diff --git a/mps/code/commpost.nmk b/mps/code/commpost.nmk index 793ec8e6035..942caf26a01 100644 --- a/mps/code/commpost.nmk +++ b/mps/code/commpost.nmk @@ -1,44 +1,21 @@ -# commpost.nmk: SECOND COMMON FRAGMENT FOR PLATFORMS USING MV AND NMAKE +# commpost.nmk: SECOND COMMON FRAGMENT FOR PLATFORMS USING NMAKE -*- makefile -*- # # $Id$ -# Copyright (c) 2001 Ravenbrook Limited. See end of file for license. +# Copyright (c) 2001-2013 Ravenbrook Limited. See end of file for license. # # DESCRIPTION # # Second common makefile fragment for w3*mv.nmk. See commpre.nmk -# PSEUDO-TARGETS +# == Pseudo-targets == -# "all" builds all the varieties of all targets -# %%TARGET: When adding a new target, add it to the all dependencies. - -all: mpmss.exe amcss.exe amsss.exe amssshe.exe segsmss.exe awlut.exe awluthe.exe\ - mpsicv.exe lockutw3.exe lockcov.exe poolncv.exe locv.exe qs.exe apss.exe \ - sacss.exe finalcv.exe finaltest.exe \ - arenacv.exe bttest.exe teletest.exe \ - abqtest.exe cbstest.exe btcv.exe mv2test.exe messtest.exe steptest.exe \ - locbwcss.exe locusss.exe zcoll.exe zmess.exe \ - mpseventcnv.exe mpseventtxt.exe \ - mps.lib +all: $(ALL_TARGETS) # Convenience targets -# %%TARGET: When adding a new target, add a pseudo-target for it here, -# first rule for variety-dependent targets, and second for -# variety-independent ones. - -mpmss.exe amcss.exe amcsshe.exe amsss.exe amssshe.exe segsmss.exe awlut.exe awluthe.exe dwstress.exe \ - mpsicv.exe lockutw3.exe lockcov.exe poolncv.exe locv.exe qs.exe apss.exe \ - sacss.exe finalcv.exe finaltest.exe \ - arenacv.exe bttest.exe teletest.exe \ - expt825.exe \ - abqtest.exe cbstest.exe btcv.exe mv2test.exe messtest.exe steptest.exe \ - walkt0.exe locbwcss.exe locusss.exe \ - exposet0.exe zcoll.exe zmess.exe \ - replay.exe replaysw.exe mpseventcnv.exe mpseventtxt.exe mpseventsql.exe \ - mps.lib: +$(ALL_TARGETS): !IFDEF VARIETY $(MAKE) /nologo /f $(PFM).nmk TARGET=$@ variety !ELSE @@ -79,6 +56,17 @@ variety: $(PFM)\$(VARIETY)\$(TARGET) mpsicv.cov: $(MAKE) /nologo /f $(PFM).nmk TARGET=$@ VARIETY=cv variety +# testrun +# Runs automated test cases. + +testrun: $(AUTO_TEST_TARGETS) +!IFDEF VARIETY + ..\tool\testrun.bat $(PFM) $(VARIETY) $(AUTO_TEST_TARGETS) +!ELSE + $(MAKE) /nologo /f $(PFM).nmk VARIETY=hot testrun + $(MAKE) /nologo /f $(PFM).nmk VARIETY=cool testrun +!ENDIF + # THE MPS LIBRARY # @@ -133,41 +121,8 @@ $(PFM)\di\mps.lib: \ !IFDEF VARIETY -$(PFM)\$(VARIETY)\finalcv.exe: $(PFM)\$(VARIETY)\finalcv.obj \ - $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) - -$(PFM)\$(VARIETY)\finaltest.exe: $(PFM)\$(VARIETY)\finaltest.obj \ - $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) - -$(PFM)\$(VARIETY)\expt825.exe: $(PFM)\$(VARIETY)\expt825.obj \ - $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) - -$(PFM)\$(VARIETY)\locv.exe: $(PFM)\$(VARIETY)\locv.obj \ - $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) - -$(PFM)\$(VARIETY)\mpmss.exe: $(PFM)\$(VARIETY)\mpmss.obj \ - $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) - -$(PFM)\$(VARIETY)\apss.exe: $(PFM)\$(VARIETY)\apss.obj \ - $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) - -$(PFM)\$(VARIETY)\sacss.exe: $(PFM)\$(VARIETY)\sacss.obj \ - $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) - -$(PFM)\$(VARIETY)\bttest.exe: $(PFM)\$(VARIETY)\bttest.obj \ - $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) - -$(PFM)\$(VARIETY)\teletest.exe: $(PFM)\$(VARIETY)\teletest.obj \ - $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) - -$(PFM)\$(VARIETY)\lockcov.exe: $(PFM)\$(VARIETY)\lockcov.obj \ - $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) - -$(PFM)\$(VARIETY)\lockutw3.exe: $(PFM)\$(VARIETY)\lockutw3.obj \ - $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) - -$(PFM)\$(VARIETY)\mpsicv.exe: $(PFM)\$(VARIETY)\mpsicv.obj \ - $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) +$(PFM)\$(VARIETY)\abqtest.exe: $(PFM)\$(VARIETY)\abqtest.obj \ + $(PFM)\$(VARIETY)\abq.obj $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) $(PFM)\$(VARIETY)\amcss.exe: $(PFM)\$(VARIETY)\amcss.obj \ $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) @@ -175,24 +130,21 @@ $(PFM)\$(VARIETY)\amcss.exe: $(PFM)\$(VARIETY)\amcss.obj \ $(PFM)\$(VARIETY)\amcsshe.exe: $(PFM)\$(VARIETY)\amcsshe.obj \ $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) +$(PFM)\$(VARIETY)\amcssth.exe: $(PFM)\$(VARIETY)\amcssth.obj \ + $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) + $(PFM)\$(VARIETY)\amsss.exe: $(PFM)\$(VARIETY)\amsss.obj \ $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) $(PFM)\$(VARIETY)\amssshe.exe: $(PFM)\$(VARIETY)\amssshe.obj \ $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) -$(PFM)\$(VARIETY)\segsmss.exe: $(PFM)\$(VARIETY)\segsmss.obj \ - $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) - -$(PFM)\$(VARIETY)\locbwcss.exe: $(PFM)\$(VARIETY)\locbwcss.obj \ +$(PFM)\$(VARIETY)\apss.exe: $(PFM)\$(VARIETY)\apss.obj \ $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) -$(PFM)\$(VARIETY)\locusss.exe: $(PFM)\$(VARIETY)\locusss.obj \ +$(PFM)\$(VARIETY)\arenacv.exe: $(PFM)\$(VARIETY)\arenacv.obj \ $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) -$(PFM)\$(VARIETY)\dwstress.exe: $(PFM)\$(VARIETY)\dwstress.obj \ - $(DWOBJ) $(PFM)\$(VARIETY)\mps.lib - $(PFM)\$(VARIETY)\awlut.exe: $(PFM)\$(VARIETY)\awlut.obj \ $(FMTTESTOBJ) \ $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) @@ -201,27 +153,75 @@ $(PFM)\$(VARIETY)\awluthe.exe: $(PFM)\$(VARIETY)\awluthe.obj \ $(FMTTESTOBJ) \ $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) +$(PFM)\$(VARIETY)\btcv.exe: $(PFM)\$(VARIETY)\btcv.obj \ + $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) + +$(PFM)\$(VARIETY)\bttest.exe: $(PFM)\$(VARIETY)\bttest.obj \ + $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) + +$(PFM)\$(VARIETY)\cbstest.exe: $(PFM)\$(VARIETY)\cbstest.obj \ + $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) + +$(PFM)\$(VARIETY)\exposet0.exe: $(PFM)\$(VARIETY)\exposet0.obj \ + $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) + +$(PFM)\$(VARIETY)\expt825.exe: $(PFM)\$(VARIETY)\expt825.obj \ + $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) + +$(PFM)\$(VARIETY)\finalcv.exe: $(PFM)\$(VARIETY)\finalcv.obj \ + $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) + +$(PFM)\$(VARIETY)\finaltest.exe: $(PFM)\$(VARIETY)\finaltest.obj \ + $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) + +$(PFM)\$(VARIETY)\locbwcss.exe: $(PFM)\$(VARIETY)\locbwcss.obj \ + $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) + +$(PFM)\$(VARIETY)\lockcov.exe: $(PFM)\$(VARIETY)\lockcov.obj \ + $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) + +$(PFM)\$(VARIETY)\lockutw3.exe: $(PFM)\$(VARIETY)\lockutw3.obj \ + $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) + +$(PFM)\$(VARIETY)\locusss.exe: $(PFM)\$(VARIETY)\locusss.obj \ + $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) + +$(PFM)\$(VARIETY)\locv.exe: $(PFM)\$(VARIETY)\locv.obj \ + $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) + +$(PFM)\$(VARIETY)\messtest.exe: $(PFM)\$(VARIETY)\messtest.obj \ + $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) + +$(PFM)\$(VARIETY)\mpmss.exe: $(PFM)\$(VARIETY)\mpmss.obj \ + $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) + +$(PFM)\$(VARIETY)\mpsicv.exe: $(PFM)\$(VARIETY)\mpsicv.obj \ + $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) + +$(PFM)\$(VARIETY)\mv2test.exe: $(PFM)\$(VARIETY)\mv2test.obj \ + $(PFM)\$(VARIETY)\poolmv2.obj $(PFM)\$(VARIETY)\abq.obj \ + $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) + $(PFM)\$(VARIETY)\poolncv.exe: $(PFM)\$(VARIETY)\poolncv.obj \ $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) $(PFM)\$(VARIETY)\qs.exe: $(PFM)\$(VARIETY)\qs.obj \ $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) -$(PFM)\$(VARIETY)\arenacv.exe: $(PFM)\$(VARIETY)\arenacv.obj \ +$(PFM)\$(VARIETY)\sacss.exe: $(PFM)\$(VARIETY)\sacss.obj \ $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) -$(PFM)\$(VARIETY)\abqtest.exe: $(PFM)\$(VARIETY)\abqtest.obj \ - $(PFM)\$(VARIETY)\abq.obj $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) +$(PFM)\$(VARIETY)\segsmss.exe: $(PFM)\$(VARIETY)\segsmss.obj \ + $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) -$(PFM)\$(VARIETY)\cbstest.exe: $(PFM)\$(VARIETY)\cbstest.obj \ +$(PFM)\$(VARIETY)\steptest.exe: $(PFM)\$(VARIETY)\steptest.obj \ + $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) + +$(PFM)\$(VARIETY)\teletest.exe: $(PFM)\$(VARIETY)\teletest.obj \ $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) -$(PFM)\$(VARIETY)\btcv.exe: $(PFM)\$(VARIETY)\btcv.obj \ - $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) - -$(PFM)\$(VARIETY)\mv2test.exe: $(PFM)\$(VARIETY)\mv2test.obj \ - $(PFM)\$(VARIETY)\poolmv2.obj $(PFM)\$(VARIETY)\abq.obj \ - $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) +$(PFM)\$(VARIETY)\walkt0.exe: $(PFM)\$(VARIETY)\walkt0.obj \ + $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) $(PFM)\$(VARIETY)\zcoll.exe: $(PFM)\$(VARIETY)\zcoll.obj \ $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) \ @@ -251,18 +251,6 @@ $(PFM)\$(VARIETY)\replaysw.obj: $(PFM)\$(VARIETY)\replay.obj $(ECHO) $@ copy $** $@ >nul: -$(PFM)\$(VARIETY)\messtest.exe: $(PFM)\$(VARIETY)\messtest.obj \ - $(PFM)\$(VARIETY)\mps.lib $(TESTLIBOBJ) - -$(PFM)\$(VARIETY)\steptest.exe: $(PFM)\$(VARIETY)\steptest.obj \ - $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) - -$(PFM)\$(VARIETY)\walkt0.exe: $(PFM)\$(VARIETY)\walkt0.obj \ - $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) - -$(PFM)\$(VARIETY)\exposet0.exe: $(PFM)\$(VARIETY)\exposet0.obj \ - $(PFM)\$(VARIETY)\mps.lib $(FMTTESTOBJ) $(TESTLIBOBJ) - !ENDIF @@ -307,7 +295,7 @@ $(PFM)\$(VARIETY)\sqlite3.obj: # C. COPYRIGHT AND LICENSE # -# Copyright (C) 2001-2002 Ravenbrook Limited . +# Copyright (C) 2001-2013 Ravenbrook Limited . # All rights reserved. This is an open source license. Contact # Ravenbrook for commercial licensing options. # diff --git a/mps/code/commpre.nmk b/mps/code/commpre.nmk index 47c66943164..eb49c3259b3 100644 --- a/mps/code/commpre.nmk +++ b/mps/code/commpre.nmk @@ -1,4 +1,4 @@ -# commpre.nmk: FIRST COMMON FRAGMENT FOR PLATFORMS USING MV AND NMAKE +# commpre.nmk: FIRST COMMON FRAGMENT FOR PLATFORMS USING NMAKE -*- makefile -*-1 # # $Id$ # Copyright (c) 2001 Ravenbrook Limited. See end of file for license. @@ -14,17 +14,22 @@ # %%PART: When adding a new part, add a new parameter for the files included # in the part # Parameters: -# PFM platform code, e.g. "nti3mv" +# PFM platform code, e.g. "w3i3mv" # PFMDEFS /D options to define platforms preprocessor symbols # to the compiler. Eg "/DOS_NT /DARCH_386 /DBUILD_MVC" -# MPM list of sources which make up the "mpm" part for this -# platform. Each source is stripped of its .c extension +# MPMCOMMON list of sources which make up the "mpm" part for all +# platforms. Each source is stripped of its .c extension # and surrounded in angle brackets (<>) +# MPM as above, plus sources for the "mpm" part for the current +# platform. # PLINTH as above for the "plinth" part # AMC as above for the "amc" part # AMS as above for the "ams" part # LO as above for the "lo" part -# MRG as above for the "mrg" part +# POOLN as above for the "pooln" part +# SNC as above for the "snc" part +# DW as above for the "dw" part +# FMTTEST as above for the "fmttest" part # TESTLIB as above for the "testlib" part # NOISY if defined, causes command to be emitted # @@ -33,11 +38,75 @@ # # To add new targets. varieties, and parts: # Search for the string "%%TARGET", "%%VARIETY", or "%%PART" in this makefile -# and follow the instructions. If you're adding a part, you'll have to change -# the makefile for all the platforms which use this makefile to define the -# source list for that part. +# and follow the instructions. # + +# TARGETS +# +# +# %%TARGET: When adding a new target, add it to one of the variables +# in this section. Library components go in LIB_TARGETS. + +LIB_TARGETS=mps.lib + +# If it is suitable for running regularly (for example, after every +# build) as an automated test case, add it to AUTO_TEST_TARGETS. + +AUTO_TEST_TARGETS=abqtest.exe amcss.exe amcsshe.exe amsss.exe \ + amssshe.exe apss.exe arenacv.exe awlut.exe awluthe.exe btcv.exe \ + cbstest.exe exposet0.exe expt825.exe finalcv.exe finaltest.exe \ + locbwcss.exe lockcov.exe lockutw3.exe locusss.exe locv.exe \ + messtest.exe mpmss.exe mpsicv.exe mv2test.exe poolncv.exe qs.exe \ + sacss.exe segsmss.exe steptest.exe walkt0.exe zmess.exe + +# If it is not runnable as an automated test case, but is buildable, +# add it to OTHER_TEST_TARGETS with a note. +# +# bttest and teletest -- interactive and so cannot be run unattended. +# zcoll -- takes too long to be useful as a regularly run smoke test. + +OTHER_TEST_TARGETS=bttest.exe teletest.exe zcoll.exe + +# Stand-alone programs go in EXTRA_TARGETS. + +EXTRA_TARGETS=mpseventcnv.exe mpseventtxt.exe + +# This target records programs that we were once able to build but +# can't at the moment: +# +# replay -- depends on the EPVM pool. + +UNBUILDABLE_TARGETS=replay.exe + +ALL_TARGETS=$(LIB_TARGETS) $(AUTO_TEST_TARGETS) $(OTHER_TEST_TARGETS) $(EXTRA_TARGETS) + + +# PARAMETERS +# +# +# %%PART: When adding a new part, add the sources for the new part here. + +MPMCOMMON = \ + \ + \ + \ + \ + \ + +PLINTH = +AMC = +AMS = +AWL = +LO = +MVFF = +POOLN = +SNC = +DW = +FMTTEST = +TESTLIB = + + # CHECK PARAMETERS # # @@ -50,8 +119,8 @@ !IFNDEF PFMDEFS !ERROR commpre.nmk: PFMDEFS not defined !ENDIF -!IFNDEF MPM -!ERROR commpre.nmk: MPM not defined +!IFNDEF MPMCOMMON +!ERROR commpre.nmk: MPMCOMMON not defined !ENDIF !IFNDEF PLINTH !ERROR commpre.nmk: PLINTH not defined @@ -166,7 +235,7 @@ LIBFLAGSCOOL = # C. COPYRIGHT AND LICENSE # -# Copyright (C) 2001-2002 Ravenbrook Limited . +# Copyright (C) 2001-2013 Ravenbrook Limited . # All rights reserved. This is an open source license. Contact # Ravenbrook for commercial licensing options. # diff --git a/mps/code/mpm.c b/mps/code/mpm.c index 4623ca7fad6..04195a859dd 100644 --- a/mps/code/mpm.c +++ b/mps/code/mpm.c @@ -493,7 +493,9 @@ Res WriteF_firstformat_v(mps_lib_FILE *stream, case 'F': { /* function */ WriteFF f = va_arg(args, WriteFF); Byte *b = (Byte *)&f; - /* TODO: Why do we always write these little-endian? */ + /* ISO C forbits casting function pointers to integer, so + decode bytes (see design.writef.f). + TODO: Be smarter about endianness. */ for(i=0; i < sizeof(WriteFF); i++) { res = WriteULongest(stream, (ULongest)(b[i]), 16, (CHAR_BIT + 3) / 4); diff --git a/mps/code/w3i3mv.nmk b/mps/code/w3i3mv.nmk index 6de2c80db0d..49852582f61 100644 --- a/mps/code/w3i3mv.nmk +++ b/mps/code/w3i3mv.nmk @@ -1,7 +1,7 @@ -# w3i3mv.nmk: WINDOWS (INTEL) NMAKE FILE +# w3i3mv.nmk: WINDOWS (IA-32) NMAKE FILE -*- makefile -*- # # $Id$ -# Copyright (c) 2001 Ravenbrook Limited. See end of file for license. +# Copyright (c) 2001-2013 Ravenbrook Limited. See end of file for license. PFM = w3i3mv @@ -11,31 +11,12 @@ PFM = w3i3mv PFMDEFS = /DCONFIG_PF_STRING="w3i3mv" /DCONFIG_PF_W3I3MV \ /DWIN32 /D_WINDOWS /Gs -MPM = \ - \ - \ - \ - \ -
\ - \ - \ - -PLINTH = -AMC = -AMS = -AWL = -LO = -SNC = -MVFF = -N = -DW = -FMTTEST = -POOLN = -TESTLIB = - - !INCLUDE commpre.nmk +# MPM sources: core plus platform-specific. +MPM = $(MPMCOMMON) + + # Source to object file mappings and CFLAGS amalgamation # @@ -187,7 +168,7 @@ TESTLIBOBJ = $(TESTLIBOBJ0:>=.obj) # C. COPYRIGHT AND LICENSE # -# Copyright (C) 2001-2002 Ravenbrook Limited . +# Copyright (C) 2001-2013 Ravenbrook Limited . # All rights reserved. This is an open source license. Contact # Ravenbrook for commercial licensing options. # diff --git a/mps/code/w3i6mv.nmk b/mps/code/w3i6mv.nmk index ad238b05284..7df37c29172 100644 --- a/mps/code/w3i6mv.nmk +++ b/mps/code/w3i6mv.nmk @@ -1,7 +1,7 @@ -# w3i6mv.nmk: WINDOWS (x64) NMAKE FILE +# w3i6mv.nmk: WINDOWS (x86-64) NMAKE FILE -*- makefile -*- # # $Id$ -# Copyright (c) 2001 Ravenbrook Limited. See end of file for license. +# Copyright (c) 2001-2013 Ravenbrook Limited. See end of file for license. PFM = w3i6mv @@ -12,26 +12,8 @@ PFMDEFS = /DCONFIG_PF_STRING="w3i6mv" /DCONFIG_PF_W3I6MV \ /DWIN32 /D_WINDOWS /Gs MASM = ml64 -MPM = \ - \ - \ - \ - \ -
\ - \ - \ - -PLINTH = -AMC = -AMS = -AWL = -LO = -SNC = -MVFF = -DW = -FMTTEST = -POOLN = -TESTLIB = +# MPM sources: core plus platform-specific. +MPM = $(MPMCOMMON) !INCLUDE commpre.nmk @@ -187,7 +169,7 @@ TESTLIBOBJ = $(TESTLIBOBJ0:>=.obj) # C. COPYRIGHT AND LICENSE # -# Copyright (C) 2001-2002 Ravenbrook Limited . +# Copyright (C) 2001-2013 Ravenbrook Limited . # All rights reserved. This is an open source license. Contact # Ravenbrook for commercial licensing options. # diff --git a/mps/design/alloc-frame.txt b/mps/design/alloc-frame.txt index 9e8c46544b4..f4e19d977d3 100644 --- a/mps/design/alloc-frame.txt +++ b/mps/design/alloc-frame.txt @@ -9,6 +9,7 @@ Allocation frame protocol :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: allocation frames; design Introduction @@ -252,8 +253,7 @@ the ``SelectFrameOfAddr()`` operation. _`.fn.client.in-frame`: This function is used by clients to invoke the ``AddrInFrame()`` operation. -``mps_res_t mps_ap_set_frame_class(mps_ap_t buf, mps_frame_class_t -class)`` +``mps_res_t mps_ap_set_frame_class(mps_ap_t buf, mps_frame_class_t class)`` _`.fn.client.set`: This function is used by clients to invoke the ``SetFrameClass()`` operation. diff --git a/mps/design/arena.txt b/mps/design/arena.txt index 38bdb52542d..7560a5a358d 100644 --- a/mps/design/arena.txt +++ b/mps/design/arena.txt @@ -9,6 +9,7 @@ Arena :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: arena; design Introduction diff --git a/mps/design/arenavm.txt b/mps/design/arenavm.txt index 6de3f2e2331..85eb6c9ea3b 100644 --- a/mps/design/arenavm.txt +++ b/mps/design/arenavm.txt @@ -9,7 +9,9 @@ Virtual Memory Arena :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. - +:Index terms: + pair: virtual memory arena; design + pair: VM arena; design Introduction diff --git a/mps/design/bt.txt b/mps/design/bt.txt index a6d734376dd..21894893ee6 100644 --- a/mps/design/bt.txt +++ b/mps/design/bt.txt @@ -9,6 +9,7 @@ Bit tables :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: bit tables; design Introduction diff --git a/mps/design/buffer.txt b/mps/design/buffer.txt index 78dbcfa97af..6c4d35f5f5f 100644 --- a/mps/design/buffer.txt +++ b/mps/design/buffer.txt @@ -9,6 +9,7 @@ Allocation buffers and allocation points :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: buffers; design Introduction diff --git a/mps/design/check.txt b/mps/design/check.txt index a470cce775f..b044e87b6df 100644 --- a/mps/design/check.txt +++ b/mps/design/check.txt @@ -9,6 +9,7 @@ Checking :Status: incomplete design :Revision: $Id$ :Copyright: See section `Copyright and License`_. +:Index terms: pair: checking; design Introduction diff --git a/mps/design/class-interface.txt b/mps/design/class-interface.txt index d130f7ab8fb..20c2b2f649e 100644 --- a/mps/design/class-interface.txt +++ b/mps/design/class-interface.txt @@ -9,6 +9,7 @@ Pool class interface :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: class interface; design Introduction diff --git a/mps/design/collection.txt b/mps/design/collection.txt index 973a8c0f722..75b41629020 100644 --- a/mps/design/collection.txt +++ b/mps/design/collection.txt @@ -9,6 +9,7 @@ Collection framework :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: collection framework; design Introduction diff --git a/mps/design/config.txt b/mps/design/config.txt index 693ffa93249..404db4c6206 100644 --- a/mps/design/config.txt +++ b/mps/design/config.txt @@ -9,6 +9,7 @@ MPS Configuration :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: configuration; design Introduction @@ -57,6 +58,7 @@ variety-reform_ branch. Client-specific customisation of the MPS will be handled in source control, while the MPS source remains generic, to reduce costs and increase reliability. See [RB_2012-09-13]_. +.. _variety-reform: /project/mps/branch/2012-08-15/variety-reform Definitions diff --git a/mps/design/critical-path.txt b/mps/design/critical-path.txt index 505200735c8..6d76dc82991 100644 --- a/mps/design/critical-path.txt +++ b/mps/design/critical-path.txt @@ -8,6 +8,10 @@ The critical path through the MPS :Date: 2012-09-07 :Revision: $Id$ :Copyright: See section `Copyright and License`_. +:Index terms: + single: critical path + single: path; critical + single: Memory Pool System; critical path Introduction diff --git a/mps/design/diag.txt b/mps/design/diag.txt index 0f3a84aeebe..cbc2e2ddfbd 100644 --- a/mps/design/diag.txt +++ b/mps/design/diag.txt @@ -9,6 +9,7 @@ Diagnostic feedback :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: diagnostic feedback; design Introduction diff --git a/mps/design/finalize.txt b/mps/design/finalize.txt index f299a9a8f29..52e5ebbc651 100644 --- a/mps/design/finalize.txt +++ b/mps/design/finalize.txt @@ -9,6 +9,7 @@ Finalization :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: finalization; design Overview diff --git a/mps/design/fix.txt b/mps/design/fix.txt index a48ac477b2b..8f11f5ea2be 100644 --- a/mps/design/fix.txt +++ b/mps/design/fix.txt @@ -9,6 +9,7 @@ The generic fix function :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: fix function; design Introduction diff --git a/mps/design/guide.hex.trans.txt b/mps/design/guide.hex.trans.txt index 6e8777b8f0b..4664b4adcad 100644 --- a/mps/design/guide.hex.trans.txt +++ b/mps/design/guide.hex.trans.txt @@ -10,6 +10,7 @@ Transliterating the alphabet into hexadecimal :Date: 1997-04-11 :Revision: $Id$ :Copyright: See section `Copyright and License`_. +:Index terms: pair: hexadecimal; transliterating Introduction diff --git a/mps/design/guide.impl.c.format.txt b/mps/design/guide.impl.c.format.txt index 18ebb1badd1..50cfe34a4f5 100644 --- a/mps/design/guide.impl.c.format.txt +++ b/mps/design/guide.impl.c.format.txt @@ -10,6 +10,9 @@ C Style -- formatting :Format: rst :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: + pair: C language; formatting guide + pair: C language formatting; guide Introduction diff --git a/mps/design/interface-c.txt b/mps/design/interface-c.txt index ce94aa5fd56..fce695d4847 100644 --- a/mps/design/interface-c.txt +++ b/mps/design/interface-c.txt @@ -9,6 +9,7 @@ C interface design :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: C interface; design Introduction diff --git a/mps/design/io.txt b/mps/design/io.txt index 8263e610144..f909b0fe6b2 100644 --- a/mps/design/io.txt +++ b/mps/design/io.txt @@ -9,6 +9,7 @@ I/O subsystem :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: I/O subsystem; design Introduction diff --git a/mps/design/keyword-arguments.txt b/mps/design/keyword-arguments.txt index 2adb02b59c3..3549d6fabb7 100644 --- a/mps/design/keyword-arguments.txt +++ b/mps/design/keyword-arguments.txt @@ -8,6 +8,7 @@ Keyword arguments in the MPS :Date: 2013-05-09 :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: keyword arguments; design Introduction diff --git a/mps/design/lib.txt b/mps/design/lib.txt index d1e2a793b50..f7d651189d6 100644 --- a/mps/design/lib.txt +++ b/mps/design/lib.txt @@ -9,6 +9,7 @@ Library interface :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: library interface; design Introduction diff --git a/mps/design/lock.txt b/mps/design/lock.txt index df81d9f7c82..6b2001c124f 100644 --- a/mps/design/lock.txt +++ b/mps/design/lock.txt @@ -9,6 +9,7 @@ The lock module :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: locking; design Purpose diff --git a/mps/design/locus.txt b/mps/design/locus.txt index 89260ae4b35..7975d4fefda 100644 --- a/mps/design/locus.txt +++ b/mps/design/locus.txt @@ -9,6 +9,7 @@ MPS Configuration :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: locus manager; design Introduction @@ -323,8 +324,7 @@ details, see implementation section and code, or user doc. Loci .... -``Res LocusCreate(Locus *locusReturn, LocusAttrs attrs, ZoneGroup zg, -LocusAllocDesc adesc)`` +``Res LocusCreate(Locus *locusReturn, LocusAttrs attrs, ZoneGroup zg, LocusAllocDesc adesc)`` _`.function.create`: A function to create a locus: ``adesc`` contains the information about the allocation sequences in the locus, ``zg`` is diff --git a/mps/design/message-gc.txt b/mps/design/message-gc.txt index 4a1f4fa7ded..e9682614649 100644 --- a/mps/design/message-gc.txt +++ b/mps/design/message-gc.txt @@ -9,6 +9,7 @@ GC messages :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: garbage collection messages; design Introduction diff --git a/mps/design/message.txt b/mps/design/message.txt index 5b7026c10a8..7bf84004a1c 100644 --- a/mps/design/message.txt +++ b/mps/design/message.txt @@ -9,6 +9,9 @@ Client message protocol :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: + pair: messages; design + single: client message protocol Introduction diff --git a/mps/design/object-debug.txt b/mps/design/object-debug.txt index 126f1b69d3a..1e596e53b5a 100644 --- a/mps/design/object-debug.txt +++ b/mps/design/object-debug.txt @@ -9,6 +9,7 @@ Debugging features for client objects :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: debugging; design Introduction diff --git a/mps/design/pool.txt b/mps/design/pool.txt index aca58a3be2b..2db6f5422ee 100644 --- a/mps/design/pool.txt +++ b/mps/design/pool.txt @@ -9,6 +9,7 @@ Pool and pool class mechanisms :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: pool class mechanism; design Definitions diff --git a/mps/design/poolamc.txt b/mps/design/poolamc.txt index 4023e8be978..5d89e8c298f 100644 --- a/mps/design/poolamc.txt +++ b/mps/design/poolamc.txt @@ -9,6 +9,9 @@ AMC pool class :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: + pair: AMC pool class; design + single: pool class; AMC design Introduction diff --git a/mps/design/poolams.txt b/mps/design/poolams.txt index 62423359b6f..a30b829b185 100644 --- a/mps/design/poolams.txt +++ b/mps/design/poolams.txt @@ -9,6 +9,9 @@ AMS pool class :Status: draft design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: + pair: AMS pool class; design + single: pool class; AMS design Introduction diff --git a/mps/design/poolawl.txt b/mps/design/poolawl.txt index c1320244414..3b1dfd80dc3 100644 --- a/mps/design/poolawl.txt +++ b/mps/design/poolawl.txt @@ -9,6 +9,9 @@ AWL pool class :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: + pair: AWL pool class; design + single: pool class; AWL design Introduction diff --git a/mps/design/poollo.txt b/mps/design/poollo.txt index a1d7f14861f..1ef448dd739 100644 --- a/mps/design/poollo.txt +++ b/mps/design/poollo.txt @@ -9,6 +9,9 @@ LO pool class :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: + pair: LO pool class; design + single: pool class; LO design Introduction diff --git a/mps/design/poolmfs.txt b/mps/design/poolmfs.txt index 8a00ee706c9..846bcfce924 100644 --- a/mps/design/poolmfs.txt +++ b/mps/design/poolmfs.txt @@ -9,6 +9,9 @@ MFS pool class :Status: Incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: + pair: MFS pool class; design + single: pool class; MFS design Overview diff --git a/mps/design/poolmrg.txt b/mps/design/poolmrg.txt index 9425739dfae..24646dc284d 100644 --- a/mps/design/poolmrg.txt +++ b/mps/design/poolmrg.txt @@ -9,6 +9,9 @@ MRG pool class :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: + pair: MRG pool class; design + single: pool class; MRG design Introduction diff --git a/mps/design/poolmvff.txt b/mps/design/poolmvff.txt index 366b9b9c810..4edf4c9b788 100644 --- a/mps/design/poolmvff.txt +++ b/mps/design/poolmvff.txt @@ -9,6 +9,9 @@ MVFF pool class :Organization: Harlequin :Status: incomplete doc :Revision: $Id$ +:Index terms: + pair: MVFF pool class; design + single: pool class; MVFF design Introduction @@ -50,11 +53,11 @@ Methods _`.method`: The MVFF pool supports the following methods: -``Res MVFFInit(Pool pool, va_list arg)`` +``Res MVFFInit(Pool pool, Args arg)`` _`.method.init`: This takes six `keyword arguments`_: -.. _`keyword arguments`: keyword-arguments.rst +.. _`keyword arguments`: keyword-arguments ================================== ============================================ Keyword argument Description @@ -117,6 +120,7 @@ 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 structures. This is the reason for the alignment restriction above. @@ -131,7 +135,9 @@ object size (in both cases we align up). _`.design.seg-fail`: If allocating a segment fails, we try again with a segment size just large enough for the object we're allocating. This -is in response to request.mps.170186. +is in response to `request.mps.170186`_. + +.. _`request.mps.170186`: https://info.ravenbrook.com/project/mps/import/2001-11-05/mmprevol/request/mps/170186/ Document History diff --git a/mps/design/prot.txt b/mps/design/prot.txt index c7af5787d6e..e845de71f69 100644 --- a/mps/design/prot.txt +++ b/mps/design/prot.txt @@ -9,6 +9,7 @@ The protection module :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: protection interface; design Introduction diff --git a/mps/design/protan.txt b/mps/design/protan.txt index 53c9811a0e7..2e76f0e4351 100644 --- a/mps/design/protan.txt +++ b/mps/design/protan.txt @@ -9,6 +9,9 @@ ANSI implementation of protection module :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: + pair: ANSI; protection interface design + pair: ANSI protection interface; design Introduction diff --git a/mps/design/protli.txt b/mps/design/protli.txt index bb40360344b..678239f39ca 100644 --- a/mps/design/protli.txt +++ b/mps/design/protli.txt @@ -9,6 +9,9 @@ Linux implementation of protection module :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: + pair: Linux; protection interface design + pair: Linux protection interface; design Introduction diff --git a/mps/design/protocol.txt b/mps/design/protocol.txt index 55bc76f58e6..ee2ff6f5328 100644 --- a/mps/design/protocol.txt +++ b/mps/design/protocol.txt @@ -9,6 +9,7 @@ Protocol inheritance :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: protocol inheritance; design Introduction diff --git a/mps/design/protsu.txt b/mps/design/protsu.txt index e3518c1a2be..971dbdad354 100644 --- a/mps/design/protsu.txt +++ b/mps/design/protsu.txt @@ -9,6 +9,10 @@ SunOS 4 protection module :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: + pair: SunOS 4; protection interface design + pair: SunOS 4 protection interface; design + .. warning:: diff --git a/mps/design/pthreadext.txt b/mps/design/pthreadext.txt index c68bde5ba8e..0f045d01f66 100644 --- a/mps/design/pthreadext.txt +++ b/mps/design/pthreadext.txt @@ -9,6 +9,7 @@ POSIX thread extensions :Status: Draft document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: POSIX thread extensions; design Introduction diff --git a/mps/design/reservoir.txt b/mps/design/reservoir.txt index 408f6d9d9ee..5f4c0833e12 100644 --- a/mps/design/reservoir.txt +++ b/mps/design/reservoir.txt @@ -9,6 +9,7 @@ The low-memory reservoir :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: reservoir; design Introduction diff --git a/mps/design/ring.txt b/mps/design/ring.txt index f2acc49864a..d25b4f952bd 100644 --- a/mps/design/ring.txt +++ b/mps/design/ring.txt @@ -9,6 +9,7 @@ Ring data structure :Status: incomplete design :Revision: $Id$ :Copyright: See section `Copyright and License`_. +:Index terms: pair: ring structure; design Introduction diff --git a/mps/design/root.txt b/mps/design/root.txt index 30cc285eed8..078d94f92a3 100644 --- a/mps/design/root.txt +++ b/mps/design/root.txt @@ -9,6 +9,7 @@ Root manager :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: root manager; design Basics diff --git a/mps/design/scan.txt b/mps/design/scan.txt index 047eb6371d2..875858b556e 100644 --- a/mps/design/scan.txt +++ b/mps/design/scan.txt @@ -9,6 +9,7 @@ The generic scanner :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: generic scanner; design Summaries diff --git a/mps/design/seg.txt b/mps/design/seg.txt index 5e7cdd1e529..ca54b78cec9 100644 --- a/mps/design/seg.txt +++ b/mps/design/seg.txt @@ -9,6 +9,7 @@ Segment data structure :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: segments; design Introduction diff --git a/mps/design/shield.txt b/mps/design/shield.txt index 6ac60ecfa58..2d66193d4b0 100644 --- a/mps/design/shield.txt +++ b/mps/design/shield.txt @@ -9,6 +9,7 @@ Shield :Status: incomplete guide :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: shield; design Introduction @@ -46,13 +47,13 @@ by MPS). ``void ShieldRaise(Arena arena, Seg seg, AccessSet mode)`` -Prevent the mutator accessing the memory in the specified mode -(``AccessREAD``, ``AccessWRITE``, or both). + Prevent the mutator accessing the memory in the specified mode + (``AccessREAD``, ``AccessWRITE``, or both). ``void ShieldLower(Arena arena, Seg seg, AccessSet mode)`` -Allow the mutator to access the memory in the specified mode -(``AccessREAD``, ``AccessWRITE``, or both). + Allow the mutator to access the memory in the specified mode + (``AccessREAD``, ``AccessWRITE``, or both). If the mutator attempts an access that hits a shield, the MPS gets a barrier hit (in the form of a fault, interrupt, exception), quickly @@ -65,11 +66,11 @@ this. ``void ShieldSuspend(Arena arena)`` -Stop all registered mutator threads. + Stop all registered mutator threads. ``void ShieldResume(Arena arena)`` -Resume all registered mutator threads. + Resume all registered mutator threads. Control of collector access @@ -108,7 +109,7 @@ calls to ``ShieldExpose()`` on the same segment, as long as each is balanced by a corresponding ``ShieldCover()`` before ``ShieldLeave()`` is called). A usage count is maintained on each segment in ``seg->depth``: a positive "depth" means a positive number of -outstanding reasons why the segment must be exposed to the collector. +outstanding *reasons* why the segment must be exposed to the collector. When the usage count reaches zero, there is no longer any reason the segment should be unprotected, and the Shield could re-instate hardware protection. @@ -116,14 +117,14 @@ hardware protection. However, as a performance-improving hysteresis, the Shield defers re-protection, maintaining a cache of the last ``ShieldCacheSIZE`` times a segment no longer had a reason to be collector-accessible. -Presence in the cache counts as a 'reason': segments in the cache have +Presence in the cache counts as a reason: segments in the cache have ``seg->depth`` increased by one. As segments get pushed out of the -cache, or at ``ShieldLeave()``, this artificial 'reason' is +cache, or at ``ShieldLeave()``, this artificial reason is decremented from ``seg->depth``, and (if ``seg->depth`` is now zero) the deferred reinstatement of hardware protection happens. So whenever hardware protection is temporarily removed to allow -collector access, there is a 'nurse' that will ensure this protection +collector access, there is a *nurse* that will ensure this protection is re-established: the nurse is either the balancing ``ShieldCover()`` call in collector code, or an entry in the shield cache. diff --git a/mps/design/sig.txt b/mps/design/sig.txt index 4013c1bd44c..4953026a44f 100644 --- a/mps/design/sig.txt +++ b/mps/design/sig.txt @@ -9,6 +9,9 @@ Signatures in the MPS :Date: 2013-05-09 :Revision: $Id$ :Copyright: See section `Copyright and License`_. +:Index terms: + pair: structure signatures; design + single: signatures Introduction @@ -24,13 +27,15 @@ defects early. Overview -------- -Signatures are magic numbers which are written into structures when +Signatures are `magic numbers`_ which are written into structures when they are created and invalidated (by overwriting with ``SigInvalid``) when they are destroyed. They provide a limited form of run-time type checking and dynamic scope checking. They are a simplified form of "Structure Marking", a technique used in the Multics filesystem [THVV_1995]_. +.. _`magic numbers`: http://en.wikipedia.org/wiki/Magic_number_(programming) + Definitions ----------- @@ -54,7 +59,7 @@ This is a 32-bit hex constant, spelled according to guide.hex.trans_:: ABCDEFGHIJKLMNOPQRSTUVWXYZ ABCDEF9811C7340BC6520F3812 -.. _guide.hex.trans: ./guide.hex.trans.txt +.. _guide.hex.trans: guide.hex.trans This allows the structure to be recognised when looking at memory in a hex dump or memory window, or found using memory searches. @@ -97,10 +102,13 @@ Do not do anything else with signatures. See `.rule.purpose`_. Checking -------- The signature is checked in various ways. Every function that takes a -(pointer to) a signed structure should check its argument using the ``AVERT`` -macro. This macro has different definitions depending on how the MPS is -compiled. It may simply check the signature directly, or call the full -checking function for the structure. +(pointer to) a signed structure should check its argument using the +``AVERT`` macro. This macro has different definitions depending on how +the MPS is compiled (see design.mps.config.def.var_). It may simply check +the signature directly, or call the full checking function for the +structure. + +.. _design.mps.config.def.var: config#def-var The checking function for the structure should also validate the signature as its first step using the ``CHECKS()`` macro (see diff --git a/mps/design/splay.txt b/mps/design/splay.txt index 1efbd4800be..8f3fa79d459 100644 --- a/mps/design/splay.txt +++ b/mps/design/splay.txt @@ -9,6 +9,7 @@ Splay trees :Status: draft document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: splay trees; design Introduction diff --git a/mps/design/sso1al.txt b/mps/design/sso1al.txt index 0d48f189d20..60f156f902d 100644 --- a/mps/design/sso1al.txt +++ b/mps/design/sso1al.txt @@ -9,6 +9,9 @@ Stack scanner for Digital Unix on Alpha :Status: draft document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: + pair: Digital Unix on Alpha stack scanner; design + pair: Digital Unix on Alpha; stack scanner design .. warning:: diff --git a/mps/design/strategy.txt b/mps/design/strategy.txt new file mode 100644 index 00000000000..a8b94cdd579 --- /dev/null +++ b/mps/design/strategy.txt @@ -0,0 +1,462 @@ +.. mode: -*- rst -*- + +MPS Strategy +============ + +:Tag: design.mps.strategy +:Author: Nick Barnes +:Organization: Ravenbrook Limited +:Date: 2013-06-04 +:Revision: $Id$ +:Copyright: See section `Copyright and License`_. + + +Introduction +------------ + +_`.intro` This is the design of collection strategy for the MPS. + +_`.readership` MPS developers. + + +Overview +-------- + +_`.overview` The MPS uses "strategy" code to make three decisions: + +- when to start a collection trace; + +- what to condemn; + +- how to schedule tracing work. + +This document describes the current strategy, identifies some +weaknesses in it, and outlines some possible future development +directions. + + +Requirements +------------ + +[TODO: source some from req.dylan, or do an up-to-date requirements +analysis -- NB 2013-03-25] + +Garbage collection is a trade-off between time and space: it consumes +some [CPU] time in order to save some [memory] space. Strategy shifts +the balance point. A better strategy will take less time to produce +more space. Examples of good strategy might include: + +- choosing segments to condemn which contain high proportions of dead + objects; + +- starting a trace when a large number of objects have just died; + +- doing enough collection soon enough that the client program never + suffers low-memory problems; + +- using otherwise-idle CPU resources for tracing. + +Conversely, it would be bad strategy to do the reverse of each of +these (condemning live objects; tracing when there's very little +garbage; not collecting enough; tracing when the client program is +busy). + +Abstracting from these notions, requirements on strategy would +relate to: + +- Maximum pause time and other utilization metrics (for example, + bounded mutator utilization, minimum mutator utilization, total MPS + CPU usage); + +- Collecting enough garbage (for example: overall heap size; + low-memory requirements). + +- Allowing client control (for example, client recommendations for + collection timing or condemnation). + +There are other possible strategy considerations which are so far +outside the scope of current strategy and MPS design that this +document disregards them. For example, either inferring or allowing +the client to specify preferred relative object locations ("this +object should be kept in the same cache line as that one"), to improve +cache locality. + +Generations +----------- + +The largest part of the current MPS strategy implementation is the +support for generational GC. Generations are only fully supported for +AMC (and AMCZ) pools. See under "Non-AMC Pools", below, for more +information. + +Data Structures +............... + +The fundamental structure of generational GC is the ``Chain``, +which describes a set of generations. A chain is created by client +code calling ``mps_chain_create()``, specifying the "size" and +"mortality" for each generation. When creating an AMC pool, the +client code must specify the chain which will control collections for +that pool. The same chain may be used for multiple pools. + +Each generation in a chain has a ``GenDesc`` structure, +allocated in an array pointed to from the chain. Each AMC pool has a +set of ``PoolGen`` structures, one per generation. The PoolGens +for each generation point to the GenDesc and are linked together in a +ring on the GenDesc. These structures are (solely?) used to gather +information for strategy decisions. + +The arena has a unique ``GenDesc`` structure, named +``topGen`` and described in comments as "the dynamic generation" +(although in fact it is the *least* dynamic generation). Each AMC +pool has one more PoolGen than there are GenDescs in the chain. The +extra PoolGen refers to this topGen. + +AMC segments have a segment descriptor ``amcSegStruct`` which is +a ``GCSegStruct`` with two additional fields. One field +``segTypeP`` is a pointer either to the per-generation per-pool +``amcGen`` structure (a subclass of ``PoolGen``), or to a +nailboard (which then points to an amcGen). The other field +``new`` is a boolean used for keeping track of memory usage for +strategy reasons (see below under 'Accounting'). The ``amcGen`` +is used for statistics (``->segs``) and forwarding buffers +(``->forward``). + +The AMC pool class only ever allocates a segment in order to fill a +buffer: either the buffer for a client Allocation Point, or a +forwarding buffer. In order to support generational collection, there +is a subclass ``amcBuf`` of ``SegBuf``, with a +``gen`` field (pointing to a ``amcGen``). So in +``AMCBufferFill()`` the generation of the new segment can be +determined. + +When an AMC pool is created, these ``amcGen`` and +``amcBuf`` structures are all created, and the +``amcBuf->gen`` fields initialized so that the forwarding buffer +of each amcGen knows that it belongs to the next "older" amcGen (apart +from the "oldest" amcGen - that which refers to the topGen - whose +forwarding buffer belongs to itself). + +When copying an object in ``AMCFix()``, the object's current +generation is determined (``amcSegGen()``), and the object is +copied to that amcGen's forwarding buffer, using the buffer protocol. +Thus, objects are "promoted" up the chain of generations until they +end up in the topGen, which is shared between all chains and all +pools. + +For statistics and reporting purposes, when ``STATISTICS`` is +on, each AMC pool has an array of ``PageRetStruct``s, one per +trace. This structure has many ``Count`` fields, and is +intended to help to assess AMC page retention code. See job001811. + +Zones +..... + +All collections in the MPS start with condemnation of a complete +``ZoneSet``. Each generation in each chain has a zoneset +associated with it (``chain->gen[N].zones``); the condemned +zoneset is the union of some number of generation's zonesets. It is +condemned by code in the chain system calling +``TraceCondemnZones()``. This is either for all chains +(``ChainCondemnAll()`` called for every chain from +``traceCondemnAll()``) or for some number of generations in a +single chain (``ChainCondemnAuto()`` called from +``TracePoll()``). Note that the condemnation is of every +automatic-pool segment in any zone in the zoneset. It is not limited +to the segments actually associated with the condemned generation(s). + +An attempt is made to use distinct zonesets for different generations. +Whenever a segment is allocated (``AMCBufferFill()``), a +``SegPref`` is created containing the generation number +(obtained from ``amcBuf->gen->pgen->nr``) and passed to +``SegAlloc()``. The arena keeps a zoneset for each generation +number (up to ``VMArenaGenCount``, defined in +``arenavm.c`` to be ``MPS_WORD_WIDTH/2``), and a +``freeSet``. The zoneset for each generation number starts out +empty, and the ``freeSet`` starts out ``ZoneSetUNIV``. +When a segment is allocated with a ``SegPref`` with a generation +number, an attempt is made to allocate it in the corresponding zoneset +(``pagesFindFreeInZones()``). If the zoneset is empty, an +attempt is made to allocate it in the ``freeSet`` zoneset. +After it is allocated, the zones it occupies are removed from the +``freeSet`` and (if there's a generation ``SegPref``) +added to the zoneset for that generation number. + +Note that this zone placement code knows nothing of chains, +generations, pool classes, etc. It is based solely on the generation +*number*, so generations with the same number from different chains +share a zoneset preference for the purpose of placing newly allocated +segments. Combined with the fact that condemnation is per-zone, this +effectively means that generations in distinct chains are collected +together. One consequence of this is that we don't have a very fine +granularity of control over collection: a garbage collection of all +chains together is triggered by the most eager chain. There's no way +for a library or other small part of a client program to arrange +independent collection of a separate pool or chain. + +When ``AMCBufferFill()`` gets the allocated segment back, it +adds it to the zoneset associated with that generation in the pool's +controlling chain. Note that a chain's per-generation zonesets, which +represent the zones in which segments for that generation in that +chain have been placed, are quite distinct from the arena-wide +per-generation-number zonesets, which represent the zones in which +segments for that generation number in any chain have been placed. +The arena-wide per-generation-number zoneset +``vmArena->genZoneSet[N]`` is augmented in +``vmAllocComm()``. The per-chain per-generation zoneset +``chain->gen[N].zones`` is augmented in +``PoolGenUpdateZones()``. Neither kind of zoneset can ever +shrink. + +Accounting +.......... + +- ``gen[N].mortality`` + + - Specified by the client. + - TODO: fill in how this is used. + +- ``gen[N].capacity`` + + - Specified by the client. + - TODO: fill in how this is used. + +- ``amcSeg->new`` + + - TODO: fill this in + +- ``pgen->totalSize``: + + - incremented by ``AMCBufferFill()``; + - decremented by ``amcReclaimNailed()`` and ``AMCReclaim()``; + - added up by ``GenDescTotalSize(gen)``. + +- ``pgen->newSize``: + + - incremented by ``AMCBufferFill()`` (*when not ramping*) and ``AMCRampEnd()``; + - decremented by ``AMCWhiten()``, + - added up by ``GenDescNewSize(gen)``. + +- ``gen[N].proflow``: + + - set to 1.0 by ``ChainCreate()``; + - ``arena->topGen.proflow`` set to 0.0 by ``LocusInit(arena)``; + - *The value of this field is never used*. + + +- ``pgen->newSizeAtCreate``: + + - set by ``traceCopySizes()`` (that is its purpose); + - output by ``TraceStartGenDesc_diag()``. + +Ramps +..... +The intended semantics of ramping are pretty simple. It allows the +client to advise us of periods of large short-lived allocation on a +particular AP. Stuff allocated using that AP during its "ramp" will +probably be dead when the ramp finishes. How the MPS makes use of this +advice is up to us, but for instance we might segregate those objects, +collect them less enthusiastically during the ramp and then more +enthusiastically soon after the ramp finishes. Ramps can nest. + +A ramp is entered by calling:: + + mps_ap_alloc_pattern_begin(ap, mps_alloc_pattern_ramp()) + +or similar, and left in a similar way. + +This is implemented on a per-pool basis, for AMC only (it's ignored by +the other automatic pools). PoolAMC throws away the identity of the AP +specified by the client. The implementation is intended to work by +changing the generational forwarding behaviour, so that there is a "ramp +generation" - one of the regular AMC generations - which forwards to +itself if collected during a ramp (instead of promoting to an older +generation). It also tweaks the strategy calculation code, in a way +with consequences I am documenting elsewhere. + +Right now, the code sets this ramp generation to the last generation +specified in the pool's "chain": it ordinarily forwards to the +"after-ramp" generation, which is the "dynamic generation" (i.e. the +least dynamic generation, i.e. the arena-wide "top generation"). My +recollection, and some mentions in design/poolamc, suggests that the +ramp generation used to be chosen differently from this. + +So far, it doesn't sound too ghastly, I guess, although the subversion +of the generational system seems a little daft. Read on.... + +An AMC pool has a ``rampMode`` (which is really a state of a state +machine), taking one of five values: OUTSIDE, BEGIN, RAMPING, FINISH, +and COLLECTING (actually the enum values are called RampX for these +X). We initialize in OUTSIDE. The pool also has a ``rampCount``, +which is the ramp nesting depth and is used to allow us to ignore ramp +transitions other than the outermost. According to design/poolamc, +there's an invariant (in BEGIN or RAMPING, ``rampCount > 0``; in +COLLECTING or OUTSIDE, ``rampCount == 0``), but this isn't checked in +``AMCCheck()`` and in fact is false for COLLECTING (see below). + +There is a small set of events causing state machine transitions: + +- entering an outermost ramp; +- leaving an outermost ramp; +- condemning any segment of a ramp generation (detected in AMCWhiten); +- reclaiming any AMC segment. + +Here's pseudo-code for all the transition events: + +Entering an outermost ramp: + if not FINISH, go to BEGIN. + +Leaving an outermost ramp: + if RAMPING, go to FINISH. Otherwise, go to OUTSIDE. + +Condemning a ramp generation segment: + If BEGIN, go to RAMPING and make the ramp generation forward + to itself (detach the forwarding buffer and reset its generation). + If FINISH, go to COLLECTING and make the ramp generation + forward to the after-ramp generation. + +Reclaiming any AMC segment: + If COLLECTING: + if ``rampCount > 0``, go to BEGIN. Otherwise go to OUTSIDE. + +Now, some deductions: + +1. When OUTSIDE, the count is always zero, because (a) it starts that +way, and the only ways to go OUTSIDE are (b) by leaving an outermost +ramp (count goes to zero) or (c) by reclaiming when the count is zero. + +2. When BEGIN, the count is never zero (consider the transitions to +BEGIN and the transition to zero). + +3. When RAMPING, the count is never zero (again consider transitions to +RAMPING and the transition to zero). + +4. When FINISH, the count can be anything (the transition to FINISH has +zero count, but the Enter transition when FINISH can change that and +then it can increment to any value). + +5. When COLLECTING, the count can be anything (from the previous fact, +and the transition to COLLECTING). + +6. *This is a bug!!* The ramp generation is not always reset (to forward +to the after-ramp generation). If we get into FINISH and then see +another ramp before the next condemnation of the ramp generation, we +will Enter followed by Leave. The Enter will keep us in FINISH, and +the Leave will take us back to OUTSIDE, skipping the transition to the +COLLECTING state which is what resets the ramp generation forwarding +buffer. [TODO: check whether I made an issue and/or fixed it; NB 2013-06-04] + +The simplest change to fix this is to change the behaviour of the Leave +transition, which should only take us OUTSIDE if we are in BEGIN or +COLLECTING. We should also update design/poolamc to tell the truth, and +check the invariants, which will be these: + + OUTSIDE => zero + BEGIN => non-zero + RAMPING => non-zero + +A cleverer change might radically rearrange the state machine +(e.g. reduce the number of states to three) but that would require +closer design thought and should probably be postponed until we have a +clearer overall strategy plan. + +While I'm writing pseudo-code versions of ramp-related code, I should +mention this other snippet, which is the only other code relating to +ramping (these notes are useful when thinking about the broader strategy +code): + + In ``AMCBufferFill()``, if we're RAMPING, and filling the forwarding + buffer of the ramp generation, and the ramp generation is the + forwarding buffer's generation, set ``amcSeg->new`` to FALSE. Otherwise, + add the segment size to ``poolGen.newSize``. + +And since I've now mentioned the ``amcSeg->new`` flag, here are the only +other uses of that: + +- it initializes as TRUE. + +- When leaving an outermost ramp, go through all the segments in the + pool. Any non-white segment in the rampGen with new set to FALSE has + its size added to ``poolGen->newSize`` and gets new set to TRUE. + +- in ``AMCWhiten()``, if new is TRUE, the segment size is deducted + from ``poolGen.newSize`` and new is set to FALSE. + +Non-AMC Pools +............. + +The implementations of AMS, AWL, and LO pool classes are all aware of +generations (this is necessary because all tracing is driven by the +generational data structures described above), but do not make use of +them. For LO and AWL, when a pool is created, a chain with a single +generation is also created, with size and mortality parameters +hard-wired into the pool-creation function (LOInit, AWLInit). For +AMS, a chain is passed as a pool creation parameter into +``mps_pool_create()``, but this chain must also have only a +single generation (otherwise ``ResPARAM`` is returned). + +Note that these chains are separate from any chain used by an AMC pool +(except in the trivial case when a single-generation chain is used for +both AMC and AMS). Note also that these pools do not use or point to +the ``arena->topGen``, which applies only to AMC. + +Non-AMC pools have no support for ramps. + +Starting a Trace +................ +TODO: Why do we start a trace? How do we choose what to condemn? + + +Trace Progress +.............. +TODO: When do we do some tracing work? How much tracing work do we do? + +Document History +---------------- +- 2013-06-04 NB Checked this in although it's far from complete. + Pasted in my 'ramping notes' from email, which mention some bugs + which I may have fixed (TODO: check this). + +.. _NB: http://www.ravenbrook.com/consultants/nb/ + + +Copyright and License +--------------------- +Copyright © 2013 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/design/telemetry.txt b/mps/design/telemetry.txt index e930905db79..d829fc73be5 100644 --- a/mps/design/telemetry.txt +++ b/mps/design/telemetry.txt @@ -9,6 +9,7 @@ Telemetry :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: telemetry; design Introduction diff --git a/mps/design/thread-manager.txt b/mps/design/thread-manager.txt index d3b78de6a63..70ece6a1548 100644 --- a/mps/design/thread-manager.txt +++ b/mps/design/thread-manager.txt @@ -9,6 +9,7 @@ Thread Manager :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: thread manager; design Purpose diff --git a/mps/design/thread-safety.txt b/mps/design/thread-safety.txt index 4d17d8eafd5..8250eca0304 100644 --- a/mps/design/thread-safety.txt +++ b/mps/design/thread-safety.txt @@ -9,6 +9,7 @@ Thread safety in the MPS :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: thread safety; design Introduction diff --git a/mps/design/trace.txt b/mps/design/trace.txt index 37557e0a8f9..683bcb4231e 100644 --- a/mps/design/trace.txt +++ b/mps/design/trace.txt @@ -9,6 +9,7 @@ Tracer :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: tracer; design Introduction diff --git a/mps/design/type.txt b/mps/design/type.txt index 33e793411e1..eaf99eebaa9 100644 --- a/mps/design/type.txt +++ b/mps/design/type.txt @@ -9,6 +9,7 @@ General MPS types :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: general types; design Introduction diff --git a/mps/design/version-library.txt b/mps/design/version-library.txt index 32c3427a4aa..736a9648e5d 100644 --- a/mps/design/version-library.txt +++ b/mps/design/version-library.txt @@ -9,6 +9,7 @@ Library version mechanism :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: library version mechanism; design Introduction diff --git a/mps/design/version.txt b/mps/design/version.txt index 61dd3e41c4c..f2854f1ea8f 100644 --- a/mps/design/version.txt +++ b/mps/design/version.txt @@ -9,6 +9,9 @@ Software versions :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: + pair: software versions; design + single: versions; design Introduction diff --git a/mps/design/vm.txt b/mps/design/vm.txt index 3e75d50bab5..9f5cbb7c255 100644 --- a/mps/design/vm.txt +++ b/mps/design/vm.txt @@ -9,6 +9,7 @@ Virtual mapping :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: virtual mapping; design Introduction diff --git a/mps/design/vman.txt b/mps/design/vman.txt index cfccf99cc12..0729cc381d8 100644 --- a/mps/design/vman.txt +++ b/mps/design/vman.txt @@ -9,6 +9,8 @@ ANSI fake VM :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: ANSI fake VM; design + _`.intro`: The ANSI fake VM is an implementation of the MPS VM interface (see design.mps.vm) using services provided by the ANSI C diff --git a/mps/design/vmo1.txt b/mps/design/vmo1.txt index ca0eb49c083..1ff9fff1071 100644 --- a/mps/design/vmo1.txt +++ b/mps/design/vmo1.txt @@ -9,6 +9,8 @@ VM for Digital Unix :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: VM for Digital Unix; design + .. warning:: diff --git a/mps/design/vmso.txt b/mps/design/vmso.txt index 9ec47d0967a..62d32e7f6cf 100644 --- a/mps/design/vmso.txt +++ b/mps/design/vmso.txt @@ -9,6 +9,7 @@ VM for Solaris :Status: incomplete document :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: VM for Solaris; design .. warning:: diff --git a/mps/design/writef.txt b/mps/design/writef.txt index 9a346b01e3f..fec4bd72b6e 100644 --- a/mps/design/writef.txt +++ b/mps/design/writef.txt @@ -9,6 +9,7 @@ The WriteF function :Status: incomplete design :Revision: $Id$ :Copyright: See `Copyright and License`_. +:Index terms: pair: WriteF function; design Introduction @@ -82,7 +83,7 @@ Code Bame Type Example rendering ======= =========== ================== ====================================== ``$A`` address ``Addr`` ``000000019EF60010`` ``$P`` pointer ``void *`` ``000000019EF60100`` -``$F`` function ``void *(*)()`` ``000000019EF60100`` +``$F`` function ``void *(*)()`` ``0001D69E01000000`` (see `.f`_) ``$S`` string ``char *`` ``hello`` ``$C`` character ``char`` ``x`` ``$W`` word ``ULongest`` ``0000000000109AE0`` @@ -99,10 +100,10 @@ incredible snazzy output engine. We only need it for ``Describe()`` methods and assertion messages. At the moment it's a very simple bit of code -- let's keep it that way. -_`.f`: The ``F`` code is used for function pointers. They are -currently printed as a hexadecimal string of the appropriate length -for the platform, and may one day be extended to include function name -lookup. +_`.f`: The ``F`` code is used for function pointers. ISO C forbids casting +function pointers to other types, so the bytes of their representation are +written sequentially, and may have a different endianness to other pointers. +Could be smarter, or even look up function names, but see `.snazzy`_. Document History diff --git a/mps/manual/Makefile b/mps/manual/Makefile index c4dab7a1b4b..ed3544169ba 100644 --- a/mps/manual/Makefile +++ b/mps/manual/Makefile @@ -40,7 +40,8 @@ help: @echo " tools to install a local copy of the Python tools using virtualenv" clean: - -rm -rf $(BUILDDIR)/{changes,devhelp,dirhtml,doctest,doctrees,epub,html,htmlhelp,json,latex,linkcheck,locale,man,pickle,qthelp,singlehtml,texinfo,text,converted} + -rm -rf $(BUILDDIR)/{changes,devhelp,dirhtml,doctest,doctrees,epub,html,htmlhelp,json,latex,linkcheck,locale,man,pickle,qthelp,singlehtml,texinfo,text} + -find $(BUILDDIR)/source/design -name '*.rst' ! -name 'index.rst' ! -name 'old.rst' -exec rm -f '{}' ';' html: $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html diff --git a/mps/manual/html/_sources/design/alloc-frame.txt b/mps/manual/html/_sources/design/alloc-frame.txt new file mode 100644 index 00000000000..9333d6e4414 --- /dev/null +++ b/mps/manual/html/_sources/design/alloc-frame.txt @@ -0,0 +1,459 @@ +.. _design-alloc-frame: + + +.. index:: + pair: allocation frames; design + + +Allocation frame protocol +========================= + +.. mps:prefix:: design.mps.alloc-frame + + +Introduction +------------ + +:mps:tag:`intro` This document explains the design of the support for +allocation frames in MPS. + +:mps:tag:`readership` This document is intended for any MM developer. + +:mps:tag:`overview` Allocation frames are used for implementing stack pools; +each stack frame corresponds to an allocation frame. Allocation frames +may also be suitable for implementing other sub-pool groupings, such +as generations and ramp allocation patterns. + +:mps:tag:`overview.ambition` We now believe this to be a design that loses +too many advantages of stack allocation for questionable gains. The +requirements are almost entirely based on unanalysed anecdote, instead +of actual clients. + +.. note:: + + We plan to supersede this with a stack pool design at some point + in the future. Pekka P. Pirinen, 2000-03-09. + + +Definitions +----------- + +:mps:tag:`def.alloc-frame` An allocation frame is a generic name for a +device which groups objects together with other objects at allocation +time, and which may have a parent/child relationship with other +allocation frames. + + +Purpose +------- + +:mps:tag:`purpose.stack-allocation` The allocation frame protocol is +intended to support efficient memory management for stack allocation, +that is, the allocation of objects which have dynamic extent. + +:mps:tag:`purpose.general` The allocation frame protocol is intended to be +sufficiently general that it will be useful in supporting other types +of nested allocation patterns too. For example, it could be used to +for EPVM-style save and restore, ramp allocation patterns or +generations. + + +Requirements +------------ + +Known requirements +.................. + +:mps:tag:`req.stack-alloc` Provide a interface for clients to describe a +stack allocation pattern, as an alternative to using the control +stack. + +:mps:tag:`req.efficient` Permit an implementation which is comparable in +efficiency to allocating on the control stack. + +:mps:tag:`req.ap` Support allocation via allocation points (APs). + +:mps:tag:`req.format` Support the allocation of formatted objects. + +:mps:tag:`req.scan` Ensure that objects in allocation frames can participate +in garbage collection by being scanned. + +:mps:tag:`req.fix` Ensure that objects in allocation frames can participate +in garbage collection by accepting Fix requests. + +:mps:tag:`req.condemn` Ensure that objects in allocation frames can +participate in garbage collection by being condemned. + +:mps:tag:`attr.locking` Minimize the synchronization cost for the creation +and destruction of frames. + + +Proto-requirements +.................. + +:mps:tag:`proto-req` The following are possible requirements that might be +important in the future. The design does not necessarily meet all +these requirements, but it does consider them all. Each requirement +either has direct support in the framework, or could be supported with +future additions to the framework. + +:mps:tag:`req.parallels` The allocation frame protocol should provide a +framework for exploiting the parallels between stack extents, +generations and "ramps". + +:mps:tag:`req.pool-destroy` It should be possible to use allocation frames +to free all objects in a pool without destroying the pool. + +:mps:tag:`req.epvm` It should be possible to implement EPVM-style save and +restore operations by creating and destroying allocation frames. + +:mps:tag:`req.subst` It should be possible to substitute a stack pool with a +GC-ed pool so that erroneous use of a stack pool can be detected. + +:mps:tag:`req.format-extensions` It should be possible for stack pools to +utilize the same format as any other pool, including debugging formats +that include fenceposting, etc. + +:mps:tag:`req.mis-nest` Should ensure "mis-nested" stacks are safe. + +:mps:tag:`req.non-top-level` Should support allocation in the non-top stack +extent. + +:mps:tag:`req.copy-if-necessary` Should ensure that stack pools can support +"copy-if-necessary" (so that low-level system code can heapify stack +objects.) + +:mps:tag:`req.preserve` When an object is in an allocation frame which is +being destroyed, it should be possible to preserve that object in the +parent frame. + +:mps:tag:`req.contained` Should allow clients to ask if an object is +"contained" in a frame. The object is contained in a frame if it is +affected when the frame is ended. + +:mps:tag:`req.alloc-with-other` Should allow clients to allocate an object +in the same frame as another object. + + +Overview +-------- + +:mps:tag:`frame-classes` The protocol supports different types of allocation +frames, which are represented as "frame classes". It's up to pools to +determine which classes of allocation frames they support. Pools which +support more than one frame class rely on the client to indicate which +class is currently of interest. The client indicates this by means of +an operation which stores the class in the buffer to which the +allocation point is attached. + +:mps:tag:`frame-handles` Allocation frames are described via abstract "frame +handles". Pools may choose what the representation of a frame handle +should be. Frame handles are static, and the client need not store +them in a GC root. + +:mps:tag:`lightweight-frames` The design includes an extension to the +allocation point protocol, which permits the creation and destruction +of allocation frames without the necessity for claiming the arena +lock. Such frames are called "lightweight frames". + + +Operations +---------- + +:mps:tag:`op.intro` Each operation has both an external (client) interface +and an internal (MPS) interface. The external function takes an +allocation point as a parameter, determines which buffer and pool it +belongs to, and calls the internal function with the buffer and pool +as parameters. + +:mps:tag:`op.obligatory` The following operations are supported on any +allocation point which supports allocation frames:- + +:mps:tag:`operation.push` The :c:func:`PushFrame()` operation creates a new +allocation frame of the currently chosen frame class, makes this new +frame the current frame, and returns a handle for the frame. + +:mps:tag:`operation.pop` The :c:func:`PopFrame()` operation takes a frame handle +as a parameter. Some pool classes might insist or assume that this is +the handle for the current frame. It finds the parent of that frame +and makes it the current frame. The operation indicates that all +children of the new current frame contain objects which are likely to +be dead. The reclaim policy is up to the pool; some classes might +insist or assume that the objects must be dead, and eagerly free them. +Note that this might introduce the possibility of leaving dangling +pointers elsewhere in the arena. If so, it's up to the pool to decide +what to do about this. + +:mps:tag:`op.optional` The following operations are supported for some +allocation frames, but not all. Pools may choose to support some or +all of these operations for certain frame classes. An unsupported +operation will return a failure value:- + +:mps:tag:`operation.select` The :c:func:`SelectFrame()` operation takes a frame +handle as a parameter and makes that frame the current frame. It does +not indicate that any children of the current frame contain objects +which are likely to be dead. + +:mps:tag:`operation.select-addr` The :c:func:`SelectFrameOfAddr()` operation takes +an address as a parameter and makes the frame of that address the +current frame. It does not indicate that any children of the current +frame contain objects which are likely to be dead. + +:mps:tag:`operation.in-frame` The :c:func:`AddrInFrame()` operation determines +whether the supplied address is the address of an object allocated in +the supplied frame, or any child of that frame. + +:mps:tag:`operation.set` The :c:func:`SetFrameClass()` operation takes a frame +class and an allocation point as parameters, and makes that the +current frame class for the allocation point. The next :c:func:`PushFrame()` +operation will create a new frame of that class. + + +Interface +--------- + +External types +.............. + +:mps:tag:`type.client.frame-handle` Frame handles are defined as the abstract +type :c:type:`mps_frame_t`. + +.. c:type:: struct mps_frame_class_s *mps_frame_class_t + +:mps:tag:`type.client.frame-class` Frame classes are defined as an abstract +type. + +:mps:tag:`type.client.frame-class.access` Clients access frame classes by +means of dedicated functions for each frame class. + +External functions +.................. + +:mps:tag:`fn.client.push` :c:func:`mps_ap_frame_push()` is used by clients to +invoke the :c:func:`PushFrame()` operation. For lightweight frames, this +might not invoke the corresponding internal function. + +:mps:tag:`fn.client.pop` :c:func:`mps_ap_frame_pop()` is used by clients to invoke +the :c:func:`PopFrame()` operation. For lightweight frames, this might not +invoke the corresponding internal function. + +.. c:function:: mps_res_t mps_ap_frame_select(mps_ap_t buf, mps_frame_t frame) + +:mps:tag:`fn.client.select` This following function is used by clients to +invoke the :c:func:`SelectFrame()` operation. + +.. c:function:: mps_res_t mps_ap_frame_select_from_addr(mps_ap_t buf, mps_addr_t addr) + +:mps:tag:`fn.client.select-addr` This function is used by clients to invoke +the :c:func:`SelectFrameOfAddr()` operation. + +.. c:function:: mps_res_t mps_ap_addr_in_frame(mps_bool_t *inframe_o, mps_ap_t buf, mps_addr_t *addrref, mps_frame_t frame) + +:mps:tag:`fn.client.in-frame` This function is used by clients to invoke the +:c:func:`AddrInFrame()` operation. + +.. c:function:: mps_res_t mps_ap_set_frame_class(mps_ap_t buf, mps_frame_class_t class) + +:mps:tag:`fn.client.set` This function is used by clients to invoke the +:c:func:`SetFrameClass()` operation. + +.. c:function:: mps_frame_class_t mps_alloc_frame_class_stack(void) + +:mps:tag:`fn.client.stack-frame-class` This function is used by clients to +access the frame class used for simple stack allocation. + + +Internal types +.............. + +.. c:type:: struct AllocFrameStruct *AllocFrame + +:mps:tag:`type.frame-handle` Frame handles are defined as an abstract type. + +.. c:type:: struct AllocFrameClassStruct *AllocFrameClass + +:mps:tag:`type.frame-class` Frame classes are defined as an abstract type. + +.. c:type:: Res (*PoolFramePushMethod)(AllocFrame *frameReturn, Pool pool, Buffer buf) + +:mps:tag:`fn.push` A pool method of this type is called (if needed) to +invoke the :c:func:`PushFrame()` operation. + +.. c:type:: Res (*PoolFramePopMethod)(Pool pool, Buffer buf, AllocFrame frame) + +:mps:tag:`fn.pop` A pool method of this type is called (if needed) +to invoke the PopFrame operation: + +.. c:type:: Res (*PoolFrameSelectMethod)(Pool pool, Buffer buf, AllocFrame frame) + +:mps:tag:`fn.select` A pool method of this type is called to invoke the +:c:func:`SelectFrame()` operation. + +.. c:type:: Res (*PoolFrameSelectFromAddrMethod)(Pool pool, Buffer buf, Addr addr) + +:mps:tag:`fn.select-addr` A pool method of this type is called to invoke the +:c:func:`SelectFrameOfAddr()` operation. + +.. c:type:: Res (*PoolAddrInFrameMethod)(Bool *inframeReturn, Pool pool, Seg seg, Addr *addrref, AllocFrame frame) + +:mps:tag:`fn.in-frame` A pool method of this type is called to invoke the +:c:func:`AddrInFrame()` operation. + +.. c:type:: Res (*PoolSetFrameClassMethod)(Pool pool, Buffer buf, AllocFrameClass class) + +:mps:tag:`fn.set` A pool method of this type is called to invoke the +:c:func:`SetFrameClass()` operation. + + +Lightweight frames +------------------- + +Overview +........ + +:mps:tag:`lw-frame.overview` Allocation points provide direct support for +lightweight frames, and are designed to permit PushFrame and PopFrame +operations without the need for locking and delegation to the pool +method. Pools can disable this mechanism for any allocation point, so +that the pool method is always called. The pool method will be called +whenever synchronization is required for other reasons (e.g. the +buffer is tripped). + +:mps:tag:`lw-frame.model` Lightweight frames offer direct support for a +particular model of allocation frame use, whereby the PushFrame +operation returns the current allocation pointer as a frame handle, +and the PopFrame operation causes the allocation pointer to be reset +to the address of the frame handle. This model should be suitable for +simple stack frames, where more advanced operations like SelectFrame +are not supported. It may also be suitable for more advanced +allocation frame models when they are being used simply. The use of a +complex operation always involves synchronization via locking, and the +pool may disable lightweight synchronization temporarily at this time. + +State +..... + +:mps:tag:`lw-frame.states` Allocation points supporting lightweight frames +will be in one of the following states: + +============ ================================================================ +Valid Indicates that :c:func:`PushFrame()` can be a lightweight + operation and need not be synchronized. +PopPending Indicates that there has been a :c:func:`PopFrame()` operation + that the pool must respond to. +Disabled Indicates that the pool has disabled support for lightweight + operations for this AP. +============ ================================================================ + +These states are in addition to the state normally held by an AP for +allocation purposes. An AP will be in the Disabled state at creation. + +:mps:tag:`lw-frame.transitions` State transitions happen under the following +circumstances: + +======================= ==================================================== +Valid → PopPending As a result of a client :c:func:`PopFrame()` + operation. +Valid → Disabled At the choice of the pool (for example, when + responding to a :c:func:`SelectFrame()` operation). +PopPending → Valid At the choice of the pool, when processing a + :c:func:`PopFrame()`. +PopPending → Disabled At the choice of the pool, when processing a + :c:func:`PopFrame()`. +Disabled → Valid At the choice of the pool. +Disabled → Popframe Illegal. +======================= ==================================================== + +:mps:tag:`lw-frame.state-impl` Each AP contains 3 additional fields to hold this state:: + + mps_addr_t frameptr; + mps_bool_t enabled; + mps_bool_t lwPopPending; + +:mps:tag:`lw-frame.enabled` The ``enabled`` slot holds the following values for +each state: + +========== ========== +Valid :c:macro:`TRUE` +PopPending :c:macro:`TRUE` +Disabled :c:macro:`FALSE` +========== ========== + +:mps:tag:`lw-frame.frameptr` The ``frameptr`` slot holds the following values +for each state: + +========== ============================================ +Valid :c:macro:`NULL` +PopPending Frame handle for most recently popped frame. +Disabled :c:macro:`NULL` +========== ============================================ + +:mps:tag:`lw-frame.lwPopPending` The ``lwPopPending`` slot holds the +following values for each state: + +========== ========= +Valid :c:macro:`FALSE` +PopPending :c:macro:`TRUE` +Disabled :c:macro:`FALSE` +========== ========= + +:mps:tag:`lw-frame.state-for-gc` It is not necessary for the tracer, format +code, pool, or any other part of the GC support in MPS to read either +of the two additional AP fields in order to scan a segment which +supports a lightweight allocation frame. + + +Synchronization +............... + +:mps:tag:`lw-frame.sync` The purpose of the design is that mutator may +access the state of an AP without locking with MPS (via the external +functions). The design assumes the normal MPS restriction that an +operation on an AP may only be performed by a single mutator thread at +a time. Each of the operations on allocation frames counts as an +operation on an AP. + +:mps:tag:`lw-frame.sync.pool` Pools are permitted to read or modify the +lightweight frame state of an AP only in response to an operation on +that AP. + +:mps:tag:`lw-frame.sync.external` The external functions +:c:func:`mps_ap_frame_push()` and :c:func:`mps_ap_frame_pop()` are permitted to +read the values of the ``enabled`` and ``frameptr`` fields for the +supplied AP without claiming the arena lock. They are permitted to +modify the ``frameptr`` field if and only if ``enabled == FALSE``. + +:mps:tag:`lw-frame.sync.trip` When a buffer trip happens, and the trap +wasn't set by MPS itself (that is, it wasn't because of a flip or for +logging), then the buffer code must check whether the AP has state +PopPending. If it does, the buffer code must call the Pool. + + +Implementation +.............. + +:mps:tag:`lw-frame.push` The external :c:func:`PushFrame()` operation +(:c:func:`mps_ap_frame_push()`) performs the following operations:: + + IF (!APIsTrapped(ap) && StateOfFrame(ap) == Valid && ap->init == ap->alloc) + *frame_o = ap->init; + ELSE + WITH_ARENA_LOCK + PerformInternalPushFrameOperation(...) + END + END + +:mps:tag:`lw-frame.pop` The external :c:func:`PopFrame()` operation +(:c:func:`mps_ap_frame_pop()`) performs the following operations:: + + IF (StateOfFrame(ap) != Disabled) + TrapAP(ap); /* ensure next allocation or push involves the pool */ + ap->frameptr = frame; + ap->lwpopPending = TRUE; + ELSE + WITH_ARENA_LOCK + PerformInternalPopFrameOperation(...) + END + END + + diff --git a/mps/manual/html/_sources/design/arena.txt b/mps/manual/html/_sources/design/arena.txt index 6b89e3948c2..c0f671e419d 100644 --- a/mps/manual/html/_sources/design/arena.txt +++ b/mps/manual/html/_sources/design/arena.txt @@ -1,6 +1,535 @@ +.. _design-arena: + + .. index:: pair: arena; design -.. _design-arena: -.. include:: ../../converted/arena.rst +Arena +===== + +.. mps:prefix:: design.mps.arena + + +Introduction +------------ + +:mps:tag:`intro` This is the design of the arena structure. + +:mps:tag:`readership` MPS developers. + + +Overview +-------- + +:mps:tag:`overview` The arena serves two purposes. It is a structure that is +the top-level state of the MPS, and as such contains a lot of fields +which are considered "global". And it provides raw memory to pools. + +An arena belongs to a particular arena class. The class is selected +when the arena is created. Classes encapsulate both policy (such as +how pool placement preferences map into actual placement) and +mechanism (such as where the memory originates: operating system +virtual memory, client provided, or via malloc). Some behaviour +(mostly serving the "top-level datastructure" purpose) is implemented +by generic arena code, and some by arena class code. + + +Definitions +----------- + +:mps:tag:`def.tract` Pools request memory from the arena by calling +:c:func:`ArenaAlloc()`. This returns a block comprising a contiguous sequence +of "tracts". A tract has a specific size (also known as the "arena +alignment", which typically corresponds to the operating system page +size) and all tracts are aligned to that size. "Tract" is also used +for the data structure used to manage tracts. + + +Requirements +------------ + +.. note:: + + Where do these come from? Need to identify and document the + sources of requirements so that they are traceable to client + requirements. Most of these come from the architectural design + (design.mps.architecture) or the fix function design + (design.mps.fix). Richard Brooksby, 1995-08-28. + + They were copied from design.mps.arena.vm(1) and edited slightly. + David Jones, 1999-06-23. + + +Block management +................ + +:mps:tag:`req.fun.block.alloc` The arena must provide allocation of +contiguous blocks of memory. + +:mps:tag:`req.fun.block.free` It must also provide freeing of contiguously +allocated blocks owned by a pool - whether or not the block was +allocated via a single request. + +:mps:tag:`req.attr.block.size.min` The arena must support management of +blocks down to the size of the grain (page) provided by the virtual +mapping interface if a virtual memory interface is being used, or a +comparable size otherwise. + +:mps:tag:`req.attr.block.size.max` It must also support management of blocks +up to the maximum size allowed by the combination of operating system +and architecture. This is derived from req.dylan.attr.obj.max (at +least). + +:mps:tag:`req.attr.block.align.min` The alignment of blocks shall not be less +than :c:macro:`MPS_PF_ALIGN` for the architecture. This is so that pool +classes can conveniently guarantee pool allocated blocks are aligned +to :c:macro:`MPS_PF_ALIGN`. (A trivial requirement.) + +:mps:tag:`req.attr.block.grain.max` The granularity of allocation shall not +be more than the grain size provided by the virtual mapping interface. + + +Address translation +................... + +:mps:tag:`req.fun.trans` The arena must provide a translation from any +address to either an indication that the address is not in any tract +(if that is so) or the following data associated with the tract +containing that address: + +:mps:tag:`req.fun.trans.pool` The pool that allocated the tract. + +:mps:tag:`req.fun.trans.arbitrary` An arbitrary pointer value that the pool +can associate with the tract at any time. + +:mps:tag:`req.fun.trans.white` The tracer whiteness information. That is, a +bit for each active trace that indicates whether this tract is white +(contains white objects). This is required so that the "fix" protocol +can run very quickly. + +:mps:tag:`req.attr.trans.time` The translation shall take no more than @@@@ +[something not very large -- drj 1999-06-23] + + +Iteration protocol +.................. + +:mps:tag:`req.iter` er, there's a tract iteration protocol which is +presumably required for some reason? + + +Arena partition +............... + +:mps:tag:`req.fun.set` The arena must provide a method for approximating sets +of addresses. + +:mps:tag:`req.fun.set.time` The determination of membership shall take no +more than @@@@ [something very small indeed]. (the non-obvious +solution is refsets) + + +Constraints +........... + +:mps:tag:`req.attr.space.overhead` req.dylan.attr.space.struct implies that +the arena must limit the space overhead. The arena is not the only +part that introduces an overhead (pool classes being the next most +obvious), so multiple parts must cooperate in order to meet the +ultimate requirements. + +:mps:tag:`req.attr.time.overhead` Time overhead constraint? + +.. note:: + + How can there be a time "overhead" on a necessary component? David + Jones, 1999-06-23. + + +Architecture +------------ + +Statics +....... + +:mps:tag:`static` There is no higher-level data structure than a arena, so in +order to support several arenas, we have to have some static data in +impl.c.arena. See impl.c.arena.static. + +:mps:tag:`static.init` All the static data items are initialized when the +first arena is created. + +:mps:tag:`static.serial` ``arenaSerial`` is a static :c:type:`Serial`, containing +the serial number of the next arena to be created. The serial of any +existing arena is less than this. + +:mps:tag:`static.ring` ``arenaRing`` is the sentinel of the ring of arenas. + +:mps:tag:`static.ring.init` ``arenaRingInit`` is a :c:type:`Bool` showing whether +the ring of arenas has been initialized. + +:mps:tag:`static.ring.lock` The ring of arenas has to be locked when +traversing the ring, to prevent arenas being added or removed. This is +achieved by using the (non-recursive) global lock facility, provided +by the lock module. + +:mps:tag:`static.check` The statics are checked each time any arena is +checked. + + +Arena classes +............. + +.. c:type:: mps_arena_s *Arena + +:mps:tag:`class` The :c:type:`Arena` data structure is designed to be subclassable +(see design.mps.protocol(0)). Clients can select what arena class +they'd like when instantiating one with :c:func:`mps_arena_create()`. The +arguments to :c:func:`mps_arena_create()` are class-dependent. + +:mps:tag:`class.init` However, the generic :c:func:`ArenaInit()` is called from the +class-specific method, rather than vice versa, because the method is +responsible for allocating the memory for the arena descriptor and the +arena lock in the first place. Likewise, :c:func:`ArenaFinish()` is called +from the finish method. + +:mps:tag:`class.fields` The ``alignment`` (for tract allocations) and +``zoneShift`` (for computing zone sizes and what zone an address is +in) fields in the arena are the responsibility of the each class, and +are initialized by the ``init`` method. The responsibility for +maintaining the ``commitLimit``, ``spareCommitted``, and +``spareCommitLimit`` fields is shared between the (generic) arena and +the arena class. ``commitLimit`` (see :mps:ref:`.commit-limit`) is changed by +the generic arena code, but arena classes are responsible for ensuring +the semantics. For ``spareCommitted`` and ``spareCommitLimit`` see +:mps:ref:`.spare-committed` below. + +:mps:tag:`class.abstract` The basic arena class (:c:type:`AbstractArenaClass`) is +abstract and must not be instantiated. It provides little useful +behaviour, and exists primarily as the root of the tree of arena +classes. Each concrete class must specialize each of the class method +fields, with the exception of the describe method (which has a trivial +implementation) and the ``extend``, ``retract`` and +``spareCommitExceeded`` methods which have non-callable methods for +the benefit of arena classes which don't implement these features. + +:mps:tag:`class.abstract.null` The abstract class does not provide dummy +implementations of those methods which must be overridden. Instead +each abstract method is initialized to :c:macro:`NULL`. + + +Tracts +...... + +:mps:tag:`tract` The arena allocation function :c:func:`ArenaAlloc()` allocates a +block of memory to pools, of a size which is aligned to the arena +alignment. Each alignment unit (grain) of allocation is represented by +a tract. Tracts are the hook on which the segment module is +implemented. Pools which don't use segments may use tracts for +associating their own data with each allocation grain. + +:mps:tag:`tract.structure` The tract structure definition looks like this:: + + typedef struct TractStruct { /* Tract structure */ + Pool pool; /* MUST BE FIRST (design.mps.arena.tract.field.pool) */ + void *p; /* pointer for use of owning pool */ + Addr base; /* Base address of the tract */ + TraceSet white : TRACE_MAX; /* traces for which tract is white */ + unsigned int hasSeg : 1; /* does tract have a seg in p? */ + } TractStruct; + +:mps:tag:`tract.field.pool` The pool field indicates to which pool the tract +has been allocated (:mps:ref:`.req.fun.trans.pool`). Tracts are only valid +when they are allocated to pools. When tracts are not allocated to +pools, arena classes are free to reuse tract objects in undefined +ways. A standard technique is for arena class implementations to +internally describe the objects as a union type of :c:type:`TractStruct` and +some private representation, and to set the pool field to :c:macro:`NULL` +when the tract is not allocated. The pool field must come first so +that the private representation can share a common prefix with +:c:type:`TractStruct`. This permits arena classes to determine from their +private representation whether such an object is allocated or not, +without requiring an extra field. + +:mps:tag:`tract.field.p` The ``p`` field is used by pools to associate tracts +with other data (:mps:ref:`.req.fun.trans.arbitrary`). It's used by the +segment module to indicate which segment a tract belongs to. If a pool +doesn't use segments it may use the ``p`` field for its own purposes. +This field has the non-specific type ``(void *)`` so that pools can +use it for any purpose. + +:mps:tag:`tract.field.hasSeg` The ``hasSeg`` bit-field is a Boolean which +indicates whether the ``p`` field is being used by the segment module. +If this field is :c:macro:`TRUE`, then the value of ``p`` is a :c:type:`Seg`. +``hasSeg`` is typed as an ``unsigned int``, rather than a :c:type:`Bool`. +This ensures that there won't be sign conversion problems when +converting the bit-field value. + +:mps:tag:`tract.field.base` The base field contains the base address of the +memory represented by the tract. + +:mps:tag:`tract.field.white` The white bit-field indicates for which traces +the tract is white (:mps:ref:`.req.fun.trans.white`). This information is also +stored in the segment, but is duplicated here for efficiency during a +call to ``TraceFix`` (see design.mps.trace.fix). + +:mps:tag:`tract.limit` The limit of the tract's memory may be determined by +adding the arena alignment to the base address. + +:mps:tag:`tract.iteration` Iteration over tracts is described in +design.mps.arena.tract-iter(0). + +.. c:function:: Bool TractOfAddr(Tract *tractReturn, Arena arena, Addr addr) + +:mps:tag:`tract.if.tractofaddr` The function :c:func:`TractOfAddr()` finds the tract +corresponding to an address in memory. (See :mps:ref:`.req.fun.trans`.) + +If ``addr`` is an address which has been allocated to some pool, then +:c:func:`TractOfAddr()` returns :c:macro:`TRUE`, and sets ``*tractReturn`` to the +tract corresponding to that address. Otherwise, it returns :c:macro:`FALSE`. +This function is similar to :c:func:`TractOfBaseAddr()` (see +design.mps.arena.tract-iter.if.contig-base) but serves a more general +purpose and is less efficient. + +:mps:tag:`tract.if.TRACT_OF_ADDR` :c:func:`TRACT_OF_ADDR()` is a macro version of +:c:func:`TractOfAddr()`. It's provided for efficiency during a call to +:c:func:`TraceFix()` (see design.mps.trace.fix.tractofaddr). + + +Control pool +............ + +:mps:tag:`pool` Each arena has a "control pool", +``arena->controlPoolStruct``, which is used for allocating MPS control +data structures by calling :c:func:`ControlAlloc()`. + + +Polling +....... + +:mps:tag:`poll` :c:func:`ArenaPoll()` is called "often" by other code (for instance, +on buffer fill or allocation). It is the entry point for doing tracing +work. If the polling clock exceeds a set threshold, and we're not +already doing some tracing work (that is, ``insidePoll`` is not set), +it calls :c:func:`TracePoll()` on all busy traces. + +:mps:tag:`poll.size` The actual clock is ``arena->fillMutatorSize``. This is +because internal allocation is only significant when copy segments are +being allocated, and we don't want to have the pause times to shrink +because of that. There is no current requirement for the trace rate to +guard against running out of memory. + +.. note:: + + Clearly it really ought to: we have a requirement to not run out + of memory (see req.dylan.prot.fail-alloc, req.dylan.prot.consult), + and emergency tracing should not be our only story. David Jones, + 1999-06-22. + +:c:func:`BufferEmpty()` is not taken into account, because the splinter will +rarely be useable for allocation and we are wary of the clock running +backward. + +:mps:tag:`poll.clamp` Polling is disabled when the arena is "clamped", in +which case ``arena->clamped`` is :c:macro:`TRUE`. Clamping the arena prevents +background tracing work, and further new garbage collections from +starting. Clamping and releasing are implemented by the :c:func:`ArenaClamp()` +and :c:func:`ArenaRelease()` methods. + +:mps:tag:`poll.park` The arena is "parked" by clamping it, then polling until +there are no active traces. This finishes all the active collections +and prevents further collection. Parking is implemented by the +:c:func:`ArenaPark()` method. + + +Commit limit +............ + +:mps:tag:`commit-limit` The arena supports a client configurable "commit +limit" which is a limit on the total amount of committed memory. The +generic arena structure contains a field to hold the value of the +commit limit and the implementation provides two functions for +manipulating it: :c:func:`ArenaCommitLimit()` to read it, and +:c:func:`ArenaSetCommitLimit()` to set it. Actually abiding by the contract of +not committing more memory than the commit limit is left up to the +individual arena classes. + +:mps:tag:`commit-limit.err` When allocation from the arena would otherwise +succeed but cause the MPS to use more committed memory than specified +by the commit limit :c:func:`ArenaAlloc()` should refuse the request and +return ``ResCOMMIT_LIMIT``. + +:mps:tag:`commit-limit.err.multi` In the case where an :c:func:`ArenaAlloc()` request +cannot be fulfilled for more than one reason including exceeding the +commit limit then class implementations should strive to return a +result code other than ``ResCOMMIT_LIMIT``. That is, +``ResCOMMIT_LIMIT`` should only be returned if the *only* reason for +failing the :c:func:`ArenaAlloc()` request is that the commit limit would be +exceeded. The client documentation allows implementations to be +ambiguous with respect to which result code in returned in such a +situation however. + + +Spare committed (aka "hysteresis") +.................................. + +:mps:tag:`spare-committed` See :c:func:`mps_arena_spare_committed()`. The generic +arena structure contains two fields for the spare committed memory +fund: ``spareCommitted`` records the total number of spare committed +bytes; ``spareCommitLimit`` records the limit (set by the user) on the +amount of spare committed memory. ``spareCommitted`` is modified by +the arena class but its value is used by the generic arena code. There +are two uses: a getter function for this value is provided through the +MPS interface (:c:func:`mps_arena_spare_commit_limit_set()`), and by the +:c:func:`SetSpareCommitLimit()` function to determine whether the amount of +spare committed memory needs to be reduced. ``spareCommitLimit`` is +manipulated by generic arena code, however the associated semantics +are the responsibility of the class. It is the class's responsibility +to ensure that it doesn't use more spare committed bytes than the +value in ``spareCommitLimit``. + +:mps:tag:`spare-commit-limit` The function :c:func:`ArenaSetSpareCommitLimit()` sets +the ``spareCommitLimit`` field. If the limit is set to a value lower +than the amount of spare committed memory (stored in +``spareCommitted``) then the class specific function +``spareCommitExceeded`` is called. + + +Locks +..... + +:mps:tag:`lock.ring` :c:func:`ArenaAccess()` is called when we fault on a barrier. +The first thing it does is claim the non-recursive global lock to +protect the arena ring (see design.mps.lock(0)). + +:mps:tag:`lock.arena` After the arena ring lock is claimed, :c:func:`ArenaEnter()` is +called on one or more arenas. This claims the lock for that arena. +When the correct arena is identified or we run out of arenas, the lock +on the ring is released. + +:mps:tag:`lock.avoid` Deadlocking is avoided as described below: + +:mps:tag:`lock.avoid.mps` Firstly we require the MPS not to fault (that is, +when any of these locks are held by a thread, that thread does not +fault). + +:mps:tag:`lock.avoid.thread` Secondly, we require that in a multi-threaded +system, memory fault handlers do not suspend threads (although the +faulting thread will, of course, wait for the fault handler to +finish). + +:mps:tag:`lock.avoid.conflict` Thirdly, we avoid conflicting deadlock between +the arena and global locks by ensuring we never claim the arena lock +when the recursive global lock is already held, and we never claim the +binary global lock when the arena lock is held. + + +Location dependencies +..................... + +:mps:tag:`ld` Location dependencies use fields in the arena to maintain a +history of summaries of moved objects, and to keep a notion of time, +so that the staleness of location dependency can be determined. + + +Finalization +............ + +:mps:tag:`final` There is a pool which is optionally (and dynamically) +instantiated to implement finalization. The fields ``finalPool`` and +``isFinalPool`` are used. + + +Implementation +-------------- + + +Tract cache +........... + +:mps:tag:`tract.cache` When tracts are allocated to pools by :c:func:`ArenaAlloc()`, +the first tract of the block and it's base address are cached in arena +fields ``lastTract`` and ``lastTractBase``. The function +:c:func:`TractOfBaseAddr()` (see design.mps.arena.tract-iter.if.block-base(0)) +checks against these cached values and only calls the class method on +a cache miss. This optimizes for the common case where a pool +allocates a block and then iterates over all its tracts (for example, +to attach them to a segment). + +:mps:tag:`tract.uncache` When blocks of memory are freed by pools, +:c:func:`ArenaFree()` checks to see if the cached value for the most recently +allocated tract (see :mps:ref:`.tract.cache`) is being freed. If so, the cache +is invalid, and must be reset. The ``lastTract`` and ``lastTractBase`` +fields are set to :c:macro:`NULL`. + + +Control pool +............ + +:mps:tag:`pool.init` The control pool is initialized by a call to +:c:func:`PoolInit()` during :c:func:`ArenaCreate()`. + +:mps:tag:`pool.ready` All the other fields in the arena are made checkable +before calling :c:func:`PoolInit()`, so :c:func:`PoolInit()` can call +``ArenaCheck(arena)``. The pool itself is, of course, not checkable, +so we have a field ``arena->poolReady``, which is false until after +the return from :c:func:`PoolInit()`. :c:func:`ArenaCheck()` only checks the pool if +``poolReady``. + + +Traces +...... + +:mps:tag:`trace` ``arena->trace[ti]`` is valid if and only if +``TraceSetIsMember(arena->busyTraces, ti)``. + +:mps:tag:`trace.create` Since the arena created by :c:func:`ArenaCreate()` has +``arena->busyTraces = TraceSetEMPTY``, none of the traces are +meaningful. + +:mps:tag:`trace.invalid` Invalid traces have signature ``SigInvalid``, which +can be checked. + + +Polling +....... + +:mps:tag:`poll.fields` There are three fields of a arena used for polling: +``pollThreshold``, ``insidePoll``, and ``clamped`` (see above). +``pollThreshold`` is the threshold for the next poll: it is set at the +end of :c:func:`ArenaPoll()` to the current polling time plus +:c:macro:`ARENA_POLL_MAX`. + + +Location dependencies +..................... + +:mps:tag:`ld.epoch` ``arena->epoch`` is the "current epoch". This is the +number of 'flips' of traces in the arena since the arena was created. +From the mutator's point of view locations change atomically at flip. + +:mps:tag:`ld.history` ``arena->history`` is an array of :c:macro:`ARENA_LD_LENGTH` +elements of type ``RefSet``. These are the summaries of moved objects +since the last :c:macro:`ARENA_LD_LENGTH` epochs. If ``e`` is one of these +recent epochs, then :: + + arena->history[e % ARENA_LD_LENGTH] + +is a summary of (the original locations of) objects moved since epoch +``e``. + +:mps:tag:`ld.prehistory` ``arena->prehistory`` is a ``RefSet`` summarizing +the original locations of all objects ever moved. When considering +whether a really old location dependency is stale, it is compared with +this summary. + + +Roots +..... + +:mps:tag:`root-ring` The arena holds a member of a ring of roots in the +arena. It holds an incremental serial which is the serial of the next +root. + + diff --git a/mps/manual/html/_sources/design/arenavm.txt b/mps/manual/html/_sources/design/arenavm.txt new file mode 100644 index 00000000000..b4f3638928c --- /dev/null +++ b/mps/manual/html/_sources/design/arenavm.txt @@ -0,0 +1,206 @@ +.. _design-arenavm: + + +.. index:: + pair: virtual memory arena; design + pair: VM arena; design + + +Virtual Memory Arena +==================== + +.. mps:prefix:: design.mps.arena.vm + pair: virtual memory arena; design + pair: VM arena; design + + +Introduction +------------ + +:mps:tag:`intro` This document describes the detailed design of the Virtual +Memory Arena Class of the Memory Pool System. The VM Arena Class is +just one class available in the MPS. The generic arena part is +described in design.mps.arena. + + +Overview +-------- + +:mps:tag:`overview` VM arenas provide blocks of memory to all other parts of +the MPS in the form of "tracts" using the virtual mapping interface +(design.mps.vm) to the operating system. The VM Arena Class is not +expected to be provided on platforms that do not have virtual memory +(like MacOS, os.s7(1)). + +:mps:tag:`overview.gc` The VM Arena Class provides some special services on +these blocks in order to facilitate garbage collection: + +:mps:tag:`overview.gc.zone` Allocation of blocks with specific zones. This +means that the generic fix function (design.mps.fix) can use a fast +refset test to eliminate references to addresses that are not in the +condemned set. This assumes that a pool class that uses this placement +appropriately is being used (such as the generation placement policy +used by AMC: see design.mps.poolamc(1)) and that the pool selects the +condemned sets to coincide with zone stripes. + +:mps:tag:`overview.gc.tract` A fast translation from addresses to tract. +(See design.mps.arena.req.fun.trans) + + +Notes +----- + +:mps:tag:`note.refset` Some of this document simply assumes that RefSets +(see the horribly incomplete design.mps.refset) have been chosen as +the solution for design.mps.arena.req.fun.set. It's a lot simpler that +way. Both to write and understand. + + +Requirements +------------ + +Most of the requirements are in fact on the generic arena (see +design.mps.arena.req). However, many of those requirements can only be +met by a suitable arena class design. + +Requirements particular to this arena class: + +Placement +......... + +:mps:tag:`req.fun.place` It must be possible for pools to obtain tracts at +particular addresses. Such addresses shall be declared by the pool +specifying what refset zones the tracts should lie in and what refset +zones the tracts should not lie in. It is acceptable for the arena to +not always honour the request in terms of placement if it has run out +of suitable addresses. + +Arena partition +............... + +:mps:tag:`req.fun.set` See design.mps.arena.req.fun.set. The approximation +to sets of address must cooperate with the placement mechanism in the +way required by :mps:ref:`.req.fun.place` (above). + + +Architecture +------------ + +:mps:tag:`arch.memory` The underlying memory is obtained from whatever +Virtual Memory interface (see design.mps.vm). @@@@ Explain why this is +used. + + +Solution ideas +-------------- + +:mps:tag:`idea.grain` Set the arena granularity to the grain provided by the +virtual mapping module. + +:mps:tag:`idea.mem` Get a single large contiguous address area from the +virtual mapping interface and divide that up. + +:mps:tag:`idea.table` Maintain a table with one entry per grain in order to +provide fast mapping (shift and add) between addresses and table +entries. + +:mps:tag:`idea.table.figure` [missing figure] + +:mps:tag:`idea.map` Store the pointers (:mps:ref:`.req.fun.trans`) in the table +directly for every grain. + +:mps:tag:`idea.zones` Partition the managed address space into zones (see +idea.zones) and provide the set approximation as a reference +signature. + +:mps:tag:`idea.first-fit` Use a simple first-fit allocation policy for +tracts within each zone (:mps:ref:`.idea.zones`). Store the freelist in the +table (:mps:ref:`.idea.table`). + +:mps:tag:`idea.base` Store information about each contiguous area (allocated +of free) in the table entry (:mps:ref:`.idea.table`) corresponding to the base +address of the area. + +:mps:tag:`idea.shadow` Use the table (:mps:ref:`.idea.table`) as a "shadow" of the +operating system's page table. Keep information such as last access, +protection, etc. in this table, since we can't get at this information +otherwise. + +:mps:tag:`idea.barrier` Use the table (:mps:ref:`.idea.table`) to implement the +software barrier. Each segment can have a read and/or write barrier +placed on it by each process. (:mps:tag:`idea.barrier.bits` Store a +bit-pattern which remembers which process protected what.) This will +give a fast translation from a barrier-protected address to the +barrier handler via the process table. + +:mps:tag:`idea.demand-table` For a 1 GiB managed address space with a 4 KiB +page size, the table will have 256K-entries. At, say, four words per +entry, this is 4 MiB of table. Although this is only an 0.4%, the +table shouldn't be preallocated or initially it is an infinite +overhead, and with 1 MiB active, it is a 300% overhead! The address +space for the table should be reserved, but the pages for it mapped +and unmapped on demand. By storing the table in a tract, the status of +the table's pages can be determined by looking at it's own entries in +itself, and thus the translation lookup (:mps:ref:`.req.fun.trans`) is slowed +to two lookups rather than one. + +:mps:tag:`idea.pool` Make the Arena Manager a pool class. Arena +initialization becomes pool creation. Tract allocation becomes +:c:func:`PoolAlloc()`. Other operations become class-specific operations on +the "arena pool". + + +Data structures +--------------- + +:mps:tag:`tables` There are two table data structures: a page table, and an +alloc table. + +:mps:tag:`table.page.map` Each page in the VM has a corresponding page table +entry. + +:mps:tag:`table.page.linear` The table is a linear array of PageStruct +entries; there is a simple mapping between the index in the table and +the base address in the VM. Namely: + +- index to base address: ``base-address = arena-base + (index * page-size)`` +- base address to index: ``index = (base-address - arena-base) / page-size`` + +:mps:tag:`table.page.partial` The table is partially mapped on an +"as-needed" basis. The function :c:func:`unusedTablePages()` identifies +entirely unused pages occupied by the page table itself (that is, +those pages of the page table which are occupied by :c:type:`PageStruct` +objects which all describe free pages). Tract allocation and freeing +use this function to map and unmap the page table with no hysteresis. +(There is restriction on the parameters you may pass to +:c:func:`unusedTablePages()`.) + +:mps:tag:`table.page.tract` Each page table entry contains a tract, which is +only valid if it is allocated to a pool. If it is not allocated to a +pool, the fields of the tract are used for other purposes. (See +design.mps.arena.tract.field.pool) + +:mps:tag:`table.alloc` The alloc table is a simple bit table (implemented +using the BT module, design.mps.bt). + +:mps:tag:`table.alloc.map` Each page in the VM has a corresponding alloc +table entry. + +:mps:tag:`table.alloc.semantics` The bit in the alloc table is set iff the +corresponding page is allocated (to a pool). + + +Notes +----- + +:mps:tag:`fig.page` How the pages in the arena area are represented in the +tables. + +[missing figure] + +:mps:tag:`fig.count` How a count table can be used to partially map the page +table, as proposed in request.dylan.170049.sol.map. + +[missing figure] + + diff --git a/mps/manual/html/_sources/design/bt.txt b/mps/manual/html/_sources/design/bt.txt index f8ac21cb720..6690fb5c439 100644 --- a/mps/manual/html/_sources/design/bt.txt +++ b/mps/manual/html/_sources/design/bt.txt @@ -1,6 +1,709 @@ +.. _design-bt: + + .. index:: pair: bit tables; design -.. _design-bt: -.. include:: ../../converted/bt.rst +Bit tables +========== + +.. mps:prefix:: design.mps.bt + + +Introduction +------------ + +:mps:tag:`intro` This is the design of the Bit Tables module. A Bit Table is a +linear array of bits. A Bit Table of length *n* is indexed using an +integer from 0 up to (but not including) *n*. Each bit in a Bit Table +can hold either the value 0 (aka :c:macro:`FALSE`) or 1 (aka :c:macro:`TRUE`). A +variety of operations are provided including: set, reset, and +retrieve, individual bits; set and reset a contiguous range of bits; +search for a contiguous range of reset bits; making a "negative image" +copy of a range. + +:mps:tag:`readership` MPS developers. + + +Definitions +----------- + +:mps:tag:`def.set` **Set** + + Used as a verb meaning to assign the value 1 or :c:macro:`TRUE` to a bit. + Used descriptively to denote a bit containing the value 1. Note 1 + and :c:macro:`TRUE` are synonyms in MPS C code (see + design.mps.type(0).bool.value). + +:mps:tag:`def.reset` **Reset** + + Used as a verb meaning to assign the value 0 or :c:macro:`FALSE` to a + bit. Used descriptively to denote a bit containing the value 0. + Note 0 and :c:macro:`FALSE` are synonyms in MPS C code (see + design.mps.type(0).bool.value). + +.. note:: + + Consider using "fill/empty" or "mark/clear" instead of + "set/reset", set/reset is probably a hangover from drj's z80 + hacking days -- drj 1999-04-26 + +:mps:tag:`def.bt` **Bit Table** + + A Bit Table is a mapping from [0, *n*) to {0,1} for some *n*, + represented as a linear array of bits. + + _`..def.bt.justify`: They are called *bit tables* because a single + bit is used to encode whether the image of a particular integer + under the map is 0 or 1. + +:mps:tag:`def.range` **Range** + + A contiguous sequence of bits in a Bit Table. Ranges are typically + specified as a *base*--*limit* pair where the range includes the + position specified by the base, but excludes that specified by the + limit. The mathematical interval notation for half-open intervals, + [*base*, *limit*), is used. + + + +Requirements +------------ + +:mps:tag:`req.bit` The storage for a Bit Table of *n* bits shall take no more +than a small constant addition to the storage required for *n* bits. +_`..req.bit.why`: This is so that clients can make some predictions +about how much storage their algorithms use. A small constant is +allowed over the minimal for two reasons: inevitable implementation +overheads (such as only being able to allocate storage in multiples of +32 bits), extra storage for robustness or speed (such as signature and +length fields). + +:mps:tag:`req.create` A means to create Bit Tables. :mps:tag:`req.create.why` Obvious. + +:mps:tag:`req.destroy` A means to destroy Bit Tables. _`.req.destroy.why` +Obvious. + +:mps:tag:`req.ops` The following operations shall be supported: + +* :mps:tag:`req.ops.get` **Get**. Get the value of a bit at a specified + index. + +* :mps:tag:`req.ops.set` **Set**. Set a bit at a specified index. + +* :mps:tag:`req.ops.reset` **Reset**. Reset a bit at a specified index. + +:mps:tag:`req.ops.minimal.why` Get, Set, Reset, are the minimal operations. +All possible mappings can be created and inspected using these +operations. + +* :mps:tag:`req.ops.set.range` **SetRange**. Set a range of bits. + :mps:tag:`req.ops.set.range.why` It's expected that clients will often want + to set a range of bits; providing this operation allows the + implementation of the BT module to make the operation efficient. + +* :mps:tag:`req.ops.reset.range` **ResetRange**. Reset a range of + bits. :mps:tag:`req.ops.reset.range.why` as for SetRange, see + :mps:ref:`.req.ops.set.range.why`. + +* :mps:tag:`req.ops.test.range.set` **IsSetRange**. Test whether a range + of bits are all set. :mps:tag:`req.ops.test.range.set.why` Mostly + for checking. For example, often clients will know that a range they + are about to reset is currently all set, they can use this operation + to assert that fact. + +* :mps:tag:`req.ops.test.range.reset` **IsResetRange**. Test whether a + range of bits are all reset. _`.req.ops.test.range.reset.why` + As for IsSetRange, see :mps:ref:`.req.ops.test.range.set.why`. + +* :mps:tag:`req.ops.find` Find a range (which we'll denote [*i*, *j*)) of at + least *L* reset bits that lies in a specified subrange of the entire + Bit Table. Various find operations are required according to the + (additional) properties of the required range: + + * :mps:tag:`req.ops.find.short.low` **FindShortResetRange**. Of all + candidate ranges, find the range with least *j* (find the leftmost + range that has at least *L* reset bits and return just enough of + that). :mps:tag:`req.ops.find.short.low.why` Required by client and VM + arenas to allocate segments. The arenas implement definite + placement policies (such as lowest addressed segment first) so + they need the lowest (or highest) range that will do. It's not + currently useful to allocate segments larger than the requested + size, so finding a short range is sufficient. + + * :mps:tag:`req.ops.find.short.high` **FindShortResetRangeHigh**. Of all + candidate ranges, find the range with greatest *i* (find the + rightmost range that has at least *L* reset bits and return just + enough of that). :mps:tag:`req.ops.find.short.high.why` Required by arenas + to implement a specific segment placement policy (highest + addressed segment first). + + * :mps:tag:`req.ops.find.long.low` **FindLongResetRange**. Of all candidate + ranges, identify the ranges with least *i* and of those find the + one with greatest *j* (find the leftmost range that has at least + *L* reset bits and return all of it). _`.req.ops.find.long.low.why` + Required by the mark and sweep Pool Classes (AMS, AWL, LO) for + allocating objects (filling a buffer). It's more efficient to fill + a buffer with as much memory as is conveniently possible. There's + no strong reason to find the lowest range but it's bound to have + some beneficial (small) cache effect and makes the algorithm more + predictable. + + * :mps:tag:`req.ops.find.long.high` **FindLongResetRangeHigh**. Provided, + but not required, see :mps:ref:`.non-req.ops.find.long.high`. + +* :mps:tag:`req.ops.copy` Copy a range of bits from one Bit Table to another + Bit Table. Various copy operations are required: + + * :mps:tag:`req.ops.copy.simple` Copy a range of bits from one Bit Table to + the same position in another Bit Table. + :mps:tag:`req.ops.copy.simple.why` Required to support copying of the + tables for the "low" segment during segment merging and splitting, + for pools using tables (for example, ``PoolClassAMS``). + + * :mps:tag:`req.ops.copy.offset` Copy a range of bits from one Bit Table to + an offset position in another Bit Table. + :mps:tag:`req.ops.copy.offset.why` Required to support copying of the + tables for the "high" segment during segment merging and + splitting, for pools which support this (currently none, as of + 2000-01-17). + + * :mps:tag:`req.ops.copy.invert` Copy a range of bits from one Bit Table to + the same position in another Bit Table inverting all the bits in + the target copy. :mps:tag:`req.ops.copy.invert.why` Required by colour + manipulation code in ``PoolClassAMS`` and ``PoolClassLO``. + +:mps:tag:`req.speed` Operations shall take no more than a few memory +operations per bit manipulated. :mps:tag:`req.speed.why` Any slower +would be gratuitous. + +:mps:tag:`req.speed.fast` The following operations shall be very fast: + +* :mps:tag:`req.speed.fast.find.short` FindShortResRange (the + operation used to meet :mps:ref:`.req.ops.find.short.low`) + FindShortResRangeHigh (the operation used to meet + :mps:ref:`.req.ops.find.short.high`). + + :mps:tag:`req.speed.fast.find.short.why` These two are used by the client + arena (design.mps.arena.client) and the VM arena + (design.mps.arena.vm) for finding segments in page tables. The + operation will be used sufficiently often that its speed will + noticeably affect the overall speed of the MPS. They will be called + with a length equal to the number of pages in a segment. Typical + values of this length depend on the pool classes used and their + configuration, but we can expect length to be small (1 to 16) + usually. We can expect the Bit Table to be populated densely where + it is populated at all, that is set bits will tend to be clustered + together in subranges. + +* :mps:tag:`req.speed.fast.find.long` FindLongResRange (the operation + used to meet :mps:ref:`.req.ops.find.long.low`) + + :mps:tag:`req.speed.fast.find.long.why` Used in the allocator for + ``PoolClassAWL`` (design.mps.poolawl(1)), ``PoolClassAMS`` + (design.mps.poolams(2)), ``PoolClassEPVM`` (design.mps.poolepvm(0)). + Of these AWL and EPVM have speed requirements. For AWL the length of + range to be found will be the length of a Dylan table in words. + According to mail.tony.1999-05-05.11-36(0), only + objects are allocated in AWL (though not all objects + are allocated in AWL), and the mean length of an + object is 486 Words. No data for EPVM alas. + +:mps:tag:`req.speed.fast.other.why` We might expect mark and sweep pools to +make use of Bit Tables, the MPS has general requirements to support +efficient mark and sweep pools, so that imposes general speed +requirements on Bit Tables. + + +Non requirements +---------------- + +The following are not requirements but the current design could +support them with little modification or does support them. Often they +used to be requirements, but are no longer, or were added +speculatively or experimentally but aren't currently used. + +* :mps:tag:`non-req.ops.test.range.same` **RangesSame**. Test whether two + ranges that occupy the same positions in different Bit Tables are + the same. This used to be required by ``PoolClassAMS``, but is no + longer. Currently (1999-05-04) the functionality still exists. + +* :mps:tag:`non-req.ops.find.long.high` **FindLongResetRangeHigh**. (see + :mps:ref:`.req.ops.find`) Of all candidate ranges, identify the ranges with + greatest *j* and of those find the one with least *i* (find the + rightmost range that has at least *L* reset bits and return all of + it). Provided for symmetry but only currently used by the BT tests + and ``cbstest.c``. + + +Background +---------- + +:mps:tag:`background` Originally Bit Tables were used and implemented +by ``PoolClassLO`` (design.mps.poollo). It was +decided to lift them out into a separate module when designing the +Pool to manage Dylan Weak Tables which is also a mark and sweep pool +and will make use of Bit Tables (see design.mps.poolawl). +:mps:tag:`background.analysis` analysis.mps.bt(0) contains +some of the analysis of the design decisions that were and were not +made in this document. + + +Clients +------- + +:mps:tag:`clients` Bit Tables are used throughout the MPS but the important +uses are in the client and VM arenas (design.mps.arena.client(0) and +design.mps.arena.vm(1)) a bit table is used to record whether each +page is free or not; several pool classes (``PoolClassLO``, +``PoolClassEPVM``, ``PoolClassAMS``) use bit tables to record which +locations are free and also to store colour. + + +Overview +-------- + +:mps:tag:`over` Mostly, the design is as simple as possible. The significant +complications are iteration (see :mps:ref:`.iteration` below) and searching +(see :mps:ref:`.fun.find-res-range` below) because both of these are required +to be fast. + + +Interface +--------- + +.. c:type:: Word *BT + +:mps:tag:`if.representation.abstract` A Bit Table is represented by the type +:c:type:`BT`. + +:mps:tag:`if.declare` The module declares a type :c:type:`BT` and a prototype for +each of the functions below. The type is declared in impl.h.mpmtypes, +the prototypes are declared in impl.h.mpm. Some of the functions are +in fact implemented as macros in the usual way +(doc.mps.ref-man.if-conv(0).macro.std). + +:mps:tag:`if.general.index` Many of the functions specified below take +indexes. If otherwise unspecified an index must be in the interval [0, +*n*) (note, up to, but not including, *n*) where *n* is the number of +bits in the relevant Bit Table (as passed to the :c:func:`BTCreate()` +function). + +:mps:tag:`if.general.range` Where a range is specified by two indexes (*base* +and *limit*), the index *base*, which specifies the beginning of the +range, must be in the interval [0, *n*), and the index *limit*, which +specifies the end of the range, must be in the interval [1, *n*] (note +can be *n*), and *base* must be strictly less than *limit* (empty +ranges are not allowed). Sometimes *i* and *j* are used instead of +*base* and *limit*. + +.. c:function:: Res BTCreate(BT *btReturn, Arena arena, Count n) + +:mps:tag:`if.create` Attempts to create a table of length ``n`` in the arena +control pool, putting the table in ``*btReturn``. Returns ``ResOK`` if +and only if the table is created OK. The initial values of the bits in +the table are undefined (so the client should probably call +:c:func:`BTResRange()` on the entire range before using the :c:type:`BT`). Meets +:mps:ref:`.req.create`. + +.. c:function:: void BTDestroy(BT t, Arena arena, Count n) + +:mps:tag:`if.destroy` Destroys the table ``t``, which must have been created +with :c:func:`BTCreate()`. The value of argument ``n`` must be same as the +value of the argument passed to :c:func:`BTCreate()`. Meets +:mps:ref:`.req.destroy`. + +.. c:function:: size_t BTSize(Count n) + +:mps:tag:`if.size` ``BTSize(n)`` returns the number of bytes needed for a Bit +Table of ``n`` bits. :c:func:`BTSize()` is a macro, but ``(BTSize)(n)`` will +assert if ``n`` exceeds ``COUNT_MAX - MPS_WORD_WIDTH + 1``. This is +used by clients that allocate storage for the :c:type:`BT` themselves. +Before :c:func:`BTCreate()` and :c:func:`BTDestroy()` were implemented that was the +only way to allocate a Bit Table, but is now deprecated. + +.. c:function:: int BTGet(BT t, Index i) + +:mps:tag:`if.get` ``BTGet(t, i)`` returns the ``i``-th bit of the table ``t`` +(that is, the image of ``i`` under the mapping). Meets +:mps:ref:`.req.ops.get`. + +.. c:function:: void BTSet(BT t, Index i) + +:mps:tag:`if.set` ``BTSet(t, i)`` sets the ``i``-th bit of the table ``t`` (to +1). ``BTGet(t, i)`` will now return 1. Meets :mps:ref:`.req.ops.set`. + +.. c:function:: void BTRes(BT t, Index i) + +:mps:tag:`if.res` ``BTRes(t, i)`` resets the ``i``-th bit of the table ``t`` +(to 0). ``BTGet(t, i)`` will now return 0. Meets :mps:ref:`.req.ops.reset`. + +.. c:function:: void BTSetRange(BT t, Index base, Index limit) + +:mps:tag:`if.set-range` ``BTSetRange(t, base, limit)`` sets the range of bits +[``base``, ``limit``) in the table ``t``. ``BTGet(t, x)`` will now +return 1 for ``base`` ≤ ``x`` < ``limit``. Meets +:mps:ref:`.req.ops.test.range.set`. + +.. c:function:: void BTResRange(BT t, Index base, Index limit) + +:mps:tag:`if.res-range` ``BTResRange(t, base, limit)`` resets the range of +bits [``base``, ``limit``) in the table ``t``. ``BTGet(t, x)`` will +now return 0 for ``base`` ≤ ``x`` < ``limit``. Meets +:mps:ref:`.req.ops.test.range.reset`. + +.. c:function:: Bool BTIsSetRange(BT bt, Index base, Index limit) + +:mps:tag:`if.test.range.set` Returns :c:macro:`TRUE` if all the bits in the range +[``base``, ``limit``) are set, :c:macro:`FALSE` otherwise. Meets +:mps:ref:`.req.ops.test.range.set`. + +.. c:function:: Bool BTIsResRange(BT bt, Index base, Index limit) + +:mps:tag:`if.test.range.reset` Returns :c:macro:`TRUE` if all the bits in the range +[``base``, ``limit``) are reset, :c:macro:`FALSE` otherwise. Meets +:mps:ref:`.req.ops.test.range.reset`. + +``Bool BTRangesSame(BT BTx, BT BTy, Index base, Index limit);`` + +:mps:tag:`if.test.range.same` returns :c:macro:`TRUE` if ``BTGet(BTx,i)`` equals +``BTGet(BTy,i)`` for ``i`` in [``base``, ``limit``), and :c:macro:`FALSE` +otherwise. Meets :mps:ref:`.non-req.ops.test.range.same`. + +:mps:tag:`if.find.general` There are four functions (below) to find reset +ranges. All the functions have the same prototype (for symmetry):: + + Bool find(Index *baseReturn, Index *limitReturn, + BT bt, + Index searchBase, Index searchLimit, + Count length); + +where ``bt`` is the Bit Table in which to search. ``searchBase`` and +``searchLimit`` specify a subset of the Bit Table to use, the +functions will only find ranges that are subsets of [``searchBase``, +``searchLimit``) (when set, ``*baseReturn`` will never be less than +``searchBase`` and ``*limitReturn`` will never be greater than +``searchLimit``). ``searchBase`` and ``searchLimit`` specify a range +that must conform to the general range requirements for a range [*i*, +*j*), as per :mps:ref:`.if.general.range` modified appropriately. ``length`` +is the number of contiguous reset bits to find; it must not be bigger +than ``searchLimit - searchBase`` (that would be silly). If a suitable +range cannot be found the function returns :c:macro:`FALSE` (0) and leaves +``*baseReturn`` and ``*limitReturn`` untouched. If a suitable range is +found then the function returns the range's base in ``*baseReturn`` +and its limit in ``*limitReturn`` and returns :c:macro:`TRUE` (1). + +.. c:function:: Bool BTFindShortResRange(Index *baseReturn, Index *limitReturn, BT bt, Index searchBase, Index searchLimit, Count length) + +:mps:tag:`if.find-short-res-range` Finds a range of reset bits in the table, +starting at ``searchBase`` and working upwards. This function is +intended to meet :mps:ref:`.req.ops.find.short.low` so it will find the +leftmost range that will do, and never finds a range longer than the +requested length (the intention is that it will not waste time +looking). + +.. c:function:: Bool BTFindShortResRangeHigh(Index *baseReturn, Index *limitReturn, BT bt, Index searchBase, Index searchLimit, Count length) + +:mps:tag:`if.find-short-res-range-high` Finds a range of reset bits in the +table, starting at ``searchLimit`` and working downwards. This +function is intended to meet :mps:ref:`.req.ops.find.short.high` so it will +find the rightmost range that will do, and never finds a range longer +than the requested length. + +.. c:function:: Bool BTFindLongResRange(Index *baseReturn, Index *limitReturn, BT bt, Index searchBase, Index searchLimit, Count length) + +:mps:tag:`if.find-long-res-range` Finds a range of reset bits in the table, +starting at ``searchBase`` and working upwards. This function is +intended to meet :mps:ref:`.req.ops.find.long.low` so it will find the +leftmost range that will do and returns all of that range (which can +be longer than the requested length). + +.. c:function:: Bool BTFindLongResRangeHigh(Index *baseReturn, Index *limitReturn, BT bt, Index searchBase, Index searchLimit, Count length) + +:mps:tag:`if.find-long-res-range-high` Finds a range of reset bits in the +table, starting at ``searchLimit`` and working downwards. This +function is intended to meet :mps:ref:`.req.ops.find.long.high` so it will +find the rightmost range that will do and returns all that range +(which can be longer than the requested length). + +.. c:function:: void BTCopyRange(BT fromBT, BT toBT, Index base, Index limit) + +:mps:tag:`if.copy-range` Overwrites the ``i``-th bit of ``toBT`` with the +``i``-th bit of ``fromBT``, for all ``i`` in [``base``, ``limit``). +Meets :mps:ref:`.req.ops.copy.simple`. + +.. c:function:: void BTCopyOffsetRange(BT fromBT, BT toBT, Index fromBase, Index fromLimit, Index toBase, Index toLimit) + +:mps:tag:`if.copy-offset-range` Overwrites the ``i``-th bit of ``toBT`` with +the ``j``-th bit of ``fromBT``, for all ``i`` in [``toBase``, +``toLimit``) and corresponding ``j`` in [``fromBase``, ``fromLimit``). +Each of these ranges must be the same size. This might be +significantly less efficient than :c:func:`BTCopyRange()`. Meets +:mps:ref:`.req.ops.copy.offset`. + +.. c:function:: void BTCopyInvertRange(BT fromBT, BT toBT, Index base, Index limit) + +:mps:tag:`if.copy-invert-range` Overwrites the ``i``-th bit of ``toBT`` with +the inverse of the ``i``-th bit of ``fromBT``, for all ``i`` in +[``base``, ``limit``). Meets :mps:ref:`.req.ops.copy.invert`. + + +Detailed design +--------------- + + +Data structures +............... + +:mps:tag:`datastructure` Bit Tables will be represented as (a pointer to) an +array of :c:type:`Word`. A plain array is used instead of the more usual +design convention of implementing an abstract data type as a structure +with a signature (see guide.impl.c.adt(0)). +:mps:tag:`datastructure.words.justify` The type :c:type:`Word` is used as it will +probably map to the object that can be most efficiently accessed on +any particular platform. :mps:tag:`datastructure.non-adt.justify` The usual +abstract data type convention was not followed because (i) The initial +design (drj) was lazy, (ii) Bit Tables are more likely to come in +convenient powers of two with the extra one or two words overhead. +However, the loss of checking is severe. Perhaps it would be better to +use the usual abstract data type style. + + +Functions +......... + +:mps:tag:`fun.size` :c:func:`BTSize()`. Since a Bit Table is an array of :c:type:`Word`, the +size of a Bit Table of *n* bits is simply the number of words that it +takes to store *n* bits times the number of bytes in a word. This is +``ceiling(n/MPS_WORD_WIDTH)*sizeof(Word).`` :mps:tag:`fun.size.justify` Since +there can be at most ``MPS_WORD_WIDTH - 1`` unused bits in the entire +table, this satisfies :mps:ref:`.req.bit`. + +:mps:tag:`index` The designs for the following functions use a decomposition +of a bit-index, ``i``, into two parts, ``iw``, ``ib``. + +* :mps:tag:`index.word` ``iw`` is the "word-index" which is the index into the + word array of the word that contains the bit referred to by the + bit-index. ``iw = i / MPS_WORD_WIDTH``. Since :c:macro:`MPS_WORD_WIDTH` is + a power of two, this is the same as ``iw = i >> MPS_WORD_SHIFT``. + The latter expression is used in the code. :mps:tag:`index.word.justify` The + compiler is more likely to generate good code without the divide. + +* :mps:tag:`index.sub-word` ``ib`` is the "sub-word-index" which is the index + of the bit referred to by the bit-index in the above word. ``ib = i + % MPS_WORD_WIDTH``. Since :c:macro:`MPS_WORD_WIDTH` is a power of two, this + is the same as ``ib = i & ~((Word)-1<>5) + (i&31); + } + +.. c:function:: ACT_ON_RANGE(Index base, Index limit, single_action, bits_action, word_action) +.. c:function:: ACT_ON_RANGE_HIGH(Index base, Index limit, single_action, bits_action, word_action) + +:mps:tag:`iteration` Many of the following functions involve iteration over +ranges in a Bit Table. This is performed on whole words rather than +individual bits, whenever possible (to improve speed). This is +implemented internally by the macros :c:func:`ACT_ON_RANGE()` and +:c:func:`ACT_ON_RANGE_HIGH()` for iterating over the range forwards and +backwards respectively. These macros do not form part of the interface +of the module, but are used extensively in the implementation. The +macros are often used even when speed is not an issue because it +simplifies the implementation and makes it more uniform. The iteration +macros take the parameters ``base``, ``limit``, ``single_action``, +``bits_action``, and ``word_action``: + +* ``base`` and ``limit`` are of type :c:type:`Index` and define the range of + the iteration. + +* ``single_action`` is the name of a macro which will be used for + iterating over bits in the table individually. This macro must take + a single :c:type:`Index` parameter corresponding to the index for the bit. + The expansion of the macro must not contain ``break`` or + ``continue`` because it will be called from within a loop from the + expansion of :c:func:`ACT_ON_RANGE()`. + +* ``bits_action`` is the name of a macro which will be used for + iterating over part-words. This macro must take parameters + ``wordIndex``, ``base``, ``limit`` where ``wordIndex`` is the index + into the array of words, and ``base`` and ``limit`` define a range + of bits within the indexed word. + +* ``word_action`` is the name of a macro which will be used for + iterating over whole-words. This macro must take the single + parameter ``wordIndex`` which is the index of the whole-word in the + array. The expansion of the macro must not contain ``break`` or + ``continue`` because it will be called from within a loop from the + expansion of :c:func:`ACT_ON_RANGE()`. + +:mps:tag:`iteration.exit` The expansion of the ``single_action``, +``bits_action``, and ``word_action`` macros is allowed to contain +``return`` or ``goto`` to terminate the iteration early. This is used +by the test (:mps:ref:`.fun.test.range.set`) and find (:mps:ref:`.fun.find`) +operations. + +:mps:tag:`iteration.small` If the range is sufficiently small only the +``single_action`` macro will be used, as this is more efficient in +practice. The choice of what constitutes a small range is made +entirely on the basis of experimental performance results (and +currently, 1999-04-27, a "small range" is 6 bits or fewer. See +change.mps.epcore.brisling.160181 for some justification). Otherwise +(for a bigger range) ``bits_action`` is used on the part words at +either end of the range (or the whole of the range it if it fits in a +single word), and ``word_action`` is used on the words that comprise +the inner portion of the range. + +The implementation of :c:func:`ACT_ON_RANGE()` (and :c:func:`ACT_ON_RANGE_HIGH()`) is +simple enough. It decides which macros it should invoke and invokes +them. ``single_action`` and ``word_action`` are invoked inside loops. + +:mps:tag:`fun.get` :c:func:`BTGet()`. The bit-index will be converted in the usual +way, see :mps:ref:`.index`. The relevant :c:type:`Word` will be read out of the Bit +Table and shifted right by the sub-:c:type:`Word` index (this brings the +relevant bit down to the least significant bit of the :c:type:`Word`), the +:c:type:`Word` will then be masked with 1, producing the answer. + +:mps:tag:`fun.set` :c:func:`BTSet()`. + +:mps:tag:`fun.res` :c:func:`BTRes()`. + +In both :c:func:`BTSet()` and :c:func:`BTRes()` a mask is constructed by shifting 1 +left by the sub-word-index (see :mps:ref:`.index`). For :c:func:`BTSet()` the mask is +or-ed into the relevant word (thereby setting a single bit). For +:c:func:`BTRes()` the mask is inverted and and-ed into the relevant word +(thereby resetting a single bit). + +:mps:tag:`fun.set-range` :c:func:`BTSetRange()`. :c:func:`ACT_ON_RANGE()` (see :mps:ref:`.iteration` +above) is used with macros that set a single bit (using :c:func:`BTSet()`), +set a range of bits in a word, and set a whole word. + +:mps:tag:`fun.res-range` :c:func:`BTResRange()` This is implemented similarly to +:c:func:`BTSetRange()` (:mps:ref:`.fun.set-range`) except using :c:func:`BTRes()` and reverse +bit-masking logic. + +:mps:tag:`fun.test.range.set` :c:func:`BTIsSetRange()`. :c:func:`ACT_ON_RANGE()` (see +:mps:ref:`.iteration` above) is used with macros that test whether all the +relevant bits are set; if some of the relevant bits are not set then +``return FALSE`` is used to terminate the iteration early and return +from the :c:func:`BTIsSetRange()` function. If the iteration completes then +:c:macro:`TRUE` is returned. + +:mps:tag:`fun.test.range.reset` :c:func:`BTIsResRange()`. As for :c:func:`BTIsSetRange()` +(:mps:ref:`.fun.test.range.set` above) but testing whether the bits are reset. + +:mps:tag:`fun.test.range.same` :c:func:`BTRangesSame()`. As for :c:func:`BTIsSetRange()` +(:mps:ref:`.fun.test.range.set` above) but testing whether corresponding +ranges in the two Bit Tables are the same. Note there are no speed +requirements, but :c:func:`ACT_ON_RANGE()` is used for simplicity and +uniformity. + +:mps:tag:`fun.find` The four external find functions (:c:func:`BTFindShortResRange()`, +:c:func:`BTFindShortResRangeHigh()`, :c:func:`BTFindLongResRange()`, +:c:func:`BTFindLongResRangeHigh()`) simply call through to one of the two +internal functions: :c:func:`BTFindResRange()` and :c:func:`BTFindResRangeHigh()`. + +.. c:function:: Bool BTFindResRange(Index *baseReturn, Index *limitReturn, BT bt, Index searchBase, Index searchLimit, Count minLength, Count maxLength) +.. c:function:: Bool BTFindResRangeHigh(Index *baseReturn, Index *limitReturn, BT bt, Index searchBase, Index searchLimit, Count minLength, Count maxLength) + +There are two length parameters, one specifying the minimum length of +the range to be found, the other the maximum length. For +:c:func:`BTFindShort()` and :c:func:`BTFindShortHigh()`, ``maxLength`` is equal to +``minLength`` when passed; for :c:func:`BTFindLong()` and :c:func:`BTFindLongHigh()`, +``maxLength` is equal to the maximum possible range, namely +``searchLimit - searchBase``. + +:mps:tag:`fun.find-res-range` :c:func:`BTFindResRange()`. Iterate within the search +boundaries, identifying candidate ranges by searching for a reset bit. +The :ref:`Boyer–Moore algorithm ` is used (it's particularly +easy to implement when there are only two symbols, 0 and 1, in the +alphabet). For each candidate range, iterate backwards over the bits +from the end of the range towards the beginning. If a set bit is +found, this candidate has failed and a new candidate range is +selected. If when scanning for the set bit a range of reset bits was +found before finding the set bit, then this (small) range of reset +bits is used as the start of the next candidate. Additionally the end +of this small range of reset bits (the end of the failed candidate +range) is remembered so that we don't have to iterate over this range +again. But if no reset bits were found in the candidate range, then +iterate again (starting from the end of the failed candidate) to look +for one. If during the backwards search no set bit is found, then we +have found a sufficiently large range of reset bits; now extend the +valid range as far as possible up to the maximum length by iterating +forwards up to the maximum limit looking for a set bit. The iterations +make use of the :c:func:`ACT_ON_RANGE()` and :c:func:`ACT_ON_RANGE_HIGH()` macros, +which can use ``goto`` to effect an early termination of the iteration +when a set/reset (as appropriate) bit is found. The macro +:c:func:`ACTION_FIND_SET_BIT()` is used in the iterations. It efficiently +finds the first (that is, with lowest index or weight) set bit in a +word or subword. + +:mps:tag:`fun.find-res-range.improve` Various other performance improvements +have been suggested in the past, including some from +request.epcore.170534. Here is a list of potential improvements which +all sound plausible, but which have not led to performance +improvements in practice: + +* :mps:tag:`fun.find-res-range.improve.step.partial` When the top index in a + candidate range fails, skip partial words as well as whole words, + using, for example, lookup tables. + +* :mps:tag:`fun.find-res-range.improve.lookup` When testing a candidate run, + examine multiple bits at once (for example, 8), using lookup tables + for (for example) index of first set bit, index of last set bit, + number of reset bits, length of maximum run of reset bits. + +:mps:tag:`fun.find-res-range-high` :c:func:`BTFindResRangeHigh()`. Exactly the same +algorithm as in :c:func:`BTFindResRange()` (see :mps:ref:`.fun.find-res-range` above), +but moving over the table in the opposite direction. + +:mps:tag:`fun.copy-simple-range` :c:func:`BTCopyRange()`. Uses :c:func:`ACT_ON_RANGE()` (see +:mps:ref:`.iteration` above) with the obvious implementation. Should be fast. + +:mps:tag:`fun.copy-offset-range` :c:func:`BTCopyOffsetRange()`. Uses a simple +iteration loop, reading bits with :c:func:`BTGet()` and setting them with +:c:func:`BTSet()`. Doesn't use :c:func:`ACT_ON_RANGE()` because the two ranges will +not, in general, be similarly word-aligned. + +:mps:tag:`fun.copy-invert-range` :c:func:`BTCopyInvertRange()`. Uses :c:func:`ACT_ON_RANGE()` +(see :mps:ref:`.iteration` above) with the obvious implementation. Should be +fast---although there are no speed requirements. + + +Testing +------- + +:mps:tag:`test` The following tests are available or have been used during +development. + +:mps:tag:`test.btcv` ``btcv.c``. This is supposed to be a coverage test, +intended to execute all of the module's code in at least some minimal +way. + +:mps:tag:`test.cbstest` ``cbstest.c``. This was written as a test of the +:c:macro:`CBS` module (design.mps.cbs(2)). It compares the functional +operation of a :c:macro:`CBS` with that of a :c:type:`BT` so is a good functional +test of either module. + +:mps:tag:`test.mmqa.120` MMQA_test_function!210.c. This is used because it has +a fair amount of segment allocation and freeing so exercises the arena +code that uses Bit Tables. + +:mps:tag:`test.bttest` ``bttest.c``. This is an interactive test that can be +used to exercise some of the :c:type:`BT` functionality by hand. + +:mps:tag:`test.dylan` It is possible to modify Dylan so that it uses Bit +Tables more extensively. See change.mps.epcore.brisling.160181 TEST1 +and TEST2. + + diff --git a/mps/manual/html/_sources/design/buffer.txt b/mps/manual/html/_sources/design/buffer.txt new file mode 100644 index 00000000000..feaa3142a41 --- /dev/null +++ b/mps/manual/html/_sources/design/buffer.txt @@ -0,0 +1,698 @@ +.. _design-buffer: + + +.. index:: + pair: buffers; design + + +Allocation buffers and allocation points +======================================== + +.. mps:prefix:: design.mps.buffer + + +Introduction +------------ + +:mps:tag:`scope` This document describes the design of allocation buffers +and allocation points. + +:mps:tag:`purpose` The purpose of this document is to record design +decisions made concerning allocation buffers and allocation points and +justify those decisions in terms of requirements. + +:mps:tag:`readership` The document is intended for reading by any MPS +developer. + + +Glossary +-------- + +trapped + + :mps:tag:`def.trapped` The buffer is in a state such that the MPS gets + to know about the next use of that buffer. + + +Source +------ + +:mps:tag:`source.mail` Much of the juicy stuff about buffers is only +floating around in mail discussions. You might like to try searching +the archives if you can't find what you want here. + +.. note:: + + Mail archives are only accessible to Ravenbrook staff. RHSK + 2006-06-09. + +:mps:tag:`source.synchronize` For a discussion of the synchronization +issues: + +* `mail.richard.1995-05-19.17-10 `_ +* `mail.ptw.1995-05-19.19-15 `_ +* `mail.richard.1995-05-24.10-18 `_ + +.. note:: + + I believe that the sequence for flip in PTW's message is + incorrect. The operations should be in the other order. DRJ. + +:mps:tag:`source.interface` For a description of the buffer interface in C +prototypes: + +* `mail.richard.1997-04-28.09-25(0) `_ + +:mps:tag:`source.qa` Discussions with QA were useful in pinning down the +semantics and understanding of some obscure but important boundary +cases. See the thread starting +`mail.richard.tucker.1997-05-12.09-45(0) +`_ with subject "notes on +our allocation points discussion": + +* `mail.richard.tucker.1997-05-12.09-45 `_ +* `mail.ptw.1997-05-12.12-46(1) `_ +* `mail.richard.1997-05-12.13-15 `_ +* `mail.richard.1997-05-12.13-28 `_ +* `mail.ptw.1997-05-13.15-15 `_ +* `mail.sheep.1997-05-14.11-52 `_ +* `mail.rit.1997-05-15.09-19 `_ +* `mail.ptw.1997-05-15.21-22 `_ +* `mail.ptw.1997-05-15.21-35 `_ +* `mail.rit.1997-05-16.08-02 `_ +* `mail.rit.1997-05-16.08-42 `_ +* `mail.ptw.1997-05-16.12-36 `_ +* `mail.ptw.1997-05-16.12-47 `_ +* `mail.richard.1997-05-19.15-46 `_ +* `mail.richard.1997-05-19.15-56 `_ +* `mail.ptw.1997-05-20.20-47 `_ + + + +Requirements +------------ + +:mps:tag:`req.fast` Allocation must be very fast. + +:mps:tag:`req.thread-safe` Must run safely in a multi-threaded environment. + +:mps:tag:`req.no-synch` Must avoid the use of thread-synchronization. +(:mps:ref:`.req.fast`) + +:mps:tag:`req.manual` Support manual memory management. + +:mps:tag:`req.exact` Support exact collectors. + +:mps:tag:`req.ambig` Support ambiguous collectors. + +:mps:tag:`req.count` Must record (approximately) the amount of allocation (in bytes). + +.. note:: + + Actually not a requirement any more, but once was put forward as a + Dylan requirement. Bits of the code still reflect this + requirement. See request.dylan.170554. + + +Classes +------- + +:mps:tag:`class.hierarchy` The :c:type:`Buffer` data structure is designed to be +subclassable (see design.mps.protocol). + +:mps:tag:`class.hierarchy.buffer` The basic buffer class (:c:type:`BufferClass`) +supports basic allocation-point buffering, and is appropriate for +those manual pools which don't use segments (:mps:ref:`.req.manual`). The +:c:type:`Buffer` class doesn't support reference ranks (that is, the buffers +have ``RankSetEMPTY``). Clients may use :c:type:`BufferClass` directly, or +create their own subclasses (see :mps:ref:`.subclassing`). + +:mps:tag:`class.hierarchy.segbuf` Class :c:type:`SegBufClass` is also provided for +the use of pools which additionally need to associate buffers with +segments. :c:type:`SegBufClass` is a subclass of :c:type:`BufferClass`. Manual +pools may find it convenient to use :c:type:`SegBufClass`, but it is +primarily intended for automatic pools (:mps:ref:`.req.exact`, :mps:ref:`.req.ambig`). +An instance of :c:type:`SegBufClass` may be attached to a region of memory +that lies within a single segment. The segment is associated with the +buffer, and may be accessed with the :c:func:`BufferSeg()` function. +:c:type:`SegBufClass` also supports references at any rank set. Hence this +class or one of its subclasses should be used by all automatic pools +(with the possible exception of leaf pools). The rank sets of buffers +and the segments they are attached to must match. Clients may use +:c:type:`SegBufClass` directly, or create their own subclasses (see +:mps:ref:`.subclassing`). + +:mps:tag:`class.hierarchy.rankbuf` Class :c:type:`RankBufClass` is also provided +as a subclass of :c:type:`SegBufClass`. The only way in which this differs +from its superclass is that the rankset of a :c:type:`RankBufClass` is set +during initialization to the singleton rank passed as an additional +parameter to :c:func:`BufferCreate()`. Instances of :c:type:`RankBufClass` are of +the same type as instances of :c:type:`SegBufClass`, that is, ``SegBuf``. +Clients may use :c:type:`RankBufClass` directly, or create their own +subclasses (see :mps:ref:`.subclassing`). + +:mps:tag:`class.create` The buffer creation functions (:c:func:`BufferCreate()` +and :c:func:`BufferCreateV()`) take a ``class`` parameter, which determines +the class of buffer to be created. + +:mps:tag:`class.choice` Pools which support buffered allocation should +specify a default class for buffers. This class will be used when a +buffer is created in the normal fashion by MPS clients (for example by +a call to :c:func:`mps_ap_create()`). Pools specify the default class by +means of the ``bufferClass`` field in the pool class object. This +should be a pointer to a function of type :c:type:`PoolBufferClassMethod`. +The normal class "Ensure" function (for example +:c:func:`EnsureBufferClass()`) has the appropriate type. + +:mps:tag:`subclassing` Pools may create their own subclasses of the standard +buffer classes. This is sometimes useful if the pool needs to add an +extra field to the buffer. The convenience macro +:c:func:`DEFINE_BUFFER_CLASS()` may be used to define subclasses of buffer +classes. See design.mps.protocol.int.define-special. + +:mps:tag:`replay` To work with the allocation replayer (see +design.mps.telemetry.replayer), the buffer class has to emit an event +for each call to an external interface, containing all the parameters +passed by the user. If a new event type is required to carry this +information, the replayer (impl.c.eventrep) must then be extended to +recreate the call. + +:mps:tag:`replay.pool-buffer` The replayer must also be updated if the +association of buffer class to pool or the buffer class hierarchy is +changed. + +:mps:tag:`class.method` Buffer classes provide the following methods (these +should not be confused with the pool class methods related to the +buffer protocol, described in :mps:ref:`.method`): + +.. c:type:: Res (*BufferInitMethod)(Buffer buffer, Pool pool, ArgList args) + +:mps:tag:`class.method.init` :c:func:`init()` is a class-specific initialization +method called from :c:func:`BufferInit()`. It receives the keyword arguments +passed to to :c:func:`BufferInit()`. Client-defined methods must call their +superclass method (via a next-method call) before performing any +class-specific behaviour. :mps:tag:`replay.init` The :c:func:`init()` method +should emit a ``BufferInit`` event (if there aren't any extra +parameters, `` = ""``). + +.. c:type:: void (*BufferFinishMethod)(Buffer buffer) + +:mps:tag:`class.method.finish` :c:func:`finish()` is a class-specific finish +method called from :c:func:`BufferFinish()`. Client-defined methods must +call their superclass method (via a next-method call) after performing +any class-specific behaviour. + +.. c:type:: void (*BufferAttachMethod)(Buffer buffer, Addr base, Addr limit, Addr init, Size size) + +:mps:tag:`class.method.attach` :c:func:`attach()` is a class-specific method +called whenever a buffer is attached to memory, via +:c:func:`BufferAttach()`. Client-defined methods must call their superclass +method (via a next-method call) before performing any class-specific +behaviour. + +.. c:type:: void (*BufferDetachMethod)(Buffer buffer) + +:mps:tag:`class.method.detach` :c:func:`detach()` is a class-specific method +called whenever a buffer is detached from memory, via +:c:func:`BufferDetach()`. Client-defined methods must call their superclass +method (via a next-method call) after performing any class-specific +behaviour. + +.. c:type:: Seg (*BufferSegMethod)(Buffer buffer) + +:mps:tag:`class.method.seg` :c:func:`seg()` is a class-specific accessor method +which returns the segment attached to a buffer (or :c:macro:`NULL` if there +isn't one). It is called from :c:func:`BufferSeg()`. Clients should not need +to define their own methods for this. + +.. c:type:: RankSet (*BufferRankSetMethod)(Buffer buffer) + +:mps:tag:`class.method.rankSet` :c:func:`rankSet()` is a class-specific accessor +method which returns the rank set of a buffer. It is called from +:c:func:`BufferRankSet()`. Clients should not need to define their own +methods for this. + +.. c:type:: void (*BufferSetRankSetMethod)(Buffer buffer, RankSet rankSet) + +:mps:tag:`class.method.setRankSet` :c:func:`setRankSet()` is a class-specific +setter method which sets the rank set of a buffer. It is called from +:c:func:`BufferSetRankSet()`. Clients should not need to define their own +methods for this. + +.. c:type:: Res (*BufferDescribeMethod)(Buffer buffer, mps_lib_FILE *stream) + +:mps:tag:`class.method.describe` :c:func:`describe()` is a class-specific method +called to describe a buffer, via BufferDescribe. Client-defined +methods must call their superclass method (via a next-method call) +before describing any class-specific state. + + +Logging +------- + +:mps:tag:`logging.control` Buffers have a separate control for whether they +are logged or not, this is because they are particularly high volume. +This is a Boolean flag (``bufferLogging``) in the :c:type:`ArenaStruct`. + + +Measurement +----------- + +:mps:tag:`count` Counting the allocation volume is done by maintaining two +fields in the buffer struct: + +:mps:tag:`count.fields` ``fillSize``, ``emptySize``. + +:mps:tag:`count.monotonic` both of these fields are monotonically +increasing. + +:mps:tag:`count.fillsize` ``fillSize`` is an accumulated total of the size +of all the fills (as a result of calling the :c:type:`PoolClass` +:c:func:`BufferFill()` method) that happen on the buffer. + +:mps:tag:`count.emptysize` ``emptySize`` is an accumulated total of the size of +all the empties than happen on the buffer (which are notified to the +pool using the :c:type:`PoolClass` :c:func:`BufferEmpty()` method). + +:mps:tag:`count.generic` These fields are maintained by the generic buffer +code in :c:func:`BufferAttach()` and :c:func:`BufferDetach()`. + +:mps:tag:`count.other` Similar count fields are maintained in the pool and +the arena. They are maintained on an internal (buffers used internally +by the MPS) and external (buffers used for mutator allocation points) +basis. The fields are also updated by the buffer code. The fields are: + +- in the pool: ``fillMutatorSize``, ``fillInternalSize``, + ``emptyMutatorSize``, and ``emptyInternalSize`` (4 fields); +- in the arena, ``fillMutatorSize``, ``fillInternalSize``, + ``emptyMutatorSize``, ``emptyInternalSize``, and + ``allocMutatorSize`` (5 fields). + +:mps:tag:`count.alloc.how` The amount of allocation in the buffer just +after an empty is ``fillSize - emptySize``. At other times this +computation will include space that the buffer has the use of (between +base and init) but which may not get allocated in (because the +remaining space may be too large for the next reserve so some or all +of it may get emptied). The arena field ``allocMutatorSize`` is +incremented by the allocated size (between base and init) +whenever a buffer is detached. Symmetrically this field is decremented +by by the pre-allocated size (between base and init) whenever +a buffer is attached. The overall count is asymptotically correct. + +:mps:tag:`count.type` All the count fields are type double. + +:mps:tag:`count.type.justify` This is because double is the type most likely +to give us enough precision. Because of the lack of genuine +requirements the type isn't so important. It's nice to have it more +precise than long. Which double usually is. + + +Notes from the whiteboard +------------------------- + +Requirements + +- atomic update of words +- guarantee order of reads and write to certain memory locations. + +Flip + +- limit:=0 +- record init for scanner + +Commit + +- init:=alloc +- if(limit = 0) ... +- L written only by MM +- A written only by client (except during synchronized MM op) +- I ditto +- I read by MM during flip + +States + +- busy +- ready +- trapped +- reset + +.. note:: + + There are many more states. DRJ. + +Misc + +- During buffer ops all field values can change. Might trash perfectly + good ("valid"?) object if pool isn't careful. + + +Synchronization +--------------- + +Buffers provide a loose form of synchronization between the mutator +and the collector. + +The crucial synchronization issues are between the operation the pool +performs on flip and the mutator's commit operation. + +Commit + +- read init +- write init +- Memory Barrier +- read ``limit`` + +Flip + +- write ``limit`` +- Memory Barrier +- read init + +Commit consists of two parts. The first is the update to init. +This is a declaration that the new object just before init is now +correctly formatted and can be scanned. The second is a check to see +if the buffer has been "tripped". The ordering of the two parts is +crucial. + +Note that the declaration that the object is correctly formatted is +independent of whether the buffer has been tripped or not. In +particular a pool can scan up to the init pointer (including the newly +declared object) whether or not the pool will cause the commit to +fail. In the case where the pool scans the object, but then causes the +commit to fail (and presumably the allocation to occur somewhere +else), the pool will have scanned a "dead" object, but this is just +another example of conservatism in the general sense. + +Not that the read of init in the Flip sequence can in fact be +arbitrarily delayed (as long as it is read before a buffered segment +is scanned). + +On processors with Relaxed Memory Order (such as the DEC Alpha), +Memory Barriers will need to be placed at the points indicated. + +:: + + * DESIGN + * + * design.mps.buffer. + * + * An allocation buffer is an interface to a pool which provides + * very fast allocation, and defers the need for synchronization in + * a multi-threaded environment. + * + * Pools which contain formatted objects must be synchronized so + * that the pool can know when an object is valid. Allocation from + * such pools is done in two stages: reserve and commit. The client + * first reserves memory, then initializes it, then commits. + * Committing the memory declares that it contains a valid formatted + * object. Under certain conditions, some pools may cause the + * commit operation to fail. (See the documentation for the pool.) + * Failure to commit indicates that the whole allocation failed and + * must be restarted. When using a pool which introduces the + * possibility of commit failing, the allocation sequence could look + * something like this: + * + * do { + * res = BufferReserve(&p, buffer, size); + * if(res != ResOK) return res; // allocation fails, reason res + * initialize(p); // p now points at valid object + * } while(!BufferCommit(buffer, p, size)); + * + * Pools which do not contain formatted objects can use a one-step + * allocation as usual. Effectively any random rubbish counts as a + * "valid object" to such pools. + * + * An allocation buffer is an area of memory which is pre-allocated + * from a pool, plus a buffer descriptor, which contains, inter + * alia, four pointers: base, init, alloc, and limit. Base points + * to the base address of the area, limit to the last address plus + * one. Init points to the first uninitialized address in the + * buffer, and alloc points to the first unallocated address. + * + * L . - - - - - . ^ + * | | Higher addresses -' + * | junk | + * | | the "busy" state, after Reserve + * A |-----------| + * | uninit | + * I |-----------| + * | init | + * | | Lower addresses -. + * B `-----------' v + * + * L . - - - - - . ^ + * | | Higher addresses -' + * | junk | + * | | the "ready" state, after Commit + * A=I |-----------| + * | | + * | | + * | init | + * | | Lower addresses -. + * B `-----------' v + * + * Access to these pointers is restricted in order to allow + * synchronization between the pool and the client. The client may + * only write to init and alloc, but in a restricted and atomic way + * detailed below. The pool may read the contents of the buffer + * descriptor at _any_ time. During calls to the fill and trip + * methods, the pool may update any or all of the fields + * in the buffer descriptor. The pool may update the limit at _any_ + * time. + * + * Access to buffers by these methods is not synchronized. If a buffer + * is to be used by more than one thread then it is the client's + * responsibility to ensure exclusive access. It is recommended that + * a buffer be used by only a single thread. + * + * [Only one thread may use a buffer at once, unless the client + * places a mutual exclusion around the buffer access in the usual + * way. In such cases it is usually better to create one buffer for + * each thread.] + * + * Here are pseudo-code descriptions of the reserve and commit + * operations. These may be implemented in-line by the client. + * Note that the client is responsible for ensuring that the size + * (and therefore the alloc and init pointers) are aligned according + * to the buffer's alignment. + * + * Reserve(buf, size) ; size must be aligned to pool + * if buf->limit - buf->alloc >= size then + * buf->alloc +=size ; must be atomic update + * p = buf->init + * else + * res = BufferFill(&p, buf, size) ; buf contents may change + * + * Commit(buf, p, size) + * buf->init = buf->alloc ; must be atomic update + * if buf->limit == 0 then + * res = BufferTrip(buf, p, size) ; buf contents may change + * else + * res = True + * (returns True on successful commit) + * + * The pool must allocate the buffer descriptor and initialize it by + * calling BufferInit. The descriptor this creates will fall + * through to the fill method on the first allocation. In general, + * pools should not assign resources to the buffer until the first + * allocation, since the buffer may never be used. + * + * The pool may update the base, init, alloc, and limit fields when + * the fallback methods are called. In addition, the pool may set + * the limit to zero at any time. The effect of this is either: + * + * 1. cause the _next_ allocation in the buffer to fall through to + * the buffer fill method, and allow the buffer to be flushed + * and relocated; + * + * 2. cause the buffer trip method to be called if the client was + * between reserve and commit. + * + * A buffer may not be relocated under other circumstances because + * there is a race between updating the descriptor and the client + * allocation sequence. + + +Interface +--------- + +.. c:function:: Res BufferCreate(Buffer *bufferReturn, BufferClass class, Pool pool, Bool isMutator, ArgList args) + +:mps:tag:`method.create` Create an allocation buffer in a pool. The buffer +is created in the "ready" state. + +A buffer structure is allocated from the space control pool and +partially initialized (in particularly neither the signature nor the +serial field are initialized). The pool class's :c:func:`bufferCreate()` +method is then called. This method can update (some undefined subset +of) the fields of the structure; it should return with the buffer in +the "ready" state (or fail). The remainder of the initialization then +occurs. + +If and only if successful then a valid buffer is returned. + +.. c:function:: void BufferDestroy(Buffer buffer) + +:mps:tag:`method.destroy` Free a buffer descriptor. The buffer must be in +the "ready" state, that is, not between a Reserve and Commit. +Allocation in the area of memory to which the descriptor refers must +cease after :c:func:`BufferDestroy()` is called. + +Destroying an allocation buffer does not affect objects which have +been allocated, it just frees resources associated with the buffer +itself. + +The pool class's :c:func:`bufferDestroy()` method is called and then the +buffer structure is uninitialized and freed. + +.. c:function:: BufferCheck(Buffer buffer) + +:mps:tag:`method.check` The check method is straightforward, the non-trivial dependencies checked are: + +- The ordering constraints between base, init, alloc, and limit. +- The alignment constraints on base, init, alloc, and limit. +- That the buffer's rank is identical to the segment's rank. + +.. c:function:: void BufferAttach(Buffer buffer, Addr base, Addr limit, Addr init, Size size) + +:mps:tag:`method.attach` Set the base, init, alloc, and limit fields so that +the buffer is ready to start allocating in area of memory. The alloc +field is set to ``init + size``. + +:mps:tag:`method.attach.unbusy` :c:func:`BufferAttach()` must only be applied to +buffers that are not busy. + +.. c:function:: void BufferDetach(Buffer buffer, Pool pool) + +:mps:tag:`method.detach` Set the seg, base, init, alloc, and limit fields to +zero, so that the next reserve request will call the fill method. + +:mps:tag:`method.detach.unbusy` :c:func:`BufferDetach()` must only be applied to +buffers that are not busy. + +.. c:function:: Bool BufferIsReset(Buffer buffer) + +:mps:tag:`method.isreset` Returns :c:macro:`TRUE` if and only if the buffer is in the +reset state, that is, with base, init, alloc, and limit all set to +zero. + +.. c:function:: Bool BufferIsReady(Buffer buffer) + +:mps:tag:`method.isready` Returns :c:macro:`TRUE` if and only if the buffer is not +between a reserve and commit. The result is only reliable if the +client is not currently using the buffer, since it may update the +alloc and init pointers asynchronously. + +.. c:function:: mps_ap_t (BufferAP)(Buffer buffer) + +Returns the :c:type:`APStruct` substructure of a buffer. + +.. c:function:: Buffer BufferOfAP(mps_ap_t ap) + +:mps:tag:`method.ofap` Return the buffer which owns an :c:type:`APStruct`. + +:mps:tag:`method.ofap.thread-safe` :c:func:`BufferOfAP()` must be thread safe (see +impl.c.mpsi.thread-safety). This is achieved simply because the +underlying operation involved is simply a subtraction. + +.. c:function:: Arena BufferArena(Buffer buffer) + +:mps:tag:`method.arena` Returns the arena which owns a buffer. + +:mps:tag:`method.arena.thread-safe` :c:func:`BufferArena()` must be thread safe +(see impl.c.mpsi.thread-safety). This is achieved simple because the +underlying operation is a read of shared-non-mutable data (see +design.mps.thread-safety). + +.. c:function:: Pool BufferPool(Buffer buffer) + +Returns the pool to which a buffer is attached. + +.. c:function:: Res BufferReserve(Addr *pReturn, Buffer buffer, Size size, Bool withReservoirPermit) + +:mps:tag:`method.reserve` Reserves memory from an allocation buffer. + +This is a provided version of the reserve procedure described above. +The size must be aligned according to the buffer alignment. If +successful, ``ResOK`` is returned and ``*pReturn`` is updated with a +pointer to the reserved memory. Otherwise ``*pReturn`` is not touched. +The reserved memory is not guaranteed to have any particular contents. +The memory must be initialized with a valid object (according to the +pool to which the buffer belongs) and then passed to the +:c:func:`BufferCommit()` method (see below). ``BufferReserve(0`` may not be +applied twice to a buffer without a :c:func:`BufferCommit()` in-between. In +other words, Reserve/Commit pairs do not nest. + +.. c:function:: Res BufferFill(Addr *pReturn, Buffer buffer, Size size, Bool withReservoirPermit) + +:mps:tag:`method.fill` Refills an empty buffer. If there is not enough space +in a buffer to allocate in-line, :c:func:`BufferFill()` must be called to +"refill" the buffer. + +.. c:function:: Bool BufferCommit(Buffer buffer, Addr p, Size size) + +:mps:tag:`method.commit` Commit memory previously reserved. + +:c:func:`BufferCommit()` notifies the pool that memory which has been +previously reserved (see above) has been initialized with a valid +object (according to the pool to which the buffer belongs). The +pointer ``p`` must be the same as that returned by +:c:func:`BufferReserve()`, and the size must match the size passed to +:c:func:`BufferReserve()`. + +:c:func:`BufferCommit()` may not be applied twice to a buffer without a +reserve in between. In other words, objects must be reserved, +initialized, then committed only once. + +Commit returns :c:macro:`TRUE` if successful, :c:macro:`FALSE` otherwise. If commit +fails and returns :c:macro:`FALSE`, the client may try to allocate again by +going back to the reserve stage, and may not use the memory at ``p`` +again for any purpose. + +Some classes of pool may cause commit to fail under rare +circumstances. + +.. c:function:: BufferTrip(Buffer buffer, Addr p, Size size) + +:mps:tag:`method.trip` Act on a tripped buffer. The pool which owns a buffer +may asynchronously set the buffer limit to zero in order to get +control over the buffer. If this occurs after a :c:func:`BufferReserve()` +(but before the corresponding commit), then the :c:func:`BufferCommit()` +method calls :c:func:`BufferTrip()` and the :c:func:`BufferCommit()` method +returns with the return value of :c:func:`BufferTrip()`. + +:mps:tag:`method.trip.precondition` At the time trip is called, from +:c:func:`BufferCommit()`, the following are true: + +- :mps:tag:`method.trip.precondition.limit` ``limit == 0`` +- :mps:tag:`method.trip.precondition.init` ``init == alloc`` +- :mps:tag:`method.trip.precondition.p` ``p + size == alloc`` + + +Diagrams +-------- + +Here are a number of diagrams showing how buffers behave. In general, +the horizontal axis corresponds to mutator action (reserve, commit) +and the vertical axis corresponds to collector action. I'm not sure +which of the diagrams are the same as each other, and which are best +or most complete when they are different, but they all attempt to show +essentially the same information. It's very difficult to get all the +details in. These diagrams were drawn by Richard Brooksby, Richard +Tucker, Gavin Matthews, and others in April 1997. In general, the +later diagrams are, I suspect, more correct, complete and useful than +the earlier ones. I have put them all here for the record. Richard +Tucker, 1998-02-09. + +Buffer Diagram: +Buffer States + +Buffer States (3-column) +Buffer States (4-column) +Buffer States (gavinised) +Buffer States (interleaved) +Buffer States (richardized) + +[missing diagrams] + + diff --git a/mps/manual/html/_sources/design/cbs.txt b/mps/manual/html/_sources/design/cbs.txt deleted file mode 100644 index 0956be703a0..00000000000 --- a/mps/manual/html/_sources/design/cbs.txt +++ /dev/null @@ -1,695 +0,0 @@ -.. sources: - - ``_ - - -.. mps:prefix:: design.mps.cbs - -Coalescing block structure -========================== - - -Introduction ------------- - -:mps:tag:`intro` This is the design for :mps:ref:`impl.c.cbs`, which -implements a data structure for the management of non-intersecting -memory ranges, with eager coalescence. - -:mps:tag:`readership` This document is intended for any MM developer. - -:mps:tag:`source` :mps:ref:`design.mps.poolmv2`, :mps:ref:`design.mps.poolmvff`. - -:mps:tag:`overview` The "coalescing block structure" is a set of -addresses (or a subset of address space), with provision for efficient -management of contiguous ranges, including insertion and deletion, -high level communication with the client about the size of contiguous -ranges, and detection of protocol violations. - - -History -------- - -:mps:tag:`hist.0` This document was derived from the outline in -:mps:ref:`design.mps.poolmv2(2)`. Written by Gavin Matthews -1998-05-01. - -:mps:tag:`hist.1` Updated by Gavin Matthews 1998-07-22 in response to -approval comments in :mps:ref:`change.epcore.anchovy.160040` There is -too much fragmentation in trapping memory. - -:mps:tag:`hist.2` Updated by Gavin Matthews (as part of -:mps:ref:`change.epcore.brisling.160158`: MVFF cannot be instantiated -with 4-byte alignment) to document new alignment restrictions. - -:mps:tag:`hist.3` Converted from MMInfo database design document. -Richard Brooksby, 2002-06-07. - -:mps:tag:`hist.4` Converted to reStructuredText. Gareth Rees, -2013-04-14. - - -Definitions ------------ - -:mps:tag:`def.range` A (contiguous) range of addresses is a semi-open -interval on address space. - -:mps:tag:`def.isolated` A contiguous range is isolated with respect to -some property it has, if adjacent elements do not have that property. - -:mps:tag:`def.interesting` A block is interesting if it is of at least -the minimum interesting size specified by the client. - - -Requirements ------------- - -:mps:tag:`req.set` Must maintain a set of addresses. - -:mps:tag:`req.fast` Common operations must have a low amortized cost. - -:mps:tag:`req.add` Must be able to add address ranges to the set. - -:mps:tag:`req.remove` Must be able to remove address ranges from the set. - -:mps:tag:`req.size` Must report concisely to the client when isolated -contiguous ranges of at least a certain size appear and disappear. - -:mps:tag:`req.iterate` Must support the iteration of all isolated -contiguous ranges. This will not be a common operation. - -:mps:tag:`req.protocol` Must detect protocol violations. - -:mps:tag:`req.debug` Must support debugging of client code. - -:mps:tag:`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. - -:mps:tag:`req.align` Must support an alignment (the alignment of all -addresses specifying ranges) of down to ``sizeof(void *)`` without -losing memory. - - -Interface ---------- - -:mps:tag:`header` CBS is used through :mps:ref:`impl.h.cbs`. - - -External types -.............. - -.. c:type:: typedef struct CBSStruct CBSStruct, *CBS; - -:mps:tag:`type.cbs` :c:type:`CBS` is the main datastructure for -manipulating a CBS. It is intended that a :c:type:`CBSStruct` be -embedded in another structure. No convenience functions are provided -for the allocation or deallocation of the CBS. - -.. c:type:: typedef struct CBSBlockStruct CBSBlockStruct, *CBSBlock; - -:mps:tag:`type.cbs.block` :c:type:`CBSBlock` is the data-structure -that represents an isolated contiguous range held by the CBS. It is -returned by the new and delete methods described below. - -:mps:tag:`type.cbs.method` The following methods are provided as -callbacks to advise the client of certain events. The implementation -of these functions should not cause any CBS function to be called on -the same CBS. In this respect, the CBS module is not re-entrant. - -.. c:type:: typedef void (*CBSChangeSizeMethod)(CBS cbs, CBSBlock block, Size oldSize, SizeNewSize); - -:mps:tag:`type.cbs.change.size.method` :c:type:`CBSChangeSizeMethod` -is the function pointer type, four instances of which are optionally -registered via CBSInit. - -These callbacks are invoked under :c:func:`CBSInsert`, -:c:func:`CBSDelete`, or :c:func:`CBSSetMinSize` in certain -circumstances. Unless otherwise stated, ``oldSize`` and ``newSize`` -will both be non-zero, and different. The accessors -:c:func:`CBSBlockBase`, :c:func:`CBSBlockLimit`, and -:c:func:`CBSBlockSize` may be called from within these callbacks, -except within the delete callback when ``newSize`` is zero. See -:mps:ref:`.impl.callback` for implementation details. - -.. c:type:: typedef Bool (*CBSIterateMethod)(CBS cbs, CBSBlock block, void *closureP, unsigned long closureS); - -:mps:tag:`type.cbs.iterate.method` :c:type:`CBSIterateMethod` is a -function pointer type for a client method invoked by the CBS module -for every isolated contiguous range in address order, when passed to -the :c:func:`CBSIterate` or :c:func:`CBSIterateLarge` functions. The -function returns a boolean indicating whether to continue with the -iteration. - - -External functions -.................. - -.. c:function:: Res CBSInit(Arena arena, CBS cbs, CBSChangeSizeMethod new, CBSChangeSizeMethod delete, CBSChangeSizeMethod grow, CBSChangeSizeMethod shrink, Size minSize, Align alignment, Bool mayUseInline) - -:mps:tag:`function.cbs.init` :c:func:`CBSInit` is the function that -initialises the CBS structure. It performs allocation in the supplied -arena. Four methods are passed in as function pointers (see -:mps:ref:`.type.*` above), any of which may be ``NULL``. It receives a -minimum size, which is used when determining whether to call the -optional methods. The ``mayUseInline`` Boolean indicates whether the -CBS may use the memory in the ranges as a low-memory fallback (see -:mps:ref:`.impl.low-mem`). The alignment indicates the alignment of -ranges to be maintained. An initialised CBS contains no ranges. - -:mps:tag:`function.cbs.init.may-use-inline` If ``mayUseInline`` is -set, then ``alignment`` must be at least ``sizeof(void *)``. In this -mode, the CBS will never fail to insert or delete ranges, even if -memory for control structures becomes short. Note that, in such cases, -the CBS may defer notification of new/grow events, but will report -available blocks in :c:func:`CBSFindFirst` and :c:func:`CBSFindLast`. -Such low memory conditions will be rare and transitory. See -:mps:ref:`.align` for more details. - -.. c:function:: void CBSFinish(CBS cbs) - -:mps:tag:`function.cbs.finish` :c:func:`CBSFinish` is the function -that finishes the CBS structure and discards any other resources -associated with the CBS. - -.. c:function:: Res CBSInsert(CBS cbs, Addr base, Addr limit) - -:mps:tag:`function.cbs.insert` :c:func:`CBSInsert` is the function -used to add a contiguous range specified by ``[base,limit)`` to the -CBS. If any part of the range is already in the CBS, then -:c:macro:`ResFAIL` is returned, and the CBS is unchanged. This -function may cause allocation; if this allocation fails, and any -contingency mechanism fails, then :c:macro:`ResMEMORY` is returned, -and the CBS is unchanged. - -:mps:tag:`function.cbs.insert.callback` :c:func:`CBSInsert` will invoke callbacks as follows: - -* ``new``: when a new block is created that is interesting. ``oldSize == 0; newSize >= minSize``. - -* ``new``: when an uninteresting block coalesces to become interesting. ``0 < oldSize < minSize <= newSize``. - -* ``delete``: when two interesting blocks are coalesced. ``grow`` will also be invoked in this case on the larger of the two blocks. ``newSize == 0; oldSize >= minSize``. - -* ``grow``: when an interesting block grows in size. ``minSize <= oldSize < newSize``. - -.. c:function:: Res CBSDelete(CBS cbs, Addr base, Addr limit) - -:mps:tag:`function.cbs.delete` :c:func:`CBSDelete` is the function -used to remove a contiguous range specified by ``[base,limit)`` from -the CBS. If any part of the range is not in the CBS, then -:c:macro:`ResFAIL` is returned, and the CBS is unchanged. This -function may cause allocation; if this allocation fails, and any -contingency mechanism fails, then :c:macro:`ResMEMORY` is returned, -and the CBS is unchanged. - -:mps:tag:`function.cbs.delete.callback` :c:func:`CBSDelete` will -invoke callbacks as follows: - -* ``delete``: when an interesting block is entirely removed. ``newSize == 0; oldSize >= minSize``. -* ``delete``: when an interesting block becomes uninteresting. ``0 < newSize < minSize <= oldSize``. -* ``new``: when a block is split into two blocks, both of which are interesting. ``shrink`` will also be invoked in this case on the larger of the two blocks. ``oldSize == 0; newSize >= minSize``. -* ``shrink``: when an interesting block shrinks in size, but remains interesting. ``minSize <= newSize < oldSize``. - -.. c:function:: void CBSIterate(CBS cbs, CBSIterateMethod iterate, void *closureP, unsigned long closureS) - -:mps:tag:`function.cbs.iterate` :c:func:`CBSIterate` is the function -used to iterate all isolated contiguous ranges in a CBS. It receives a -pointer, unsigned long 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. - -.. c:function:: void CBSIterateLarge(CBS cbs, CBSIterateMethod iterate, void *closureP, unsigned long closureS) - -:mps:tag:`function.cbs.iterate.large` :c:func:`CBSIterateLarge` is the -function used to iterate all isolated contiguous ranges of size -greater than or equal to the client indicated minimum size in a CBS. -It receives a pointer, unsigned long closure pair to pass on to the -iterator method, and an iterator method to invoke on every large range -in address order. If the iterator method returns ``FALSE``, then the -iteration is terminated. - -.. c:function:: void CBSSetMinSize(CBS cbs, Size minSize) - -:mps:tag:`function.cbs.set.min-size` :c:func:`CBSSetMinSize` is the -function used to change the minimum size of interest in a CBS. This -minimum size is used to determine whether to invoke the client -callbacks from :c:func:`CBSInsert` and :c:func:`CBSDelete`. This -function will invoke either the ``new`` or ``delete`` callback for all -blocks that are (in the semi-open interval) between the old and new -values. ``oldSize`` and ``newSize`` will be the same in these cases. - -.. c:function:: Res CBSDescribe(CBS cbs, mps_lib_FILE *stream) - -:mps:tag:`function.cbs.describe` :c:func:`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. - -.. c:function:: Addr CBSBlockBase(CBSBlock block) - -:mps:tag:`function.cbs.block.base` The :c:func:`CBSBlockBase` function -returns the base of the range represented by the :c:type:`CBSBlock`. -This function may not be called from the delete callback when the -block is being deleted entirely. - -.. note:: - - The value of the base of a particular :c:type:`CBSBlock` is not - guaranteed to remain constant across calls to :c:func:`CBSDelete` - and :c:func:`CBSInsert`, regardless of whether a callback is - invoked. - -.. c:function:: Addr CBSBlockLimit(CBSBlock block) - -:mps:tag:`function.cbs.block.limit` The :c:func:`CBSBlockLimit` -function returns the limit of the range represented by the -:c:type:`CBSBlock`. This function may not be called from the delete -callback when the block is being deleted entirely. - -.. note:: - - The value of the limit of a particular :c:type:`CBSBlock` is not - guaranteed to remain constant across calls to :c:func:`CBSDelete` - and :c:func:`CBSInsert`, regardless of whether a callback is - invoked. - -.. c:function:: Size CBSBlockSize(CBSBlock block) - -:mps:tag:`function.cbs.block.size` The :c:func:`CBSBlockSize` function -returns the size of the range represented by the :c:type:`CBSBlock`. -This function may not be called from the ``delete`` callback when the -block is being deleted entirely. - -.. note:: - - The value of the size of a particular :c:type:`CBSBlock` is not - guaranteed to remain constant across calls to :c:func:`CBSDelete` - and :c:func:`CBSInsert`, regardless of whether a callback is - invoked. - -.. c:function:: Res CBSBlockDescribe(CBSBlock block, mps_lib_FILE *stream) - -:mps:tag:`function.cbs.block.describe` The :c:func:`CBSBlockDescribe` -function prints a textual representation of the :c:type:`CBSBlock` to -the given stream. It is provided for debugging purposes only. - -.. c:function:: Bool CBSFindFirst(Addr *baseReturn, Addr *limitReturn, CBS cbs, Size size, CBSFindDelete findDelete) - -:mps:tag:`function.cbs.find.first` The :c:func:`CBSFindFirst` function -locates the first block (in address order) within the CBS of at least -the specified size, and returns its range. If there are no such -blocks, it returns ``FALSE``. It optionally deletes the top, bottom, -or all of the found range, depending on the ``findDelete`` argument -(this saves a separate call to :c:func:`CBSDelete`, and uses the -knowledge of exactly where we found the range), which must come from -this enumeration:: - - enum { - CBSFindDeleteNONE, /* don't delete after finding */ - CBSFindDeleteLOW, /* delete precise size from low end */ - CBSFindDeleteHIGH, /* delete precise size from high end */ - CBSFindDeleteENTIRE /* delete entire range */ - }; - -.. c:function:: Bool CBSFindLast(Addr *baseReturn, Addr *limitReturn, CBS cbs, Size size, CBSFindDelete findDelete) - -:mps:tag:`function.cbs.find.last` The :c:func:`CBSFindLast` function -locates the last block (in address order) within the CBS of at least -the specified size, and returns its range. If there are no such -blocks, it returns ``FALSE``. Like :c:func:`CBSFindFirst`, it -optionally deletes the range. - -.. c:function:: Bool CBSFindLargest(Addr *baseReturn, Addr *limitReturn, CBS cbs, CBSFindDelete findDelete) - -:mps:tag:`function.cbs.find.largest` The :c:func:`CBSFindLargest` -function locates the largest block within the CBS, and returns its -range. If there are no blocks, it returns ``FALSE``. Like -:c:func:`CBSFindFirst`, it optionally deletes the range (specifying -``CBSFindDeleteLOW`` or ``CBSFindDeleteHIGH`` has the same effect as -``CBSFindDeleteENTIRE``). - - -Alignment ---------- - -:mps:tag:`align` When ``mayUseInline`` is specified to permit inline -data structures and hence avoid losing memory in low memory -situations, the alignments that the CBS supports are constrained by -three requirements: - -- The smallest possible range (namely one that is the alignment in - size) must be large enough to contain a single ``void *`` pointer (see - :mps:ref:`.impl.low-mem.inline.grain`); - -- Any larger range (namely one that is at least twice the alignment in - size) must be large enough to contain two ``void *`` pointers (see - :mps:ref:`.impl.low-mem.inline.block`); - -- It must be valid on all platforms to access a ``void *`` pointer - stored at the start of an aligned range. - -All alignments that meet these requirements are aligned to -``sizeof(void *)``, so we take that as the minimum alignment. - - -Implementation --------------- - -:mps:tag:`impl` Note that this section is concerned with describing -various aspects of the implementation. It does not form part of the -interface definition. - - -Size change callback protocol -............................. - -:mps:tag:`impl.callback` The size change callback protocol concerns -the mechanism for informing the client of the appearance and -disappearance of interesting ranges. The intention is that each range -has an identity (represented by the :c:type:`CBSBlock`). When blocks -are split, the larger fragment retains the identity. When blocks are -merged, the new block has the identity of the larger fragment. - -:mps:tag:`impl.callback.delete` Consider the case when the minimum -size is ``minSize``, and :c:func:`CBSDelete` is called to remove a -range of size ``middle``. The two (possibly non-existant) neighbouring -ranges have (possibly zero) sizes ``left`` and ``right``. ``middle`` is part -of the :c:type:`CBSBlock` ``middleBlock``. - -:mps:tag:`impl.callback.delete.delete` The ``delete`` callback will be -called in this case if and only if:: - - left + middle + right >= minSize && left < minSize && right < minSize - -That is, the combined range is interesting, but neither remaining -fragment is. It will be called with the following parameters: - -* ``block``: ``middleBlock`` -* ``oldSize``: ``left + middle + right`` -* ``newSize``: ``left >= right ? left : right`` - -:mps:tag:`impl.callback.delete.new` The ``new`` callback will be -called in this case if and only if:: - - left >= minSize && right >= minSize - -That is, both remaining fragments are interesting. It will be called -with the following parameters: - -* ``block``: a new block -* ``oldSize``: ``0`` -* ``newSize``: ``left >= right ? right : left`` - -:mps:tag:`impl.callback.delete.shrink` The shrink callback will be -called in this case if and only if:: - - left + middle + right >= minSize && (left >= minSize || right >= minSize) - -That is, at least one of the remaining fragments is still interesting. It will be called with the following parameters: - -* ``block``: ``middleBlock`` -* ``oldSize``: ``left + middle + right`` -* ``newSize``: ``left >= right ? left : right`` - -:mps:tag:`impl.callback.insert` Consider the case when the minimum -size is ``minSize``, and :c:func:`CBSInsert` is called to add a range -of size ``middle``. The two (possibly non-existant) neighbouring -blocks are ``leftBlock`` and ``rightBlock``, and have (possibly zero) -sizes ``left`` and ``right``. - -:mps:tag:`impl.callback.insert.delete` The ``delete`` callback will be -called in this case if and only if: - - left >= minSize && right >= minSize - -That is, both neighbours were interesting. It will be called with the -following parameters: - -* ``block``: ``left >= right ? rightBlock : leftBlock`` -* ``oldSize``: ``left >= right ? right : left`` -* ``newSize``: ``0`` - -:mps:tag:`impl.callback.insert.new` The ``new`` callback will be -called in this case if and only if: - - left + middle + right >= minSize && left < minSize && right < minSize - -That is, the combined block is interesting, but neither neighbour was. -It will be called with the following parameters: - -* ``block``: ``left >= right ? leftBlock : rightBlock`` -* ``oldSize``: ``left >= right ? left : right`` -* ``newSize``: ``left + middle + right`` - -:mps:tag:`impl.callback.insert.grow` The ``grow`` callback will be -called in this case if and only if:: - - left + middle + right >= minSize && (left >= minSize || right >= minSize) - -That is, at least one of the neighbours was interesting. It will be -called with the following parameters: - -* ``block``: ``left >= right ? leftBlock : rightBlock`` -* ``oldSize``: ``left >= right ? left : right`` -* ``newSize``: ``left + middle + right`` - - -Splay tree -.......... - -:mps:tag:`impl.splay` The CBS is principally implemented using a splay -tree (see :mps:ref:`design.mps.splay`). Each splay tree node is -embedded in a CBSBlock that represents a semi-open address range. The -key passed for comparison is the base of another range. - -:mps:tag:`impl.splay.fast-find` :c:func:`CBSFindFirst` and -:c:func:`CBSFindLast` use the update/refresh facility of splay trees -to store, in each :c:type:`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. - -:mps:tag:`impl.find-largest` :c:func:`CBSFindLargest` simply finds out -the size of the largest block in the CBS from the root of the tree -(using :c:func:`SplayRoot`), and does :c:func:`SplayFindFirst` for a -block of that size. This is O(log(*n*)) in the size of the free list, -so it's about the best you can do without maintaining a separate -priority queue, just to do :c:func:`CBSFindLargest`. Except when the -emergency lists (see :mps:ref:`.impl.low-mem`) are in use, they are -also searched. - - -Low memory behaviour -.................... - -:mps:tag:`impl.low-mem` Low memory situations cause problems when the -CBS tries to allocate a new :c:type:`CBSBlock` structure for a new -isolated range as a result of either :c:func:`CBSInsert` or -:c:func:`CBSDelete`, and there is insufficient memory to allocation -the :c:type:`CBSBlock` structure: - -:mps:tag:`impl.low-mem.no-inline` If ``mayUseInline`` is ``FALSE``, -then the range is not added to the CBS, and the call to -:c:func:`CBSInsert` or :c:func:`CBSDelete` returns ``ResMEMORY``. - -:mps:tag:`impl.low-mem.inline` If ``mayUseInline`` is ``TRUE``: - -:mps:tag:`impl.low-mem.inline.block` If the range is large enough to -contain an inline block descriptor consisting of two pointers, then it -is kept on an emergency block list. The CBS will eagerly attempt to -add this block back into the splay tree during subsequent calls to -:c:func:`CBSInsert` and :c:func:`CBSDelete`. The CBS will also keep -its emergency block list in address order, and will coalesce this list -eagerly. Some performance degradation will be seen when the emergency -block list is in use. Ranges on this emergency block list will not be -made available to the CBS's client via callbacks. :c:func:`CBSIterate` -and :c:func:`CBSIterateLarge` will not iterate over ranges on this -list. - -:mps:tag:`impl.low-mem.inline.block.structure` The two pointers stored -are to the next such block (or ``NULL``), and to the limit of the -block, in that order. - -:mps:tag:`impl.low-mem.inline.grain` Otherwise, the range must be -large enough to contain an inline grain descriptor consisting of one -pointer, then it is kept on an emergency grain list. The CBS will -eagerly attempt to add this grain back into either the splay tree or -the emergency block list during subsequent calls to -:c:func:`CBSInsert` and :c:func:`CBSDelete`. The CBS will also keep -its emergency grain list in address order. Some performance -degradation will be seen when the emergency grain list is in use. -Ranges on this emergency grain list will not be made available to the -CBS's client via callbacks. :c:func:`CBSIterate` and -:c:func:`CBSIterateLarge` will not iterate over ranges on this list. - -:mps:tag:`impl.low-mem.inline.grain.structure` The pointer stored is -to the next such grain, or ``NULL``. - - -The CBS block -............. - -:mps:tag:`impl.cbs.block` The block contains a base-limit pair and a -splay tree node. - -:mps:tag:`impl.cbs.block.special` The base and limit may be equal if -the block is halfway through being deleted. - -:mps:tag:`impl.cbs.block.special.just` This conflates values and -status, but is justified because block size is very important. - - -Testing -------- - -:mps:tag:`test` The following testing will be performed on this module: - -:mps:tag:`test.cbstest` There is a stress test for this module in -:mps:ref:`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 :c:type:`CBS` and a :c:type:`BT`. It makes both -valid and invalid requests, and compares the :c:type:`CBS` response to -the correct behaviour as determined by the :c:type:`BT`. It also -iterates the ranges in the :c:type:`CBS`, comparing them to the -:c:type:`BT`. It also invokes the :c:func:`CBSDescribe` method, but -makes no automatic test of the resulting output. It does not currently -test the callbacks. - -:mps:tag:`test.pool` Several pools (currently :ref:`pool-mvt` and -:ref:`pool-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. - - -Notes for future development ----------------------------- - -:mps:tag:`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 -:mps:ref:`.req.fast`). - -:mps:tag:`future.hybrid` It would be possible to attenuate the problem -of :mps:ref:`.risk.overhead` (below) by using a single word bit set to -represent the membership in a (possibly aligned) word-width of grains. -This might be used for block sizes less than a word-width of grains, -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)``. - - -Risks ------ - -:mps:tag:`risk.overhead` Clients should note that the current -implementation of CBSs has a space overhead proportional to the number -of isolated contiguous ranges. [Four words per range.] If the CBS -contains every other grain in an area, then the overhead will be large -compared to the size of that area. [Four words per two grains.] See -:mps:ref:`.future.hybrid` for a suggestion to solve this problem. An -alternative solution is to use CBSs only for managing long ranges. - - -Proposed hybrid implementation ------------------------------- - -.. note:: - - The following relates to a pending re-design and does not yet - relate to any working source version. GavinM 1998-09-25 - -The CBS system provides its services by combining the services -provided by three subsidiary CBS modules: - -- ``CBSST`` -- Splay Tree: Based on out-of-line splay trees; must - allocate to insert isolated, which may therefore fail. - -- ``CBSBL`` -- Block List: Based on a singly-linked list of variable - sized ranges with inline descriptors; ranges must be at least large - enough to store the inline descriptor. - -- ``CBSGL`` -- Grain List: Based on a singly-linked list of fixed size - ranges with inline descriptors; the ranges must be the alignment of - the CBS. - -The three sub-modules have a lot in common. Although their methods are -not invoked via a dispatcher, they have been given consistent -interfaces, and consistent internal appearance, to aid maintenance. - -Methods supported by sub-modules (not all sub-modules support all -methods): - -- ``MergeRange`` -- Finds any ranges in the specific CBS adjacent to - the supplied one. If there are any, it extends the ranges, possibly - deleting one of them. This cannot fail, but should return ``FALSE`` - if there is an intersection between the supplied range and a range - in the specific CBS. - -- ``InsertIsolatedRange`` -- Adds a range to the specific CBS that is - not adjacent to any range already in there. Depending on the - specific CBS, this may be able to fail for allocation reasons, in - which case it should return ``FALSE``. It should :c:func:`AVER` if - the range is adjacent to or intersects with a range already there. - -- ``RemoveAdjacentRanges`` -- Finds and removes from the specific CBS - any ranges that are adjacent to the supplied range. Should return - ``FALSE`` if the supplied range intersects with any ranges already - there. - -- ``DeleteRange`` -- Finds and deletes the supplied range from the - specific CBS. Returns a tri-state result: - - - ``Success`` -- The range was successfully deleted. This may have - involved the creation of a new range, which should be done via - ``CBSInsertIsolatedRange``. - - - ``ProtocolError`` -- Either some non-trivial strict subset of the - supplied range was in the specific CBS, or a range adjacent to the - supplied range was in the specific CBS. Either of these indicates - a protocol error. - - - ``NoIntersection`` -- The supplied range was not found in the CBS. - This may or not be a protocol error, depending on the invocation - context. - -- ``FindFirst`` -- Returns the first (in address order) range in the - specific CBS that is at least as large as the supplied size, or - ``FALSE`` if there is no such range. - -- ``FindFirstBefore`` -- As ``FindFirst``, but only finds ranges prior - to the supplied address. - -- ``FindLast`` -- As ``FindFirst``, but finds the last such range in - address order. - -- ``FindLastAfter`` -- ``FindLast`` equivalent of ``FindFirstBefore``. - -- ``Init`` -- Initialise the control structure embedded in the CBS. - -- ``Finish`` -- Finish the control structure embedded in the CBS. - -- ``InlineDescriptorSize`` -- Returns the aligned size of the inline descriptor. - -- ``Check`` -- Checks the control structure embedded in the CBS. - -The CBS supplies the following utilities: - -- ``CBSAlignment`` -- Returns the alignment of the CBS. - -- ``CBSMayUseInline`` -- Returns whether the CBS may use the memory in - the ranges stored. - -- ``CBSInsertIsolatedRange`` -- Wrapper for ``CBS*InsertIsolatedRange``. - -Internally, the ``CBS*`` sub-modules each have an internal structure -``CBS*Block`` that represents an isolated range within the module. It -supports the following methods (for sub-module internal use): - -- ``BlockBase`` -- Returns the base of the associated range; -- ``BlockLimit`` -- ``BlockRange`` -- ``BlockSize`` diff --git a/mps/manual/html/_sources/design/check.txt b/mps/manual/html/_sources/design/check.txt index 024f8b2809a..8e7a121b38b 100644 --- a/mps/manual/html/_sources/design/check.txt +++ b/mps/manual/html/_sources/design/check.txt @@ -1,6 +1,109 @@ +.. _design-check: + + .. index:: pair: checking; design -.. _design-check: -.. include:: ../../converted/check.rst +Checking +======== + +.. mps:prefix:: design.mps.check + + +Introduction +------------ + +:mps:tag:`intro` This documents the design of structure checking within the +MPS. + +:mps:tag:`readership` MPS developers. + + +Implementation +-------------- + +:mps:tag:`level` There are three levels of checking: + +1. :mps:tag:`level.sig` The lowest level checks only that the + structure has a valid ``Signature`` (see + design.mps.sig). + +2. :mps:tag:`level.shallow` Shallow checking checks all local fields + (including signature) and also checks the signatures of any parent + or child structures. + +3. :mps:tag:`level.deep` Deep checking checks all local fields + (including signatures), the signatures of any parent structures, + and does full recursive checking on any child structures. + +:mps:tag:`level.control` Control over the levels of checking is via the +definition of at most one of the macros :c:macro:`TARGET_CHECK_SHALLOW` +(which if defined gives :mps:ref:`.level.shallow`), :c:macro:`TARGET_CHECK_DEEP` +(which if defined gives :mps:ref:`.level.deep`). If neither macro is defined +then :mps:ref:`.level.sig` is used. These macros are not intended to be +manipulated directly by developers, they should use the interface in +impl.h.target. + +:mps:tag:`order` Because deep checking (:mps:ref:`.level.deep`) uses unchecked +recursion, it is important that child relationships are acyclic +(:mps:ref:`.macro.down`). + +:mps:tag:`fun` Every abstract data type which is a structure pointer should +have a function ``Check`` which takes a pointer of type +```` and returns a :c:type:`Bool`. It should check all fields in +order, using one of the macros in :mps:ref:`.macro`, or document why not. + +:mps:tag:`fun.omit` The only fields which should be omitted from a check +function are those for which there is no meaningful check (for +example, an unlimited unsigned integer with no relation to other +fields). + +:mps:tag:`fun.return` Although the function returns a :c:type:`Bool`, if the assert +handler returns (or there is no assert handler), then this is taken to +mean "ignore and continue", and the check function hence returns +:c:macro:`TRUE`. + +:mps:tag:`macro` Checking is implemented by invoking four macros in +impl.h.assert: + +.. c:function:: CHECKS(type, val) + +:mps:tag:`macro.sig` ``CHECKS(type, val)`` checks the signature only, and +should be called precisely on ``type`` and the received object +pointer. + +.. c:function:: CHECKL(cond) + +:mps:tag:`macro.local` ``CHECKL(cond)`` checks a local field (depending on +level; see :mps:ref:`.level`), and should be called on each local field that +is not an abstract data type structure pointer itself (apart from +the signature), with an appropriate normally-true test condition. + +.. c:function:: CHECKU(type, val) + +:mps:tag:`macro.up` ``CHECKU(type, val)`` checks a parent abstract data +type structure pointer, performing at most signature checks +(depending on level; see :mps:ref:`.level`). It should be called with the +parent type and pointer. + +.. c:function:: CHECKD(type, val) + +:mps:tag:`macro.down` ``CHECKD(type, val)`` checks a child abstract data +type structure pointer, possibly invoking ``Check`` (depending +on level; see :mps:ref:`.level`). It should be called with the child type +and pointer. + +:mps:tag:`full-type` :c:func:`CHECKS()`, :c:func:`CHECKD()`, :c:func:`CHECKU()`, all operate +only on fully fledged types. This means the type has to provide a +function ``Bool TypeCheck(Type type)`` where ``Type`` is substituted +for the name of the type (for example, :c:func:`PoolCheck()`), and the +expression ``obj->sig`` must be a valid value of type :c:type:`Sig` whenever +``obj`` is a valid value of type ``Type``. + +:mps:tag:`type.no-sig` This tag is to be referenced in implementations +whenever the form ``CHECKL(ThingCheck(thing))`` is used instead of +``CHECK{U,D}(Thing, thing)`` because ``Thing`` is not a fully fledged +type (:mps:ref:`.full-type`). + + diff --git a/mps/manual/html/_sources/design/class-interface.txt b/mps/manual/html/_sources/design/class-interface.txt index e7be02d9418..8e317c93e21 100644 --- a/mps/manual/html/_sources/design/class-interface.txt +++ b/mps/manual/html/_sources/design/class-interface.txt @@ -1,6 +1,261 @@ +.. _design-class-interface: + + .. index:: pair: class interface; design -.. _design-class-interface: -.. include:: ../../converted/class-interface.rst +Pool class interface +==================== + +.. mps:prefix:: design.mps.class-interface + + +Introduction +------------- + +:mps:tag:`intro` This document describes the interface and protocols between +the MPM and the pool class implementations. + +.. note:: + + This document should be merged into design.mps.pool. Pekka P. + Pirinen, 1999-07-20. + + +Methods +------- + +:mps:tag:`methods` These methods are provided by pool classes as part of the +:c:type:`PoolClass` object (see impl.h.mpmst.class). They form the interface +which allows the MPM to treat pools in a uniform manner. + +The following description is based on the definition of the +:c:type:`PoolClassStruct` (impl.h.mpmst.class). + +If a class is not required to provide a certain method then it should +set the appropriate ``PoolNo*`` method for that method. It is not +acceptable to use :c:macro:`NULL`. + +.. note:: + + There are also some ``PoolTriv*`` methods. David Jones, 1997-08-19. + +:mps:tag:`method.name` The name field should be a short, pithy, cryptic name +for the pool class. Examples are "AMC", "MV". + +The ``size`` field is the size of the pool instance structure. For the +``Foo`` :c:type:`PoolClass` this can reasonably be expected to be +``sizeof(FooStruct)``. + +The ``offset`` field is the offset into the pool instance structure of +the generic :c:type:`PoolStruct`. Typically this field is called +``poolStruct``, so something like ``offsetof(FooStruct, poolStruct)`` +is typical. If possible, arrange for this to be zero. + +The ``init`` field is the class's init method. This method is called +via the generic function :c:func:`PoolInit()`, which is in turn called by +:c:func:`PoolCreate()`. The generic function allocates the pool's structure +(using the size and offset information), initializes the +:c:type:`PoolStruct` (generic part) then calls the ``init`` method to do any +class-specific initialization. Typically this means initializing the +fields in the class instance structure. If ``init`` returns a non-OK +result code the instance structure will be deallocated and the code +returned to the caller of :c:func:`PoolInit()`` or :c:func:`PoolCreate()`. Note that +the :c:type:`PoolStruct` isn't made fully valid until :c:func:`PoolInit()` returns. + +The ``finish`` field is the class's finish method. This method is +called via the generic function :c:func:`PoolFinish()`, which is in turn +called by :c:func:`PoolDestroy()`. It is expected to finalise the pool +instance structure and release any resources allocated to the pool, it +is expected to release the memory associated with the pool instance +structure. Note that the pool is valid when it is passed to +``finish``. The :c:type:`PoolStruct` (generic part) is finished off when the +class's ``finish`` method returns. + +The ``alloc`` field is the class's allocation method. This method is +called via the generic function :c:func:`PoolAlloc()`. It is expected to +return a pointer to a fresh (that is, not overlapping with any other +live object) object of the required size. Failure to allocate should +be indicated by returning an appropriate Error code, and in such a +case, ``*pReturn`` should not be updated. Classes are not required to +provide this method, but they should provide at least one of ``alloc`` +and ``bufferCreate``. + +.. note:: + + There is no ``bufferCreate``. Gareth Rees, 2013-04-14. + +The ``free_`` field is the class's free method. This is intended +primarily for manual style pools. this method is called via the +generic function :c:func:`PoolFree()`. The parameters to this method are +required to correspond to a previous allocation request (possibly via +a buffer). It is an assertion by the client that the indicated object +is no longer required and the resources associated with it can be +recycled. Pools are not required to provide this method. + +The ``bufferInit`` field is the class's buffer initialization method. +It is called by the generic function :c:func:`BufferCreate()`, which allocates +the buffer descriptor and initializes the generic fields. The pool may +optionally adjust these fields or fill in extra values when +``bufferInit`` is called, but often pools set ``bufferInit`` to +:c:func:`PoolTrivBufferInit()` because they don't need to do any. If +``bufferInit`` returns a result code other than ``ResOK``, the buffer +structure is deallocated and the code is returned to the called of +:c:func:`BufferCreate()`. Note that the :c:type:`BufferStruct` isn't fully valid +until :c:func:`BufferCreate()` returns. + +The ``bufferFinish`` field is the class's buffer finishing method. It +is called by the the generic function :c:func:`BufferDestroy()`. The pool is +expected to detach the buffer from any memory and prepare the buffer +for destruction. The class is expected to release the resources +associated with the buffer structure, and any unreserved memory in the +buffer may be recycled. It is illegal for a buffer to be destroyed +when there are pending allocations on it (that is, an allocation has +been reserved, but not committed) and this is checked in the generic +function. This method should be provided if and only if +``bufferCreate`` is provided. [there is no ``bufferCreate`` -- drj +1997-08-19] + +The ``condemn`` field is used to condemn a pool. This method is called +via the generic function :c:func:`PoolCondemn()`. The class is expected to +condemn a subset (possible the whole set) of objects it manages and +participate in a global trace to determine liveness. The class should +register the refsig of the condemned set with the trace using +:c:func:`TraceCondemn()`. The class should expect fix requests (via the fix +method below) during a global trace. Classes are not required to +provide this method, but it is expected that automatic style classes +will. This interface is expected to change in the future. + +.. note:: + + ``condemn`` now takes an action and a segment and should condemn + the segment (turn it white) if it corresponds to the + interpretation of the action. David Jones, 1997-08-19. + + It is now called ``whiten``. David Jones, 1998-02-02. + +The ``mark`` field is used to mark an entire pool. This method is +called via the generic function :c:func:`PoolMark()`. The class should +consider all of its objects, except any set that has been condemned in +this trace, to be marked, that is ready for scanning. The class should +arrange that any appropriate invariants are preserved possibly by the +Protection interface. Classes are not required to provide this method, +and not doing so indicates that all instances of this class will have +no fixable or traceable references in them. + +.. note:: + + ``mark`` is no longer present: ``grey`` turns an entire segment + grey. David Jones, 1997-08-19. + +The ``scan`` field is used to perform scanning. This method is called +via the generic function :c:func:`PoolScan()`. The class should scan the +segment specified. It should scan all the known live (marked, that is, +those objects on which fix has been called) on the segment and +accumulate a summary of *all* the objects on the segment. This means +that mark and sweep pools may have to jump through hoops a little bit +(see design.mps.poolasm.summary for a pedagogical example). Classes +are not required to provide this method, and not doing so indicates +that all instances of this class will have no fixable or traceable +reference in them. + +.. note:: + + The ``scan`` method now takes an extra return parameter which + classes should use to indicate whether they scanned all objects in + segment or not. Classes should return summary only of object they + scanned. Caller of this method (:c:func:`TraceScan()`) is responsible + for updating summaries correctly when not a total scan. Hence no + jumping through hoops required. David Jones, 1998-01-30. + +The ``fix`` field is used to perform fixing. This method is called via +the generic function :c:func:`TraceFix()`. It indicates that the specified +reference has been found and the class should consider the object +live. There is provision for adjusting the value of the reference (to +allow for classes that move objects). Classes are not required to +provide this method, and not doing so indicates that the class is not +automatic style (ie it does not use global tracing to determine +liveness). + +The ``reclaim`` field is used to reclaim memory. This method is called +via the generic function :c:func:`PoolReclaim()`. It indicates that the trace +has fixed all references to reachable objects. + +.. note:: + + Actually it indicates that any remaining white objects have now + been proved unreachable, hence are dead. David Jones, 1997-08-19. + +The class should consider objects that have been condemned and not +fixed in this trace to be dead and may reclaim the resources +associated with them. Classes are not required to provide this method. + +.. note:: + + ``reclaim`` is now called on each segment. David Jones, + 1997-08-19. + +The ``access`` field is used to indicate client access. This method is +called via the generic functions :c:func:`SpaceAccess()` and +:c:func:`PoolAccess()`. It indicates that the client has attempted to access +the specified region, but has been denied and the request trapped due +to a protection state. The class should perform any work necessary to +remove the protection whilst still preserving appropriate invariants +(typically this will be scanning work). Classes are not required to +provide this method, and not doing so indicates they never protect any +memory managed by the pool. + +.. note:: + + ``access`` is no longer present. David Jones, 1997-08-19. + +:mps:tag:`method.act` ``act`` is called when the MPM has decided to execute +an action that the class declared. The Class should arrange execution +of the associated work (usually by beginning an incremental trace). + +:mps:tag:`method.walk` ``walk`` is used by the heap walker. ``walk`` is only +required to be implemented by classes which specify the AttrFMT +attribute (formatted pools). The ``walk`` method should apply the +passed in function (along with its closure variables (which are also +passed in) and the object format) to all *black* objects in the +segment. Padding objects may or may not be included in the walk at the +classes discretion, in any case in will be the responsibility of the +client to do something sensible with padding objects. + +.. note:: + + What about broken hearts? David Jones, 1998-01-30. + +The ``describe`` field is used to print out a description of a pool. +This method is called via the generic function :c:func:`PoolDescribe()`. The +class should emit an textual description of the pool's contents onto +the specified stream. Each line should begin with two spaces. Classes +are not required to provide this method. + + +Events +------ + +:mps:tag:`replay` To work with the allocation replayer (see +design.mps.telemetry.replayer), the pool has to emit an event for each +call to an external interface, containing all the parameters passed by +the user. If a new event type is required to carry this information, +the replayer (impl.c.eventrep) must then be extended to recreate the +call. + +:mps:tag:`replay.Init` In particular, the ``init`` method should emit a +``PoolInit`` event with all the pool parameters. + + +Text +----- + +:mps:tag:`alloc.size` The pool class implementation defines the meaning of +the "size" parameter to the ``alloc`` and ``free`` methods. It may not +actually correspond to a number of bytes of memory. + +:mps:tag:`alloc.size.align` In particular, the class may allow an unaligned +size to be passed. + + diff --git a/mps/manual/html/_sources/design/collection.txt b/mps/manual/html/_sources/design/collection.txt index ba882faa0d2..fae198acf86 100644 --- a/mps/manual/html/_sources/design/collection.txt +++ b/mps/manual/html/_sources/design/collection.txt @@ -1,6 +1,390 @@ +.. _design-collection: + + .. index:: pair: collection framework; design -.. _design-collection: -.. include:: ../../converted/collection.rst +Collection framework +==================== + +.. mps:prefix:: design.mps.collection + + +Introduction +------------ + +:mps:tag:`intro` This document describes the Collection Framework. It's a +framework for implementing garbage collection techniques and +integrating them into a system of collectors that all cooperate in +recycling garbage. + + +Overview +-------- + +:mps:tag:`framework` MPS provides a framework that allows the integration of +many different types of GC strategies and provides many of the basic +services that those strategies use. + +:mps:tag:`framework.cover` The framework subsumes most major GC strategies +and allows many efficient techniques, like in-line allocation or +software barriers. + +:mps:tag:`framework.overhead` The overhead due to cooperation is low. + +.. note:: + + But not non-existent. Can we say something useful about it? + +:mps:tag:`framework.benefits` The ability to combine collectors contributes +significantly to the flexibility of the system. The reduction in code +duplication contributes to reliability and integrity. The services of +the framework make it easier to write new MM strategies and +collectors. + +:mps:tag:`framework.mpm` The Collection Framework is merely a part of the +structure of the MPM. See design.mps.architecture and design.mps.arch +for the big picture. + +.. note:: + + Those two documents should be combined into one. Pekka P. Pirinen, + 1998-01-15. + +Other notable components that the MPM manages to integrate into a +single framework are manually-managed memory and finalization services +(see design.mps.finalize). + +.. note:: + + A document describing the design of manually-managed memory is + missing. Pekka P. Pirinen, 1998-01-15. + +:mps:tag:`see-also` This document assumes basic familiarity with the ideas +of pool (see design.mps.arch.pools) and segment (see +design.mps.seg.over). + + +Collection abstractions +----------------------- + +Colours, scanning and fixing +............................ + +:mps:tag:`state` The framework knows about the three colours of the +tri-state abstraction and free blocks. Recording the state of each +object is the responsibility of the pool, but the framework gets told +about changes in the states and keeps track of colours in each +segment. Specifically, it records whether a segment might contain +white, grey and black objects with respect to each active trace (see +:mps:ref:`.tracer`) + +.. note:: + + Black not currently implemented. Pekka P. Pirinen, 1998-01-04. + +(A segment might contain objects of all colours at once, or none.) +This information is approximate, because when an object changes +colour, or dies, it usually is too expensive to determine if it was +the last object of its former colour. + +:mps:tag:`state.transitions` The possible state transitions are as follows:: + + free ---alloc--> black (or grey) or white or none + none --condemn-> white + none --refine--> grey + grey ---scan---> black + white ----fix---> grey (or black) + black --revert--> grey + white --reclaim-> free + black --reclaim-> none + +:mps:tag:`none-is-black` Outside of a trace, objects don't really have +colour, but technically, the colour is black. Objects are only +allocated grey or white during a trace, and by the time the trace has +finished, they are either dead or black, like the other surviving +objects. We might then reuse the colour field for another trace, so +it's convenient to set the colour to black when allocating outside a +trace. This means that refining the foundation +(analysis.tracer.phase.condemn.refine), actually turns black segments +grey, rather than vice versa, but the principle is the same. + +:mps:tag:`scan-fix` "Scanning" an object means applying the "fix" function +to all references in that object. Fixing is the generic name for the +operation that takes a reference to a white object and makes it +non-white (usually grey, but black is a possibility, and so is +changing the reference as we do for weak references). Typical examples +of fix methods are copying the object into to-space or setting its +mark bit. + +:mps:tag:`cooperation` The separation of scanning and fixing is what allows +different GC techniques to cooperate. The scanning is done by a method +on the pool that the scanned object resides in, and the fixing is done +by a method on the pool that the reference points to. + +:mps:tag:`scan-all` Pools provide a method to scan all the grey objects in a +segment. + + +Reference sets +.............. + +:mps:tag:`refsets` The cost of scanning can be significantly reduced by +storing remembered sets. We have chosen a very compact and efficient +implementation, called reference sets, or refsets for short (see +idea.remember). + +.. note:: + + design.mps.refset is empty! Perhaps some of this should go there. + Pekka P. Pirinen, 1998-02-19. + +This makes the cost of maintaining them low, so we maintain them for +all references out of all scannable segments. + +:mps:tag:`refsets.approx` You might describe refsets as summaries of all +references out of an area of memory, so they are only approximations +of remembered sets. When a refset indicates that an interesting +reference might be present in a segment, we still have to scan the +segment to find it. + +:mps:tag:`refsets.scan` The refset information is collected during scanning. +The scan state protocol provides a way for the pool and the format +scan methods to cooperate in this, and to pass this information to the +tracer module which checks it and updates the segment (see +design.mps.scan). + +.. note:: + + Actually, there's very little doc there. Pekka P. Pirinen, + 1998-02-17. + +:mps:tag:`refsets.maintain` The MPS tries to maintain the refset information +when it moves or changes object. + +:mps:tag:`refsets.pollution` Ambiguous references and pointers outside the +arena will introduce spurious zones into the refsets. We put up with +this to keep the scanning costs down. Consistency checks on refsets +have to take this into account. + +:mps:tag:`refsets.write-barrier` A write-barrier are needed to keep the +mutator from invalidating the refsets when writing to a segment. We +need one on any scannable segment whose refset is not a superset of +the mutator's (and that the mutator can see). If we know what the +mutator is writing and whether it's a reference, we can just add that +reference to the refset (figuring out whether anything can be removed +from the refset is too expensive). If we don't know or if we cannot +afford to keep the barrier up, the framework can union the mutator's +refset to the segment's refset. + +:mps:tag:`refset.mutator` The mutator's refset could be computed during root +scanning in the usual way, and then kept up to date by using a +read-barrier. It's not a problem that the mutator can create new +pointers out of nothing behind the read-barrier, as they won't be real +references. However, this is probably not cost-effective, since it +would cause lots of barrier hits. We'd need a read-barrier on every +scannable segment whose refset is not a subset of the mutator's (and +that the mutator can see). So instead we approximate the mutator's +refset with the universal refset. + + +The tracer +---------- + +:mps:tag:`tracer` The tracer is an engine for implementing multiple garbage +collection processes. Each process (called a "trace") proceeds +independently of the others through five phases as described in +analysis.tracer. The following sections describe how the action of +each phase fits into the framework. See design.mps.trace for details + +.. note:: + + No, there's not much there, either. Possibly some of this section + should go there. Pekka P. Pirinen, 1998-02-18. + +:mps:tag:`combine` The tracer can also combine several traces for some +actions, like scanning a segment or a root. The methods the tracer +calls to do the work get an argument that tells them which traces they +are expected to act for. + +.. note:: + + Extend this. + +:mps:tag:`trace.begin` Traces are started by external request, usually from +a client function or an action (see design.mps.action). + +:mps:tag:`trace.progress` The tracer gets time slices from the arena to work +on a given trace. + +.. note:: + + This is just a provisional arrangement, in lieu of real progress + control. Pekka P. Pirinen, 1998-02-18. + +In each slice, it selects a small amount of work to do, based on the +state of the trace, and does it, using facilities provided by the +pools. .trace.scan: A typical unit of work is to scan a single +segment. The tracer can choose to do this for multiple traces at once, +provided the segment is grey for more than one trace. + +:mps:tag:`trace.barrier` Barrier hits might also cause a need to scan :mps:a +segment (see :mps:ref:`.hw-barriers.hit`). Again, the tracer can +:mps:choose to combine traces, when it does this. + +:mps:tag:`mutator-colour` The framework keeps track of the colour of the +mutator separately for each trace. + + +The condemn phase +................. + +:mps:tag:`phase.condemn` The agent that creates the trace (see +:mps:ref:`.trace.begin`) determines the condemned set and colours it white. +The tracer then examines the refsets on all scannable segments, and if +it can deduce some segment cannot refer to the white set, it's +immediately coloured black, otherwise the pool is asked to grey any +objects in the segment that might need to be scanned (in copying +pools, this is typically the whole segment). + +:mps:tag:`phase.condemn.zones` To get the maximum benefit from the refsets, +we try to arrange that the zones are a minimal superset (for example, +generations uniquely occupy zones) and a maximal subset (there's +nothing else in the zone) of the condemned set. This needs to be +arranged at allocation time (or when copying during collection, which +is much like allocation) + +.. note:: + + Soon, this will be handled by segment loci, see design.mps.locus. + +:mps:tag:`phase.condemn.mutator` At this point, the mutator might reference +any objects, that is, it is grey. Allocation can be in any colour, +most commonly white. + +.. note:: + + More could be said about this. + + +The grey mutator phase +...................... + +:mps:tag:`phase.grey-mutator` Grey segments are chosen according to some +sort of progress control and scanned by the pool to make them black. +Eventually, the tracer will decide to flip or it runs out of grey +segments, and proceeds to the next phase. + +.. note:: + + Currently, this phase has not been implemented; all traces flip + immediately after condemn. Pekka P. Pirinen, 1998-02-18. + +:mps:tag:`phase.grey-mutator.copy` At this stage, we don't want to copy +condemned objects, because we would need an additional barrier to keep +the mutator's view of the heap consistent (see +analysis.async-gc.copied.pointers-and-new-copy). + +:mps:tag:`phase.grey-mutator.ambig` This is a good time to get all ambiguous +scanning out of the way, because we usually can't do any after the +flip and because it doesn't cause any copying. + +.. note:: + + Write a detailed explanation of this some day. + + +The flip phase +.............. + +:mps:tag:`phase.flip` The roots (see design.mps.root) are scanned. This has +to be an atomic action as far as the mutator is concerned, so all +threads are suspended for the duration. + +:mps:tag:`phase.flip.mutator` After this, the mutator is black: if we use a +strong barrier (analysis.async-gc.strong), this means it cannot refer +to white objects. Allocation will be in black (could be grey as well, +but there's no point to it). + + +The black mutator phase +....................... + +:mps:tag:`phase.black-mutator` Grey segments are chosen according to some +sort of progress control and scanned by the pool to make them black. +Eventually, the tracer runs out of segments that are grey for this +trace, and proceeds to the next phase. + +:mps:tag:`phase.black-mutator.copy` At this stage white objects can be +relocated, because the mutator cannot see them (as long as a strong +barrier is used, as we must do for a copying collection, see +analysis.async-gc.copied.pointers). + + +The reclaim phase +................. + +:mps:tag:`phase.reclaim` The tracer finds the remaining white segments and +asks the pool to reclaim any white objects in them. + +:mps:tag:`phase.reclaim.barrier` Once a trace has started reclaiming +objects, the others shouldn't try to scan any objects that are white +for it, because they might have dangling pointers in them. + +.. note:: + + Needs cross-reference to document that is yet to be written. + + Currently, we reclaim atomically, but it could be incremental, or + even overlapped with a new trace on the same condemned set. + Pekka P. Pirinen, 1997-12-31. + + +Barriers +-------- + +.. note:: + + An introduction and a discussion of general principles should go + here. This is a completely undesigned area. + + +Hardware barriers +................. + +:mps:tag:`hw-barriers` Hardware barrier services cannot, by their very +nature, be independently provided to each trace. A segment is either +protected or not, and we have to set the protection on a segment if +any trace needs a hardware barrier on it. + +:mps:tag:`hw-barriers.supported` The framework currently supports +segment-oriented Appel-Ellis-Li barriers +(analysis.async-gc.barrier.appel-ellis-li), and write-barriers for +keeping the refsets up-to-date. It would not be hard to add Steele +barriers (analysis.async-gc.barrier.steele.scalable). + +:mps:tag:`hw-barriers.hit` When a barrier hit happens, the arena determines +which segment it was on. The segment colour info is used to determine +whether it had trace barriers on it, and if so, the appropriate +barrier action is performed, using the methods of the owning pool. If +the segment was write-protected, its refset is unioned with the refset +of the mutator. + +.. note:: In practice this is ``RefSetUNIV``. + +:mps:tag:`hw-barriers.hit.multiple` Fortunately, if we get a barrier hit on +a segment with multiple trace barriers on it, we can scan it for all +the traces that it had a barrier for. + +.. note:: Needs link to unwritten section under :mps:ref:`.combine`. + + +Software barriers +................. + +.. note:: + + Write something about software barriers. + + diff --git a/mps/manual/html/_sources/design/config.txt b/mps/manual/html/_sources/design/config.txt index 9958ebcbced..116d3616a35 100644 --- a/mps/manual/html/_sources/design/config.txt +++ b/mps/manual/html/_sources/design/config.txt @@ -1,6 +1,542 @@ +.. _design-config: + + .. index:: pair: configuration; design -.. _design-config: -.. include:: ../../converted/config.rst +MPS Configuration +================= + +.. mps:prefix:: design.mps.config + + +Introduction +------------ + +:mps:tag:`intro` This document describes how the `Memory Pool System +`_ source code is configured so +that it can target different architectures, operating systems, build +environments, varieties, and products. + + + +Requirements +------------ + +:mps:tag:`req.import` The MPS must be simple to include in third-party projects. + +:mps:tag:`req.arch` Allow architecture specific configurations of the MPS, so +that we can vary the MPS according to the target architecture. + +:mps:tag:`req.os` Allow operating system specific configurations of the MPS, +so that we can vary the MPS according to the target OS. + +:mps:tag:`req.builder` Allow build environment specific configurations of the +MPS, so that we can vary the MPS according to the compiler, etc. + +:mps:tag:`req.var` Allow configurations with different amounts of +instrumentation (assertions, metering, etc.). + +:mps:tag:`req.impact` The configuration system should have a minimal effect on +maintainability of the implementation. + +:mps:tag:`req.port` The system should be easy to port across platforms. + +:mps:tag:`req.maint` Maintenance of the configuration and build system should +not consume much developer time. + + +Retired requirements +.................... + +:mps:tag:`req.prod` Allow product specific configurations of the MPS, so that +we can build variants of the MPS for use in different products. This +requirement has been retired on 2012-09-03 as part of work on the +variety-reform_ branch. Client-specific customisation of the MPS will +be handled in source control, while the MPS source remains generic, to +reduce costs and increase reliability. See [RB_2012-09-13]_. + +.. _variety-reform: /project/mps/branch/2012-08-15/variety-reform + + +Definitions +----------- + +:mps:tag:`def.platform` A *platform* is a combination of an architecture +(:mps:ref:`.def.arch`), an operating system (:mps:ref:`.def.os`), and a builder +(:mps:ref:`.def.builder`). The set of supported platforms is maintained in the +`Platforms section of "Building the Memory Pool System" +<../manual/html/guide/build.html#platforms>`_. + +:mps:tag:`def.arch` An *architecture* is processor type with associated calling +conventions and other binary interface stuff these days often called the +`ABI `_. +Most importantly for the MPS it determines the layout of the register +file, thread context, and thread stack. + +:mps:tag:`def.os` An *operating system* is the interface to external resources. +Most importantly for the MPS it determines the low level interface to +virtual memory (if any) and threading. + +:mps:tag:`def.builder` A *builder* is the tools (C compiler, etc.) used to make +the target (:mps:ref:`.def.target`). The MPS minimises use of compiler-specific +extensions, but this is handy for suppressing warnings, inlining hints, +etc. + +:mps:tag:`def.var` A *variety* determines things like the amount of debugging, +internal consistency checking, annotation, etc. In modern IDEs this +called a "build configuration" and the usual default is to have two: +"debug" and "release". The MPS predates this convention, but the concept +is the same. + +:mps:tag:`def.prod` A *product* is the intended product into which the MPS will +fit, e.g. ScriptWorks, Dylan, etc. We no longer maintain this concept +as a dimension of configuration since :mps:ref:`.req.prod` has been retired. + +:mps:tag:`def.target` The *target* is the result of the build. + + +Overview +-------- + +:mps:tag:`import.source` The MPS can be simply included in client products as +source code. Since `version 1.110`_ we made it possible to simply +include the file ``mps.c`` in a client's build process, without +requiring a separate build of the MPS or linking a library. This is +described `section 2.3.1, "Compiling for production" of the MPS manual +<../manual/html/guide/build.html#compiling-for-production>`_. + +.. _`version 1.110`: http://www.ravenbrook.com/project/mps/version/1.110/ + +:mps:tag:`no-gen` No generated code or external tools are required. On most +platforms the only tool is the C compiler. On 64-bit Windows we require +the assembler since Microsoft withdrew in-line assembler from their C +compiler. + +:mps:tag:`no-spaghetti` Several of the MPS team have worked on some extremely +messy code bases which used a great number of ``#ifdef`` statements. +These quickly became very expensive to maintain and develop. The +general rule in the MPS is "no ``#ifdefs``". Instead, platform-specific +code is kept in separate source files and selected by carefully controlled +``#ifdefs``, such as in `mps.c <../code/mps.c>`_. + +:mps:tag:`min-dep` Dependency on a particular configuration should be +minimized and localized when developing code. This is enshrined in the +general rules for implementation [ref?] that are enforced by MPS +development procedures including code review and inspection. + + +The build system +---------------- + +Abstract build function +....................... + +:mps:tag:`build.fun` The MPS implementation assumes only a simple "build +function" that takes a set of sources, possibly in several languages, +compiles them with a set of predefined preprocessor symbols, and links +the result with a set of libraries to form the target:: + + target := build(, , ) + +:mps:tag:`build.sep` Separate compilation and linkage can be seen as a +memoization of this function, and is not strictly necessary for the +build. Indeed, since `version 1.110` we found that modern compilers +are quite happy to compile the whole MPS in one go :mps:ref:`.import.source`. + +:mps:tag:`build.cc` A consequence of this approach is that it should always +be possible to build a complete target with a single UNIX command line +calling the compiler driver (usually "cc" or "gcc"), for example:: + + cc -o main -DCONFIG_VAR_DF foo.c bar.c baz.s -lz + +:mps:tag:`build.defs` The "defs" are the set of preprocessor macros which are to be +predefined when compiling the module sources:: + + CONFIG_VAR_ + +The variety-codes are the letter code that appears after "variety." in +the tag of the relevant variety document (see variety.*) converted to +upper case. Currently (2012-09-03): + +:mps:tag:`var.hot` :c:macro:`HOT` + + Intended for release in products. Optimised, reduced internal + checking, especially on the critical path [RB_2012-09-07]_. + +:mps:tag:`var.cool` :c:macro:`COOL` + + Intended for use during development. Moderately thorough internal + consistency checking. Reduced optimisation to allow for + single-stepping. + +:mps:tag:`var.rash` :c:macro:`RASH` + + No internal checking at all. Slight performance improvement over + :mps:ref:`.var.hot` at the cost of early detection of memory management + bugs. We do not advise use of this variety, as memory management + bugs tend to be extremely expensive to deal with. + +:mps:tag:`var.diag` :c:macro:`DIAG` (deprecated) + + This variety does some client-specific analysis and produces some + specialised diagnostic output, and is not intended for general use. + It will be phased out of the open sources. + +:mps:tag:`default.hot` If no :c:macro:`CONFIG_VAR` is present, :c:macro:`HOT` is assumed in +`config.h`_. + +:mps:tag:`build.srcs` The "srcs" are the set of sources that must be +compiled in order to build the target. The set of sources may vary +depending on the configuration. For example, different sets of sources +may be required to build different architectures. + +.. note:: + + This is a dependency between the makefile (or whatever) and the + module configuration in `config.h`_. + +:mps:tag:`build.libs` The "libs" are the set of libraries to which the +compiled sources must be linked in order to build the target. For +example, when building a test program, it might include the ANSI C +library and an operating system interface library. + + +File Structure +.............. + +:mps:tag:`file.dir` The MPS source code is arranged in a single directory +called "code" containing all the sources for the whole family of +targets. + +:mps:tag:`file.base` The names of sources must be unique in the first eight +characters in order to conform to FAT filesystem naming restrictions. +(Do not scoff -- this has been an important requirement as recently as +2012!) + +:mps:tag:`file.ext` The extension may be up to three characters and directly +indicates the source language. + +:mps:tag:`file.platform` Platform-specific files include the platform code +in their name. See :mps:ref:`.mod.impls`. + + +Modules and naming +.................. + +:mps:tag:`mod.unique` Each module has an identifier which is unique within the MPS. + +:mps:tag:`mod.impls` Each module has one or more implementations which may be +in any language supported by the relevant build environment. + +:mps:tag:`mod.primary` The primary implementation of a module is written in +target-independent ANSI C in a source file with the same name as the +module. + +:mps:tag:`mod.an` Where there are platform-specific implementations and an +inferior portable ANSI C fallback implementation, "an" is used in +place of the platform code. + +:mps:tag:`mod.secondary` The names of other implementations should begin +with the same prefix (the module id or a shortened version of it) and +be suffixed with on or more target parameter codes (defined below). In +particular, the names of assembly language sources must include the +target parameter code for the relevant architecture. + +:mps:tag:`mod.example` For example, the stack scanner is defined in `ss.h +<../code/ss.h>`_ (which is platform-independent). It has some +platform-independent C in `ss.c <../code/ss.c>`_ and, for example, +`ssw3i6mv.c <../code/ssw3i6mv.c>`_ is specific to Windows on the x64 +architecture built with Microsoft Visual C. + + +Build system rationale +...................... + +:mps:tag:`build.rat` This simple design makes it possible to build the MPS +using many different tools. Microsoft Visual C and other graphical +development tools do not support much in the way of generated sources, +staged building, or other such stuff. The Visual C and Xcode "project" +files correspond closely to a closure of the build function +(:mps:ref:`.build.fun`). The simplicity of the build function has also made it +easy to set up builds using NMAKE (DOS), MPW (Macintosh), and to get the +MPS up and running on other platforms such as FreeBSD and Linux in very +little time. The cost of maintaining the build systems on these various +platforms is also reduced to a minimum, allowing the MPS developers to +concentrate on primary development. The source code is kept simple and +straightforward. When looking at MPS sources you can tell exactly what +is going to be generated with very little context. The sources are not +munged beyond the standard ANSI C preprocessor. + +:mps:tag:`build.port` The portability requirement (:mps:ref:`.req.port`) implies that +the build system must use only standard tools that will be available on +all conceivable target platforms. Experience of development +environments on the Macintosh (Metrowerks Codewarrior) and Windows NT +(Visual C++) indicates that we cannot assume much sophistication in the +use of file structure by development environments. The best that we can +hope for is the ability to combine a fixed list of source files, +libraries, and predefined preprocessor symbols into a single target. + +:mps:tag:`build.maint` The maintainability requirement (:mps:ref:`.req.maint`) implies +that we don't spend time trying to develop a set of tools to support +anything more complicated than the simple build function described +above. The effort in constructing and maintaining a portable system of +this kind is considerable. Such efforts failed in the Electronic +Publishing division of Harlequin. + + +Implementation +-------------- + +:mps:tag:`impl` The two implementation files `config.h`_ and `mpstd.h`_ can be +seen as preprocessor programs which "accept" build parameters and "emit" +configuration parameters (:mps:ref:`.fig.impl`). The build parameters are +defined either by the builder (in the case of target detection) or by +the build function (in the case of selecting the variety). + +:mps:tag:`fig.impl` + +=========================== ============== =========================================== +Build parameters Source file Configuration parameters +=========================== ============== =========================================== +:c:macro:`CONFIG_VAR_HOT` ⟶ ``config.h`` ⟶ :c:macro:`MPS_ASSERT_STRING`, etc. +``_WIN32`` ⟶ ``mpstd.h`` ⟶ :c:macro:`MPS_OS_W3`, etc. +=========================== ============== =========================================== + +:mps:tag:`impl.dep` No source code, other than the directives in `config.h`_ +and `mpstd.h`_, should depend on any build parameters. That is, +identifers beginning "CONFIG\_" should only appear in impl.h.config. +Code may depend on configuration parameters in certain, limited ways, as +defined below (:mps:ref:`.conf`). + +.. _`config.h`: <../code/config.h> +.. _`mpstd.h`: <../code/mpstd.h> + + +Target platform detection +......................... + +:mps:tag:`pf` The target platform is "detected" by the preprocessor directives in +`mpstd.h`_. + +:mps:tag:`pf.form` This file consists of sets of directives of the form:: + + #elif + #define MPS_PF_ + #define MPS_OS_ + #define MPS_ARCH_ + #define MPS_BUILD_ + #define MPS_T_WORD + #define MPS_T_ULONGEST + #define MPS_WORD_SHIFT + #define MPS_PF_ALIGN + +:mps:tag:`pf.detect` The conjunction of builder predefinitions is a constant +expression which detects the target platform. It is a logical AND of +expressions which look for preprocessor symbols defined by the build +environment to indicate the target. These must be accompanied by a +reference to the build tool documentation from which the symbols came. +For example:: + + /* "Predefined Macros" from "Visual Studio 2010" on MSDN + * . */ + + #elif defined(_MSC_VER) && defined(_WIN32) && defined(_M_IX86) + +:mps:tag:`pf.codes` The declarations of the platform, operating system, +architecture, and builder codes define preprocessor macros corresponding +the the target detected (:mps:ref:`.pf.detect`). For example:: + + #define MPS_PF_W3I3MV + #define MPS_OS_W3 + #define MPS_ARCH_I3 + #define MPS_BUILD_MV + +:mps:tag:`pf.word` The declaration of :c:macro:`MPS_T_WORD` defines the unsigned +integral type which corresponds, on the detected target, to the +machine word. It is used to defined the MPS Word type +(design.mps.type.word). For example:: + + #define MPS_T_WORD unsigned long + +We avoid using ``typedef`` here because `mpstd.h`_ could potentially +be included in assembly language source code. + +:mps:tag:`pf.word-width` The declaration of :c:macro:`MPS_WORD_WIDTH` defines the +number of bits in the type defined by :c:macro:`MPS_T_WORD` (:mps:ref:`.pf.word`) on the +target. For example:: + + #define MPS_WORD_WIDTH 32 + +:mps:tag:`pf.word-shift` The declaration of :c:macro:`MPS_WORD_SHIFT` defines the log +to the base 2 of :c:macro:`MPS_WORD_WIDTH`. For example:: + + #define MPS_WORD_SHIFT 5 + +:mps:tag:`pf.pf-align` The declaration of :c:macro:`MPS_PF_ALIGN` defines the minimum +alignment which must be used for a memory block to permit any normal +processor memory access. In other words, it is the maximum alignment +required by the processor for normal memory access. For example:: + + #define MPS_PF_ALIGN 4 + +:mps:tag:`pf.ulongest` The declaration of :c:macro:`MPS_T_ULONGEST` defines the +longest available unsigned integer type on the platform. This is +usually just ``unsigned long`` but under Microsoft C on 64-bit Windows +``unsigned long`` is just 32-bits (curse them!) For example:: + + #define MPS_T_ULONGEST unsigned __int64 + +:mps:tag:`pf.pf-string` The declaration of :c:macro:`MPS_PF_STRING` defines a string +that is used to identify the target platform in `version.c +<../code/version.c>`_. For example:: + + #define MPS_PF_STRING "w3i6mv" + + +Target varieties +................ + +:mps:tag:`var` The target variety is handled by preprocessor directives in +impl.h.config. + +:mps:tag:`var.form` The file contains sets of directives of the form:: + + #if defined(CONFIG_VAR_COOL) + #define CONFIG_ASSERT + #define CONFIG_ASSERT_ALL + #define CONFIG_STATS + +:mps:tag:`var.detect` The configured variety is one of the variety +preprocessor definitions passed to the build function +(:mps:ref:`.build.defs`), for example, :c:macro:`CONFIG_VAR_COOL`. These are +decoupled in order to keep the number of supported varieties small, +controlling each feature (for example, assertions) by a single +preprocessor definition, and maintaining flexibility about which +features are enabled in each variety. + +:mps:tag:`var.symbols` The directives should define whatever symbols are +necessary to control featrues. These symbols parameterize other parts +of the code, such as the declaration of assertions, etc. The symbols +should all begin with the prefix :c:macro:`CONFIG_`. + + +Source code configuration +------------------------- + +:mps:tag:`conf` This section describes how the configuration may affect the +source code of the MPS. + +:mps:tag:`conf.limit` The form of dependency allowed is carefully limited to +ensure that code remains maintainable and portable (:mps:ref:`.req.impact`). + +:mps:tag:`conf.min` The dependency of code on configuration parameters should +be kept to a minimum in order to keep the system maintainable +(:mps:ref:`.req.impact`). + + +Configuration Parameters +........................ + +:mps:tag:`conf.params` The compilation of a module is parameterized by:: + + MPS_ARCH_ + MPS_OS_ + MPS_BUILDER_ + MPS_PF_ + + +Abstract and Concrete Module Interfaces +....................................... + +:mps:tag:`abs.caller` Basic principle: the caller musn't be affected by +configuration of a module. This reduces complexity and dependency of +configuration. All callers use the same abstract interface. Caller +code does not change. + +:mps:tag:`abs.interface` Abstract interface includes: + +- method definitions (logical function prototypes which may be macro methods) +- names of types +- names of constants +- names of structures and fields which form part of the interface, and + possibly their types, depending on the protocol defined +- the protocols + +:mps:tag:`abs.rule` The abstract interface to a module may not be altered by a +configuration parameter. However, the concrete interface may vary. + +For example, this isn't allowed, because there is a change in the interface:: + + #if defined(PROT_FOO) + void ProtSpong(Foo foo, Bar bar); + #else + int ProtSpong(Bar bar, Foo foo); + #endif + +This example shows how:: + + #ifdef PROTECTION + void ProtSync(Space space); + /* more decls. */ + #else /* PROTECTION not */ + #define ProtSync(space) NOOP + /* more decls. */ + #endif /* PROTECTION */ + +or:: + + #if defined(PROT_FOO) + typedef struct ProtStruct { + int foo; + } ProtStruct; + #define ProtSpong(prot) X((prot)->foo) + #elif defined(PROT_BAR) + typedef struct ProtStruct { + float bar; + } ProtStruct; + #define ProtSpong(prot) Y((prot)->bar) + #else + #error "No PROT_* configured." + #endif + +Configuration parameters may not be used to vary implementations in C files. +For example, this sort of thing:: + + int map(void *base, size_t size) + { + #if defined(MPS_OS_W3) + VirtualAlloc(foo, bar, base, size); + #elif defined(MPS_OS_SU) + mmap(base, size, frob); + #else + #error "No implementation of map." + #endif + } + +This violates :mps:ref:`.no-spaghetti`. + + +To document +----------- +- What about constants in config.h? +- Update files to refer to this design document. +- Explain the role of ``mps.c`` +- Reference to ``build.txt`` +- Procedures for adding an architecture, etc. +- Reduce duplication in this document (especially after + `Configuration Parameters`_ which looks like it's been pasted in from + elsewhere.) + + +References +---------- + +.. [RB_2012-09-07] Richard Brooksby. Ravenbrook Limited. 2012-09-07. "`The critical path through the MPS `__". + +.. [RB_2012-09-13] Richard Brooksby. Ravenbrook Limited. 2013-09-13. "`The Configura CET custom mainline `__". + +.. [PP_2005-03-01] Pekka Pirinen. Global Graphics. 2005-03-01. "`MPS platforms `__". + + diff --git a/mps/manual/html/_sources/design/critical-path.txt b/mps/manual/html/_sources/design/critical-path.txt index 8bf3f0c5c44..26830c82baf 100644 --- a/mps/manual/html/_sources/design/critical-path.txt +++ b/mps/manual/html/_sources/design/critical-path.txt @@ -1,8 +1,364 @@ +.. _design-critical-path: + + .. index:: single: critical path single: path; critical single: Memory Pool System; critical path -.. _design-critical-path: -.. include:: ../../converted/critical-path.rst +The critical path through the MPS +================================= + + single: critical path + single: path; critical + single: Memory Pool System; critical path + + +Introduction +------------ +The critical path is a key concept in the design of the `Memory Pool +System `_. Code on the critical +path is usually executed more than any other code in the process. A +change of just one instruction on the critical path can make as much as +a 1% difference in overall run-time. A lot of the design of the MPS is +arranged around making the critical path as short and fast as possible. +This document describes the critical path and explains some of that +design, with reference to more detailed documents. + + +What makes the critical path critical +------------------------------------- +In order to determine which object can be recycled, the garbage +collector has to frequently examine a very large number of pointers in +the program's objects. It does this by scanning_ memory, both +allocated objects and roots (such as the thread stacks). + +This means that the scanning functions must loop over pretty much *every +word in memory* sooner or later. The MPS takes great pains to avoid +scanning memory which does not need scanning, but to get good +performance, scanning must be highly optimised. + +What's more, the scanning functions apply an operation called "fix" to +every pointer (or potential pointer) that they find in the objects in +memory. Fixing also attempts to eliminate uninteresting pointers as +fast as possible, but it has to do some work on every object that is +being considered for recycling, and that can be a large proportion of +the objects in existence. The path through fixing must also be highly +optimised, especially in the early stages. + + +How the MPS avoids scanning and fixing +-------------------------------------- +This is just a brief overview of how the MPS is designed to reduce +unnecessary scanning and fixing. + +Firstly, the MPS must occasionally decide which objects to try to +recycle. It does this using various facts it knows about the objects, +primarily their age and whether they've survived previous attempts at +recycling them. It then `"condemns"`_ a large number of objects +at once, and each of these objects must be "preserved" by fixing +references to them. + +When the MPS condemns objects it chooses sets of objects in a small set +of "zones" in memory (preferably a single zone). The zone of an object +can be determined extremely quickly from its address, without looking at +the object or any other data structure. + +The MPS arranges that objects which will probably die at the same time +are in the same zones. + +The MPS allocates in "segments". Each segment is of the order of one +"tract" of memory (generally the same as the operating system page +size, usually 4KiB or 8KiB) but may be larger if there are large +objects inside. The MPS maintains a "summary" of the zones pointed to +by all the pointers in a segment from previous scans. + +So, once the MPS has decided what to condemn, it can quickly eliminate +all segments which definitely do not point to anything in those zones. +This avoids a large amount of scanning. It is an implementation of a +`remembered set`_, though it is unlike that in most other GCs. + +In addition, the fix operation can quickly ignore pointers to the wrong +zones. This is called the "zone check" and is a BIBOP_ technique. + +Even if a pointer passes the zone check, it may still not point to a +segment containing condemned objects. The next stage of the fix +operation is to look up the segment pointed to by the pointer and see if +it was condemned. This is a fast lookup. + +After that, each pool class must decide whether the pointer is to a +condemned object and do something to preserve it. This code is still +critical. The MPS will have tried to condemn objects that are dead, but +those objects are still likely to be in segments with other objects that +must be preserved. The pool class fix method must quickly distinguish +between them. + +Furthermore, many objects will be preserved at least once in their +lifetime, so even the code that preserves an object needs to be highly +efficient. (Programs in languages like ML might not preserve 95% of +their objects even once, but many other programs will preserve nearly +all of theirs many times.) + + +Where to find the critical path +------------------------------- +Very briefly, the critical path consists of five stages: + +1. The scanner, which iterates over pointers in objects. The MPS has + several internal scanners, but the most important ones will be format + scanners in client code registered through :c:func:`mps_format_create()` + functions. + + .. note:: + + There needs to be a chapter in the manual explaining how to + write a good scanner. Then that could be linked from here. + +2. The first-stage fix, which filters out pointers inline in the + scanner. This is implemented in :c:func:`MPS_FIX()` macros in + mps.h_. + +.. _mps.h: ../code/mps.h + +3. The second-stage fix, which filters out pointers using general + information about segments. This is ``_mps_fix2`` in + `trace.c <../code/trace.c>`_. + +4. The third-stage fix, which filters out pointers using pool-specific + information. Implemented in pool class functions called :c:func:`AMCFix()`, + :c:func:`LOFix()`, etc. in pool*.c. + +5. Preserving the object, which might entail + + - marking_ it to prevent it being recycled; and/or + + - copying_ it and updating the original pointer (or just + updating the pointer, if the object has previously been + copied); and/or + + - adding it to a queue of objects to be scanned later, if it + contains pointers. + + Found in or near the pool class fix functions. + + +The format scanner +------------------ +The critical path starts when a format scan method is called. That is a +call from the MPS to a client function of type :c:type:`mps_fmt_scan_t` +registered with one of the :c:func:`mps_format_create()` functions in mps.h_. + +Here is an example of part of a format scanner for scanning contiguous +runs of pointers, from `fmtdy.c <../code/fmtdy.c>`_, the scanner for the `Open Dylan`_ +runtime:: + + static mps_res_t dylan_scan_contig(mps_ss_t mps_ss, + mps_addr_t *base, mps_addr_t *limit) + { + mps_res_t res; + mps_addr_t *p; /* reference cursor */ + mps_addr_t r; /* reference to be fixed */ + + MPS_SCAN_BEGIN(mps_ss) { + p = base; + loop: if(p >= limit) goto out; + r = *p++; + if(((mps_word_t)r&3) != 0) /* pointers tagged with 0 */ + goto loop; /* not a pointer */ + if(!MPS_FIX1(mps_ss, r)) goto loop; + res = MPS_FIX2(mps_ss, p-1); + if(res == MPS_RES_OK) goto loop; + return res; + out: assert(p == limit); + } MPS_SCAN_END(mps_ss); + + return MPS_RES_OK; + } + +(To help with understanding optimisation of this code, it's written in +a pseudo-assembler style, with one line roughly corresponding to each +instruction of an idealized intermediate code.) + +The MPS C interface provides macros to try to help optimise this code. +The ``mps_ss`` object is a "scan state" and contains data that is used +to eliminate uninteresting pointers now, and record information which +will be used to reduce scanning in future by maintaining the +remembered set. + +The macros :c:func:`MPS_SCAN_BEGIN()` and :c:func:`MPS_SCAN_END()` load key data +from the scan state into local variables, and hopefully into processor +registers. This avoids aliasing values that we know won't change when +calls are made to ``_mps_fix2`` later, and so allows the compiler to +keep the scan loop small and avoid unnecessary memory references. + +This scanner knows that words not ending in 0b00 aren't pointers to +objects, so it eliminates them straight away. This is a kind of +`reference tag`_ chosen by the client for its object representation. + +Next, the pointer is tested using :c:func:`MPS_FIX1()`. This performs fast +tests on the pointer without using any other memory. In particular, it +does the "zone check" described in section 3. If a pointer fails these +tests, it isn't interesting and can be skipped. It is very important +to proceed to the next pointer as fast as possible in this case. + +Having passed these tests, we need to fix the pointer using other data +in memory, and possibly call the MPS to preserve the object. This is +what :c:func:`MPS_FIX2()` does. The important distinction here is that +:c:func:`MPS_FIX2()` can fail and return an error code, which must be +propagated without ado by returning from the scanner. Separating +:c:func:`MPS_FIX1()` from :c:func:`MPS_FIX2()` helps keep the error handling code +away from the tight loop with the zone check. + +``MPS_FIX*``, the macro/inline part of the fix operation, are referred +to as "fix stage 1" or "the first stage fix" in other documents and +comments. + +If these inline checks pass, ``_mps_fix2`` is called. If the MPS has +been built as a separate object file or library, this is where the +function call out of the scan loop happens. Since version 1.110 of the +MPS, we encourage clients to compile the MPS in the same translation +unit as their format code, so that the compiler can be intelligent +about inlining parts of ``_mps_fix2`` in the format scanner. The +instructions for doing this are in `Building the Memory Pool System +<../manual/build.txt>`_, part of the manual. + + +The second stage fix in the MPM +------------------------------- +If a pointer gets past the first-stage fix filters, it is passed to +``_mps_fix2``, the "second stage fix". The second stage can filter out +yet more pointers using information about segments before it has to +consult the pool class. + +The first test applied is the "tract test". The MPS looks up the tract +containing the address in the tract table, which is a simple linear +table indexed by the address shifted -- a kind of flat page table. + +Note that if the arena has been extended, the tract table becomes less +simple, and this test may involved looking in more than one table. +This will cause a considerable slow-down in garbage collection +scanning. This is the reason that it's important to give a good +estimate of the amount of address space you will ever occupy with +objects when you initialize the arena. + +The pointer might not even be in the arena (and so not in any tract). +The first stage fix doesn't guarantee it. So we eliminate any pointers +not in the arena at this stage. + +If the pointer is in an allocated tract, then the table also contains +a cache of the "white set" -- the set of garbage collection traces for +which the tract is "interesting". If a tract isn't interesting, then +we know that it contains no condemned objects, and we can filter out +the pointer. + +If the tract is interesting them it's part of a segment containing +objects that have been condemned. The MPM can't know anything about +the internal layout of the segment, so at this point we dispatch to +the third stage fix. + +This dispatch is slightly subtle. We have a cache of the function to +dispatch to in the scan state, which has recently been looked at and +is with luck still in the processor cache. The reason there is a +dispatch at all is to allow for a fast changeover to emergency garbage +collection, or overriding of garbage collection with extra operations. +Those are beyond the scope of this document. Normally, ``ss->fix`` +points at :c:func:`PoolFix()`, and we rely somewhat on modern processor +`branch target prediction +`_). +:c:func:`PoolFix()` is passed the pool, which is fetched from the tract +table entry, and that should be in the cache. + +:c:func:`PoolFix()` itself dispatches to the pool class. Normally, a +dispatch to a pool class would indirect through the pool class object. +That would be a double indirection from the tract, so instead we have +a cache of the pool's fix method in the pool object. This also allows +a pool class to vary its fix method per pool instance, a fact that is +exploited to optimize fixing in the AMC Pool depending on what kind of +object format it is managing. + + +The third stage fix in the pool class +------------------------------------- +The final stage of fixing is entirely dependent on the pool class. The +MPM can't, in general, know how the objects within a pool are arranged, +so this is pool class specific code. + +Furthermore, the pool class must make decisions based on the "reference +rank" of the pointer. If a pointer is ambiguous (``RankAMBIG``) then it +can't be changed, so even a copying pool class can't move an object. +On the other hand, if the pointer is weak (``RankWEAK``) then the pool fix +method shouldn't preserve the object at all, even if it's condemned. + +The exact details of the logic that the pool fix must implement in +order to co-operate with the MPM and other pools are beyond the scope +of this document, which is about the critical path. Since it is on +the critical path, it's important that whatever the pool fix does is +simple and fast and returns to scanning as soon as possible. + +The first step, though, is to further filter out pointers which aren't +to objects, if that's its policy. Then, it may preserve the object, +according to its policy, and possibly ensure that the object gets +scanned at some point in the future, if it contains more pointers. + +If the object is moved to preserve it (for instance, if the pool class +implements a copying GC), or was already moved when fixing a previous +reference to it, the reference being fixed must be updated (this is +the origin of the term "fix"). + +As a simple example, :c:func:`LOFix()` is the pool fix method for the Leaf +Only pool class. It implements a marking garbage collector, and does +not have to worry about scanning preserved objects because it is used +to store objects that don't contain pointers. (It is used in compiler +run-time systems to store binary data such as character strings, thus +avoiding any scanning, decoding, or remembered set overhead for them.) + +:c:func:`LOFix()` filters any ambiguous pointers that aren't aligned, since +they can't point to objects it allocated. Otherwise it subtracts the +segment base address and shifts the result to get an index into a mark +bit table. If the object wasn't marked and the pointer is weak, then +it sets the pointer to zero, since the object is about to be recycled. +Otherwise, the mark bit is set, which preserves the object from +recycling when `LOReclaim` is called later on. `LOFix` illustrates +about the minimum and most efficient thing a pool fix method can do. + + +Other considerations +-------------------- +So far this document has described the ways in which the garbage +collector is designed around optimising the critical path. There are a +few other things that the MPS does that are important. + +Firstly, inlining is very important. The first stage fix is inlined +into the format scanner by being implemented in macros in +mps.h_. And to get even better inlining, `we +recommend <../manual/build.txt>`_ that the whole MPS is compiled in a +single translation unit with the client format and that strong global +optimisation is applied. + +Secondly, we are very careful with code annotations on the critical +path. Assertions, statistics, and telemetry are all disabled on the +critical path in "hot" (production) builds. (In fact, it's because the +critical path is critical that we can afford to leave annotations +switched on elsewhere.) + +Last, but by no means least, we pay a lot of brainpower and measurement +to the critical path, and are very very careful about changing it. Code +review around the critical path is especially vigilant. + +And we write long documents about it. + + +References +---------- +.. [MMRef] "The Memory Management Reference"; . +.. _scanning: http://www.memorymanagement.org/glossary/s.html#scan +.. _marking: http://www.memorymanagement.org/glossary/m.html#marking +.. _copying: http://www.memorymanagement.org/glossary/c.html#copying.garbage.collection +.. _`"condemns"`: http://www.memorymanagement.org/glossary/c.html#condemned.set +.. _BIBOP: http://www.memorymanagement.org/glossary/b.html#bibop +.. _`remembered set`: http://www.memorymanagement.org/glossary/r.html#remembered.set +.. _`reference tag`: http://www.memorymanagement.org/glossary/t.html#tag +.. _`Open Dylan`: http://opendylan.org/ + + diff --git a/mps/manual/html/_sources/design/diag.txt b/mps/manual/html/_sources/design/diag.txt new file mode 100644 index 00000000000..4c8a16a1137 --- /dev/null +++ b/mps/manual/html/_sources/design/diag.txt @@ -0,0 +1,290 @@ +.. _design-diag: + + +.. index:: + pair: diagnostic feedback; design + + +Diagnostic feedback +=================== + +.. mps:prefix:: design.mps.diag + + +Introduction +------------ + +:mps:tag:`intro` This document describes how to use the diagnostic feedback +mechanism in the Memory Pool System. + +:mps:tag:`sources` Initially abased on [RHSK_2007-04-13]_ and [RHSK_2007-04-18]_. + + +Overview +-------- + +Diagnostic feedback is information created by the MPS diagnostic +system for the purpose of helping MPS programmers client-code +programmers. + +Such a piece of information is called "a diagnostic". (See also +:mps:ref:`.parts`.) + +A diagnostic is not intended to be end-user readable (or visible), or +machine-parseable. + +A diagnostic is not intended to be stable from one release to the +next: it may be modified or removed at any time. + + +Requirements +------------ + +MPS diagnostic feedback code must do these things: + +- calculate, store, and propagate data; +- collate, synthesise, and format it into a human-useful diagnostic; +- control (for example, filter) output of diagnostics; +- use a channel to get the diagnostic out. + +Note: the knowledge/code/logic for constructing the human-useful +message is kept inside normal MPS source code. This means it is always +in-sync with changes to the MPS. This also means that any external +utilities used to display the messages do not need to understand, or +keep in sync with, the details of what's going inside the MPS. + + +Usage +----- + +To run the MPS and get diagnostic output from it: + +1. Use a variety with diagnostics compiled-in. Currently, that means + variety.di. See ``config.h``. + +2. Check that the diagnostics you require are generated, by looking in + MPS source for invocations of the appropriate macro (for example, + :c:func:`DIAG_SINGLEF()`). + +3. Check that the diagnostics you require will be output, by looking + at the diagnostic filter rules in ``diag.c``. + +4. Run the MPS and client in an environment that supports the channel + used (for example, at a command-line if using :c:func:`WriteF()`). + + +What is a diagnostic? +..................... + +A diagnostic has three parts: + +1. a trigger condition, that causes this diagnostic to be emitted; +2. a text tag (for example, "TraceStart") which is the name of this + diagnostic; and +3. a paragraph of human-useful text. + +A diagnostic is emitted by the MPS at a certain point in time when a +certain event happens. + +Diagnostics are not nested. Every diagnostic must have a tag. Each +diagnostic should have a unique tag (uniqueness is just to help the +humans; the diagnostic system does not care). + +The paragraph of text can be many lines long. It usually explains what +event caused the diagnostic to be emitted, and commonly also includes +the output of some :c:func:`Describe()` methods for various relevant +objects. (For example, the ``TraceStart`` diagnostic might call, and +include the output generated by, the :c:func:`TraceDescribe()` method). + +How do I control (filter) which diagnostics I see? +.................................................. + +All diagnostics are emitted and then filtered according to the +"diagnostic filter rules". + +The first level of control is filtering by tag. (For example, only +show ``TraceStart`` diagnostics). + +The second level of control is filtering by paragraph content. (For +example, only show ``TraceStart`` diagnostics where the trace is +started because a nursery generation is full). + +The third level of control is filtering by line content. (For example, +only show lines containing the word ``whiteSet``). + +See ``diag.c`` for details. + +Note: the entire filtering mechanism can be turned off, so that +diagnostics go immediately to ``mps_lib_get_stdout(0``, with no +buffering or filtering See impl.c.diag.filter-disable. + + +How to write a diagnostic +------------------------- + +Improve stateless Describe methods where possible +................................................. + +Where possible, don't put clever code into an event-triggered +diagnostic: put it into a stateless :c:func:`Describe()` method instead, and +then call that method when emitting your diagnostic. + +For example:: + + FooDescribe(Foo foo, mps_lib_FILE *stream) + { + /* show value of new "quux" field */ + WriteF(stream, "Foo: $P { quux: $U }\n", foo, foo->quux); + } + + FooWibble(Foo foo) + { + ... + DIAG_FIRSTF(( "FooWibble", "Wibbling foo $P", foo, NULL)); + DIAG( FooDescribe(foo, DIAG_STREAM); ); + DIAG_END("FooWibble"); + ... + } + +This is much better, because other people can use your human-useful +output in their diagnostics, or 'live' in a debugger. + + +Use the output macros +..................... + +For a simple diagnostic, use :c:func:`DIAG_SINGLEF()`. This begins the tag, +puts text into the paragraph, and ends the tag immediately. + +For a more complex diagnostic, the first call must be +:c:func:`DIAG_FIRSTF()`, which begins a diag tag. + +While a tag is current, you can add text to the diagnostic's paragraph +using :c:func:`DIAG_MOREF()`, and ``WriteF( DIAG_STREAM, ... )``. + +.. note:: + + :c:macro:`DIAG_STREAM` is not a real standard C library stream. If you + want stream-level access, you may use :c:func:`Stream_fputc()` and + :c:func:`Stream_fputs()`. + +End the tag by calling :c:macro:`DIAG_END`. + + +Compile away in non-diag varieties; no side effects +................................................... + +Wrap non-output code with the :c:func:`DIAG()` and :c:func:`DIAG_DECL()` macros, +to make sure that non-diag varieties do not execute +diagnostic-generating code. + +For complex diagnostic-generating code, it may be cleaner to move it +into a separate local function. Put ``_diag`` on the end of the function +name (for example, :c:func:`TraceStart_diag()`). + +Obviously, diagnostic-generating code must have no side effects. + + +Choosing tags +............. + +Tags should be valid C identifiers. Unless you know of a good reason +why not. (Not currently checked). + +There's no formal scheme for tag naming, but make it helpful and +informally hierarchical, for example, ``TraceBegin``, ``TraceStart``, +``TraceEnd``, and so on, not ``BeginTrace``, ``EndTrace``. + + +Writing good paragraph text +........................... + +IMPORTANT: Make your diagnostics easy to understand! Other people will +read your diagnostics! Make them clear and helpful. Do not make them +terse and cryptic. If you use symbols, print a key in the diagnostic. +(If you don't want to see this the screen clutter, then you can always +add a filter rule to your personal rule set to filter it out). + + +Maintaining helpful filter rules +................................ + +If you add a noisy diagnostic, add a rule to the default ruleset to +turn it off. + + +How the MPS diagnostic system works +----------------------------------- + +Channels +........ + +The recommended channel is :c:func:`WriteF()` to standard output. + +Other possible of future channels might be: + +- :c:func:`printf()`; +- a new type (yet to be defined) of ``mps_message``; +- squirt them into the telemetry-log-events system; +- telnet. + +Currently, only :c:func:`printf()` and :c:func:`WriteF()` are supported. See the +:c:macro:`DIAG_WITH_` macros in ``mpm.h``. + +You can also use a debugger to call :c:func:`Describe()` methods directly, +from within the debugger. + +Note: it is unfortunate that choice of channel may (for some channels) +also dictate the form of the code that synthesises the message. (For +example, :c:func:`WriteF()` style parameter-expansion is not possible when +using the :c:func:`printf()` channel, because there is no way to get +:c:func:`WriteF()` to produce its output into a string). This is just a +technical hitch; logically, the code that synthesises a diagnostic +message should not care which channel will be used to transmit it out +of the MPS. + + +Parts of the MPS diagnostic system +.................................. + +:mps:tag:`parts` The following facilities are considered part of the MPS +diagnostic system: + +- the :c:func:`Describe()` methods. +- the :c:macro:`DIAG` macros (:c:macro:`DIAG`, :c:macro:`DIAG_DECL`, ``DIAG_*F``, and so on); +- the :c:macro:`STATISTIC` macros (see ``mpm.h``); +- the :c:macro:`METER` macros and meter subsystem. + + +Related systems +............... + +The MPS diagnostic system is separate from the following other MPS +systems: + +- The telemetry-log-events system. This emits much more data, in a + less human-readable form, requires MPS-aware external tools, and is + more stable from release to release). In non-diagnostic telemetry + varieties, the telemetry-log-events system emits events that log all + normal MPS actions. In diagnostic telemetry varieties, it may emit + additional events containing diagnostic information. Additionally, + the telemetry-log-events stream might in future be available as a + channel for emitting human-readable text diagnostics. See also + design.mps.telemetry. + +- The MPS message system. This is present in all varieties, and + manages asynchronous communication from the MPS to the client + program). However, the MPS message system might in future also be + available as a channel for emitting diagnostics. See also + design.mps.message. + + + +References +---------- + +.. [RHSK_2007-04-13] Richard Kistruck. 2007-04-13. "`diagnostic feedback from the MPS `_". + +.. [RHSK_2007-04-18] Richard Kistruck. 2007-04-18. "`Diverse types of diagnostic feedback `_". + + diff --git a/mps/manual/html/_sources/design/finalize.txt b/mps/manual/html/_sources/design/finalize.txt index 9cd0521e392..01fbc83f1ab 100644 --- a/mps/manual/html/_sources/design/finalize.txt +++ b/mps/manual/html/_sources/design/finalize.txt @@ -1,6 +1,120 @@ +.. _design-finalize: + + .. index:: pair: finalization; design -.. _design-finalize: -.. include:: ../../converted/finalize.rst +Finalization +============ + +.. mps:prefix:: design.mps.finalize + + +Overview +-------- + +:mps:tag:`overview` Finalization is implemented internally using the +Guardian Pool Class (design.mps.poolmrg). Objects can be registered +for finalization using an interface function (called +:c:func:`mps_finalize()`). Notification of finalization is given to the client +via the messaging interface. ``PoolClassMRG`` (design.mps.poolmrg) +implements a Message Class which implements the finalization messages. + + +Requirements +------------ + +:mps:tag:`req` Historically only Dylan had requirements for finalization, +see req.dylan.fun.final. Now (2003-02-19) Configura have requirements +for finalization. Happily they are very similar. + + +Architecture +------------ + +External interface +.................. + +:mps:tag:`if.register` :c:func:`mps_finalize()` increases the number of times that +an object has been registered for finalization by one. The object must +have been allocated from the arena (space). Any finalization messages +that are created for this object will appear on the arena's message +queue. The MPS will attempt to finalize the object that number of +times. + +:mps:tag:`if.deregister` :c:func:`mps_definalize()` reduces the number of times that +the object located at ``obj`` has been registered for finalization by +one. It is an error to definalize an object that has not been +registered for finalization. + +:mps:tag:`if.deregister.not` At the moment (1997-08-20) :c:func:`mps_definalize()` +is not implemented. + +:mps:tag:`if.get-ref` :c:func:`mps_message_finalization_ref()` returns the reference +to the finalized object stored in the finalization message. + + +Implementation +-------------- + +:mps:tag:`int.over` Registering an object for finalization corresponds to +allocating a reference of rank FINAL to that object. This reference is +allocated in a guardian object in a pool of ``PoolClassMRG`` (see +design.mps.poolmrg). + +:mps:tag:`int.arena.struct` The MRG pool used for managing final references +is kept in the Arena (Space), referred to as the "final pool". + +:mps:tag:`int.arena.lazy` The pool is lazily created. It will not be created +until the first object is registered for finalization. + +:mps:tag:`int.arena.flag` There is a flag in the Arena that indicates +whether the final pool has been created yet or not. + +.. c:function:: Res ArenaFinalize(Arena arena, Ref addr) + +:mps:tag:`int.finalize.create` Creates the final pool if it has not been +created yet. + +:mps:tag:`int.finalize.alloc` Allocates a guardian in the final pool. + +:mps:tag:`int.finalize.write` Writes a reference to the object into the +guardian object. + +:mps:tag:`int.finalize.all` That's all. + +:mps:tag:`int.finalize.error` If either the creation of the pool or the +allocation of the object fails then the error will be reported back to +the caller. + +:mps:tag:`int.finalize.error.no-unwind` This function does not need to do +any unwinding in the error cases because the creation of the pool is +not something that needs to be undone. + +:mps:tag:`int.arena-destroy.empty` :c:func:`ArenaDestroy()` empties the message +queue by calling :c:func:`MessageEmpty()`. + +:mps:tag:`int.arena-destroy.final-pool` If the final pool has been created +then :c:func:`ArenaDestroy()` destroys the final pool. + +:mps:tag:`access` :c:func:`mps_message_finalization_ref()` needs to access the +finalization message to retrieve the reference and then write it to +where the client asks. This must be done carefully, in order to avoid +breaking the invariants or creating a hidden root. + +:mps:tag:`access.invariants` We protect the invariants by using special +routines :c:func:`ArenaRead()` and :c:func:`ArenaPoke()` to read and write the +reference. This works as long as there's no write-barrier collection. + +.. note:: + + Instead of :c:func:`ArenaPoke()`, we could put in an :c:func:`ArenaWrite()` + that would be identical to :c:func:`ArenaPoke()`, except that it would + :c:func:`AVER()` the invariant (or it can just :c:func:`AVER()` that there are + no busy traces unflipped). When we get write-barrier collection, + we could change it to do the real thing, but in the absence of a + write-barrier, it's functionally identical to :c:func:`ArenaPoke()`. + Pekka P. Pirinen, 1997-12-09. + + diff --git a/mps/manual/html/_sources/design/fix.txt b/mps/manual/html/_sources/design/fix.txt index 2d11b05a35f..9b2b059bc0a 100644 --- a/mps/manual/html/_sources/design/fix.txt +++ b/mps/manual/html/_sources/design/fix.txt @@ -1,6 +1,56 @@ +.. _design-fix: + + .. index:: pair: fix function; design -.. _design-fix: -.. include:: ../../converted/fix.rst +The generic fix function +======================== + +.. mps:prefix:: design.mps.fix + + +Introduction +------------- + +:mps:tag:`intro` Fix is the interface through which the existence of +references are communicated from the MPS client to the MPS. The +interface also allows the value of such references to be changed (this +is necessary in order to implement a moving memory manager). + + +Architecture +------------- + +:mps:tag:`protocol.was-marked` The :c:type:`ScanState` has a :c:type:`Bool` +``wasMarked`` field. This is used for finalization. + +:mps:tag:`protocol.was-marked.set` All pool-specific fix methods must set +the ``wasMarked`` field in the :c:type:`ScanState` that they are passed. + +:mps:tag:`protocol.was-marked.meaning` If the pool-specific fix method sets +the ``wasMarked`` field to :c:macro:`FALSE` it is indicating the object +referred to by the ref (the one that it is supposed to be fixing) has +not previously been marked (ie, this is the first reference to this +object that has been fixed), and that the object was white (in +condemned space). + +:mps:tag:`protocol.was-marked.conservative` It is always okay to set the +``wasMarked`` field to :c:macro:`TRUE`. + +:mps:tag:`protocol.was-marked.finalizable` The MRG pool (design.mps.poolmrg) +uses the value of the ``wasMarked`` field to determine whether an +object is finalizable. + + +Implementation +--------------- + +:mps:tag:`fix.nailed` In a copying collection, a non-ambiguous fix to a +broken heart should be snapped out *even if* there is a ``RankAMBIG`` +ref to same object (that is, if the broken heart is nailed); the +``RankAMBIG`` reference must either be stale (no longer in existence) +or bogus. + + diff --git a/mps/manual/html/_sources/design/guide.hex.trans.txt b/mps/manual/html/_sources/design/guide.hex.trans.txt index 3c877c5ad08..5f31fb48d26 100644 --- a/mps/manual/html/_sources/design/guide.hex.trans.txt +++ b/mps/manual/html/_sources/design/guide.hex.trans.txt @@ -1,6 +1,102 @@ +.. _design-guide.hex.trans: + + .. index:: pair: hexadecimal; transliterating -.. _design-guide.hex.trans: -.. include:: ../../converted/guide.hex.trans.rst +Transliterating the alphabet into hexadecimal +============================================= + +.. mps:prefix:: guide.hex.trans + + +Introduction +------------ + +:mps:tag:`scope` This document explains how to represent the alphabet as +hexadecimal digits. + +:mps:tag:`readership` This document is intended for anyone devising +arbitrary constants which may appear in hex-dumps. + +:mps:tag:`sources` This transliteration was supplied by RichardK in +mail.richardk.1997-04-07.13-44. + + +Transliteration +--------------- + +:mps:tag:`forward` The chosen transliteration is as follows:: + + ABCDEFGHIJKLMNOPQRSTUVWXYZ + ABCDEF9811C7340BC6520F3812 + +:mps:tag:`backward` The backwards transliteration is as follows:: + + 0 OU + 1 IJY + 2 TZ + 3 MW + 4 N + 5 S + 6 R + 7 L + 8 HX + 9 G + A A + B BP + C CKQ + D D + E E + F FV + +:mps:tag:`pad` If padding is required (to fill a hex constant length), you +should use 9's, because G is rare and can usually be inferred from +context. + +:mps:tag:`punc` There is no formal scheme for spaces, or punctuation. It is +suggested that you use 9 (as :mps:ref:`.pad`). + + +Justification +-------------- + +:mps:tag:`letters` The hexadecimal letters (A-F) are all formed by +similarity of sound. B and P sound similar, as do F and V, and C, K, & +Q can all sound similar. + +:mps:tag:`numbers` The numbers (0-9) are all formed by similarity of shape +(but see :mps:ref:`.trans.t`). Nevertheless, 1=IJY retains some similarity of +sound. + +:mps:tag:`trans.t` T is an exception to :mps:ref:`.numbers`, but is such a common +letter that it deserves it. + + +Notes +----- + +:mps:tag:`change` This transliteration differs from the old transliteration +used for signatures (see design.mps.sig(0)), as follows: J:6->1; +L:1->7; N:9->4; R:4->6; W:8->3; X:5->8; Y:E->I. + +:mps:tag:`problem.mw` There is a known problem that M and W are both common, +map to the same digit (3), and are hard to distinguish in context. + +:mps:tag:`find.c` It is possible to find all 8-digit hexadecimal constants +and how many times they're used in C files, using the following Perl +script:: + + perl5 -n -e 'BEGIN { %C=(); } if(/0x([0-9A-Fa-f]{8})/) { $C{$1} = +[] if( + !defined($C{$1})); push(@{$C{$1}}, $ARGV); } END { foreach $H (sort(keys(%C))) + { printf "%3d %s %s\n", scalar(@{$C{$H}}), $H, join(", ", @{@C{$H}}); } }' *.c + *.h + +:mps:tag:`comment` It is a good idea to add a comment to any constant +declaration indicating the English version and which letters were +selected (by capitalisation), e.g.:: + + #define SpaceSig ((Sig)0x5195BACE) /* SIGnature SPACE */ + + diff --git a/mps/manual/html/_sources/design/guide.impl.c.format.txt b/mps/manual/html/_sources/design/guide.impl.c.format.txt new file mode 100644 index 00000000000..89dad45e73b --- /dev/null +++ b/mps/manual/html/_sources/design/guide.impl.c.format.txt @@ -0,0 +1,427 @@ +.. _design-guide.impl.c.format: + + +.. index:: + pair: C language; formatting guide + pair: C language formatting; guide + + +C Style -- formatting +===================== + +.. mps:prefix:: guide.impl.c.format + pair: C language; formatting guide + pair: C language formatting; guide + + +Introduction +------------ + +:mps:tag:`scope` This document describes the Ravenbrook conventions for the +general format of C source code in the MPS. + +:mps:tag:`readership` This document is intended for anyone working on or with the +C source code. + + +General Formatting Conventions +------------------------------ + +Line Width +.......... + +:mps:tag:`width` Lines should be no wider than 72 characters. :mps:tag:`width.why` Many +people use 80 column terminal windows so that multiple windows can be +placed side by side. Restricting lines to 72 characters allows line +numbering to be used (in vi for example) and also allows diffs to be +displayed without overflowing the terminal. + +White Space +........... + +:mps:tag:`space.notab` No tab characters should appear in the source files. +Ordinary spaces should be used to indent and format the sources. +:mps:tag:`space.notab.why` Tab characters are displayed differently on different +platforms, and sometimes translated back and forth, destroying layout +information. + +:mps:tag:`space.punct` There should always be whitespace after commas and +semicolons and similar punctuation. + +:mps:tag:`space.op` Put white space around operators in expressions, except when +removing it would make the expression clearer by binding certain +sub-expressions more tightly. For example:: + + foo = x + y*z; + +:mps:tag:`space.control` One space between the keyword, ``switch``, ``while``, +``for`` and the following paren. :mps:tag:`space.control.why` This distinguishes +control statements lexically from function calls, making it easier to +distinguish them visually and when searching with tools like grep. + +:mps:tag:`space.function.not` No space between a function name and the following +paren beginning its argument list. + +Sections and Paragraphs +....................... + +:mps:tag:`section` Source files can be thought of as breaking down into +"sections" and "paragraphs". A section might be the leader comment of a +file, the imports, or a set of declarations which are related. + +:mps:tag:`section.space` Precede sections by two blank lines (except the first +one in the file, which should be the leader comment in any case). + +:mps:tag:`section.comment` Each section should start with a banner comment (see +.comment.banner) describing what the section contains. + +:mps:tag:`para` Within sections, code often breaks down into natural units called +"paragraphs". A paragraph might be a set of strongly related +declarations (Init and Finish, for example), or a few lines of code +which it makes sense to consider together (the assignment of fields into +a structure, for example). + +:mps:tag:`para.space` Precede paragraphs by a single blank line. + +Statements +.......... + +:mps:tag:`statement.one` Generally only have at most one statement per line. In +particular the following are deprecated:: + + if (thing) return; + + a=0; b=0; + + case 0: f = inRampMode ? AMCGen0RampmodeFrequency : AMCGen0Frequency; + +:mps:tag:`statement.one.why` Debuggers can often only place breakpoints on lines, +not expressions or statements within a line. The ``if (thing) return;`` is +a particularly important case, if thing is a reasonably rare return +condition then you might want to breakpoint it in a debugger session. +Annoying because ``if (thing) return;`` is quite compact and pleasing +otherwise. + +Indentation +........... + +:mps:tag:`indent` Indent the body of a block by two spaces. For formatting +purposes, the "body of a block" means: + +- statements between braces, +- a single statement following a lone ``if``; +- statements in a switch body; see .switch. + +(:mps:tag:`indent.logical` The aim is to group what we think of as logical +blocks, even though they may not exactly match how "block" is used in +the definition of C syntax). + +Some examples:: + + if (res != ResOK) { + SegFinish(&span->segStruct); + PoolFreeP(MV->spanPool, span, sizeof(SpanStruct)); + return res; + } + + if (res != ResOK) + goto error; + + if (j == block->base) { + if (j+step == block->limit) { + if (block->thing) + putc('@', stream); + } + } else if (j+step == block->limit) { + putc(']', stream); + pop_bracket(); + } else { + putc('.', stream); + } + + switch (c) { + case 'A': + c = 'A'; + p += 1; + break; + } + +:mps:tag:`indent.goto-label` Place each goto-label on a line of its own, +outdented to the same level as the surrounding block. Then indent the +non-label part of the statement normally. + +:: + + result foo(void) + { + statement(); + if (error) + goto foo; + statement(); + return OK; + + foo: + unwind(); + return ERROR; + } + +:mps:tag:`indent.case-label` Outdent case- and default-labels in a switch +statement in the same way as :mps:ref:`.indent.goto-label`. See :mps:ref:`.switch`. + +:mps:tag:`indent.cont` If an expression or statement won't fit on a single line, +indent the continuation lines by two spaces, apart from the following +exception: + +:mps:tag:`indent.cont.parens` if you break a statement inside a parameter list or +other parenthesized expression, indent so that the continuation lines up +just after the open parenthesis. For example:: + + PoolClassInit(&PoolClassMVStruct, + "MV", init, finish, allocP, freeP, + NULL, NULL, describe, isValid); + +:mps:tag:`indent.cont.expr` Note that when breaking an expression it is clearer +to place the operator at the start of the continuation line:: + + CHECKL(AddrAdd((Addr)chunk->pageTableMapped, + BTSize(chunk->pageTablePages)) + <= AddrAdd(chunk->base, chunk->ullageSize)); + +This is particularly useful in long conditional expressions that use && +and ||. For example:: + + } while(trace->state != TraceFINISHED + && (trace->emergency || traceWorkClock(trace) < pollEnd)); + +:mps:tag:`indent.hint` Usually, it is possible to determine the correct +indentation for a line by looking to see if the previous line ends with +a semicolon. If it does, indent to the same amount, otherwise indent by +two more spaces. The main exceptions are lines starting with a close +brace, goto-labels, and line-breaks between parentheses. + +Positioning of Braces +..................... + +:mps:tag:`brace.otb` Use the "One True Brace" (or OTB) style. This places the +open brace after the control word or expression, separated by a space, +and when there is an else, places that after the close brace. For +example:: + + if(isBase) { + new->base = limit; + new->limit = block->limit; + block->limit = base; + new->next = block->next; + block->next = new; + } else { + new->base = block->base; + new->limit = base; + block->base = limit; + new->next = block; + *prev = new; + } + +The same applies to struct, enum, union. + +:mps:tag:`brace.otb.function.not` OTB is never used for function definitions. + +:mps:tag:`brace.always` Braces are always required after ``if``, ``else``, ``switch``, +``while``, ``do``, and ``for``. + +:mps:tag:`brace.always.except` Except that a lone ``if`` with no ``else`` is allowed +to drop its braces when its body is a single simple statement. Typically +this will be a ``goto`` or an assignment. For example:: + + if (res != ResOK) + goto failStart; + +Note in particular that an ``if`` with an ``else`` must have braces on both +paths. + +Switch Statements +................. + +:mps:tag:`switch` format switch statements like this:: + + switch (action) { + case WIBBLE: + case WOBBLE: + { + int angle; + err = move(plate, action, &angle); + } + break; + + case QUIET: + drop(); + /* fall-through */ + + case QUIESCENT: + err = 0; + break; + + default: + NOTREACHED; + break; + } + +The component rules that result in this style are: + +:mps:tag:`switch.break` The last line of every case-clause body must be an +unconditional jump statement (usually ``break``, but may be ``goto``, +``continue``, or ``return``), or if a fall-through is intended, the comment +``/* fall-through */``. (Note: if the unconditional jump should never be +taken, because of previous conditional jumps, use :c:macro:`NOTREACHED` on the +line before it). This rule is to prevent accidental fall-throughs, even +if someone makes a editing mistake that causes a conditional jump to be +missed. + +:mps:tag:`switch.default` It is usually a good idea to have a default-clause, +even if all it contains is :c:macro:`NOTREACHED` and ``break``. Remember that +:c:macro:`NOTREACHED` doesn't stop the process in all build varieties. + + +Formatting Comments +................... + +:mps:tag:`comment` There are three types of comments: banners, paragraph +comments, and columnar comments. + +:mps:tag:`comment.banner` Banner comments come at the start of sections. A banner +comment consists of a heading usually composed of a symbol, an em-dash +(--) and an short explanation, followed by English text which is +formatted using conventional text documentation guidelines (see +guide.text). The open and close comment tokens (``/*`` and ``*/``) are +placed at the top and bottom of a column of asterisks. The text is +separated from the asterisks by one space. Place a blank line between +the banner comment and the section it comments. For example:: + + /* BlockStruct -- Block descriptor + * + * The pool maintains a descriptor structure for each + * contiguous allocated block of memory it manages. + * The descriptor is on a simple linked-list of such + * descriptors, which is in ascending order of address. + */ + + typedef struct BlockStruct { + +:mps:tag:`comment.para` Paragraph comments come at the start of paragraphs in the +code. A paragraph comment consists of formatted English text, with each +line wrapped by the open and close comment tokens (``/*`` and ``*/``). +(This avoids problems when cutting and pasting comments.) For example:: + + /* If the freed area is in the base sentinel then insert */ + /* the new descriptor after it, otherwise insert before. */ + if(isBase) { + +:mps:tag:`comment.para.precede` Paragraph comments, even one-liners, precede the +code to which they apply. + +:mps:tag:`comment.column` Columnar comments appear in a column to the right of +the code. They should be used sparingly, since they clutter the code and +make it hard to edit. Use them on variable declarations and structure, +union, or enum declarations. They should start at least at column 32 +(counting from 0, that is, on a tab-stop), and should be terse +descriptive text. Abandon English sentence structure if this makes the +comment clearer. Don't write more than one line. Here's an example:: + + typedef struct PoolMVStruct { + Pool blockPool; /* for block descriptors */ + Pool spanPool; /* for span descriptors */ + size_t extendBy; /* size to extend pool by */ + size_t avgSize; /* estimate of allocation size */ + size_t maxSize; /* estimate of maximum size */ + Addr space; /* total free space in pool */ + Addr lost; /* lost when free can't allocate */ + struct SpanStruct *spans; /* span chain */ + } PoolMVStruct; + +Macros +...... + +:mps:tag:`macro.careful` Macros in C are a real horror bag, be extra careful. +There's lots that could go here, but proper coverage probably deserves a +separate document. Which isn't written yet. + +:mps:tag:`macro.general` Do try and follow the other formatting conventions for +code in macro definitions. + +:mps:tag:`macro.backslash` Backslashes used for continuation lines in macro +definitions should be put on the right somewhere where they will be less +in the way. Example:: + + #define RAMP_RELATION(X) \ + X(RampOUTSIDE, "outside ramp") \ + X(RampBEGIN, "begin ramp") \ + X(RampRAMPING, "ramping") \ + X(RampFINISH, "finish ramp") \ + X(RampCOLLECTING, "collecting ramp") + + +History +------- + +- 2007-06-04 DRJ_ Adopted from Harlequin MMinfo version and edited. + +- 2007-06-04 DRJ_ Changed .width from 80 to 72. Banned space between + ``if`` and ``(``. Required braces on almost everything. Clarified that + paragraph comments precede the code. + +- 2007-06-13 RHSK_ Removed .brace.block, because MPS source always + uses .brace.otb. Remove .indent.elseif because it is obvious (ahem) and + showing an example is sufficient. New rules for .switch.*: current MPS + practice is a mess, so lay down a neat new law. + +- 2007-06-27 RHSK_ Added :mps:ref:`.space.function.not`. + +- 2007-07-17 DRJ_ Added .macro.\* + +- 2012-09-26 RB_ Converted to Markdown and reversed inconsistent + switch "law". + +.. _DRJ: http://www.ravenbrook.com/consultants/drj +.. _RHSK: http://www.ravenbrook.com/consultants/rhsk +.. _RB: http://www.ravenbrook.com/consultants/rb + + +Copyright and License +--------------------- + +This document is copyright © 2002-2012 [Ravenbrook +Limited](http://www.ravenbrook.com/). 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/manual/html/_sources/design/index.txt b/mps/manual/html/_sources/design/index.txt index ce234220b78..a0c98237228 100644 --- a/mps/manual/html/_sources/design/index.txt +++ b/mps/manual/html/_sources/design/index.txt @@ -9,6 +9,7 @@ Design config critical-path guide.hex.trans + guide.impl.c.format keyword-arguments ring sig diff --git a/mps/manual/html/_sources/design/interface-c.txt b/mps/manual/html/_sources/design/interface-c.txt new file mode 100644 index 00000000000..b8db5831226 --- /dev/null +++ b/mps/manual/html/_sources/design/interface-c.txt @@ -0,0 +1,331 @@ +.. _design-interface-c: + + +.. index:: + pair: C interface; design + + +C interface design +================== + +.. mps:prefix:: design.mps.interface.c + + +Introduction +------------ + +:mps:tag:`scope` This document is the design for the Memory Pool System +(MPS) interface to the C Language, impl.h.mps. + +:mps:tag:`bg` See mail.richard.1996-07-24.10-57. + + +Analysis +-------- + +Goals +..... + +:mps:tag:`goal.c` The file impl.h.mps is the C external interface to the +MPS. It is the default interface between client code written in C and +the MPS. :mps:tag:`goal.cpp` impl.h.mps is not specifically designed to be +an interface to C++, but should be usable from C++. + + +Requirements +............ + +:mps:tag:`req` The interface must provide an interface from client code +written in C to the functionality of the MPS required by the product +(see req.product), Dylan (req.dylan), and the Core RIP (req.epcore). + +``mps.h`` may not include internal MPS header files (such as +``pool.h``). + +It is essential that the interface cope well with change, in order to +avoid restricting possible future MPS developments. This means that +the interface must be "open ended" in its definitions. This accounts +for some of the apparently tortuous methods of doing things +(``mps_fmt_A_t``, for example). The requirement is that the MPS should +be able to add new functionality, or alter the implementation of +existing functionality, without affecting existing client code. A +stronger requirement is that the MPS should be able to change without +*recompiling* client code. This is not always possible. + +.. note:: + + `.naming.global` was presumably done in response to unwritten + requirements regarding the use of the name spaces in C, perhaps + these: + + - :mps:tag:`req.name.iso` The interface shall not conflict in terms of + naming with any interfaces specified by ISO C and all reasonable + future versions. + + - :mps:tag:`req.name.general` The interface shall use a documented and + reasonably small portion of the namespace so that clients can + interoperate easily. + + David Jones, 1998-10-01. + + +Architecture +------------ + +:mps:tag:`fig.arch` The architecture of the MPS Interface + +[missing figure] + +Just behind ``mps.h`` is the file ``mpsi.c``, the "MPS interface +layer" which does the job of converting types and checking parameters +before calling through to the MPS proper, using internal MPS methods. + + +General conventions +------------------- + +:mps:tag:`naming` The external interface names should adhere to the +documented interface conventions; these are found in +doc.mps.ref-man.if-conv(0).naming. They are paraphrased/recreated +here. + +:mps:tag:`naming.unixy` The external interface does not follow the same +naming conventions as the internal code. The interface is designed to +resemble a more conventional C, Unix, or Posix naming convention. + +:mps:tag:`naming.case` Identifiers are in lower case, except +non-function-like macros, which are in upper case. + +:mps:tag:`naming.global` All publicised identifiers are +prefixed ``mps_`` or :c:macro:`MPS_`. + +:mps:tag:`naming.all` All identifiers defined by the MPS +should begin ``mps_`` or :c:macro:`MPS_` or ``_mps_``. + +:mps:tag:`naming.type` Types are suffixed ``_t``. + +:mps:tag:`naming.struct` Structure types and tags are suffixed ``_s``. + +:mps:tag:`naming.union` Unions types and tags are suffixed ``_u``. + +:mps:tag:`naming.scope` The naming conventions apply to all identifiers (see +ISO C §6.1.2); this includes names of functions, variables, types +(through typedef), structure and union tags, enumeration members, +structure and union members, macros, macro parameters, labels. + +:mps:tag:`naming.scope.labels` labels (for ``goto`` statements) should be +rare, only in special block macros and probably not even then. + +.. note:: + + This principle is not adhered to in the source code, which uses + ``goto`` for handling error cases. Gareth Rees, 2013-05-27. + +:mps:tag:`naming.scope.other` The naming convention would also extend to +enumeration types and parameters in functions prototypes but both of +those are prohibited from having names in an interface file. + +:mps:tag:`type.gen` The interface defines memory addresses as ``void *`` and +sizes as ``size_t`` for compatibility with standard C (in particular, +with :c:func:`malloc()`). These types must be binary compatible with the +internal types :c:type:`Addr` and :c:type:`Size` respectively. Note that this +restricts the definitions of the internal types :c:type:`Addr` and :c:type:`Size` +when the MPS is interfaced with C, but does not restrict the MPS in +general. + +:mps:tag:`type.opaque` Opaque types are defined as pointers to structures +which are never defined. These types are cast to the corresponding +internal types in ``mpsi.c``. + +:mps:tag:`type.trans` Some transparent structures are defined. The client is +expected to read these, or poke about in them, under restrictions +which should be documented. The most important is probably the +allocation point (:c:type:`mps_ap_s`) which is part of allocation buffers. +The transparent structures must be binary compatible with +corresponding internal structures. For example, the fields of +:c:type:`mps_ap_s` must correspond with :c:type:`APStruct` internally. This is +checked by ``mpsi.c`` in :c:func:`mps_check()`. + +:mps:tag:`type.pseudo` Some pseudo-opaque structures are defined. These only +exist so that code can be inlined using macros. The client code +shouldn't mess with them. The most important case of this is the scan +state (:c:type:`mps_ss_s`) which is accessed by the in-line scanning macros, +``MPS_SCAN_*`` and ``MPS_FIX*``. + +:mps:tag:`type.enum` There should be no enumeration types in the interface. +Note that enum specifiers (to declare integer constants) are fine as +long as no type is declared. See guide.impl.c.misc.enum.type. + +:mps:tag:`type.fun` Whenever function types or derived function types (such +as pointer to function) are declared a prototype should be used and +the parameters to the function should not be named. This includes the +case where you are declaring the prototype for an interface function. + +:mps:tag:`type.fun.example` So use:: + + extern mps_res_t mps_alloc(mps_addr_t *, mps_pool_t, size_t, ...); + +rather than:: + + extern mps_res_t mps_alloc(mps_addr_t *addr_return, mps_pool_t pool , size_t size, ...); + +and:: + + typedef mps_addr_t (*mps_fmt_class_t)(mps_addr_t); + +rather than:: + + typedef mps_addr_t (*mps_fmt_class_t)(mps_addr_t object); + +See guide.impl.c.misc.prototype.parameters. + + +Checking +-------- + +:mps:tag:`check.space` When the arena needs to be recovered from a parameter +it is check using ``AVERT(Foo, foo)`` before any attempt to call +``FooArena(foo)``. The macro :c:func:`AVERT()` in impl.h.assert performs +simple thread-safe checking of ``foo``, so it can be called outside of +:c:func:`ArenaEnter()` and :c:func:`ArenaLeave()`. + +:mps:tag:`check.types` We use definitions of types in both our external +interface and our internal code, and we want to make sure that they +are compatible. (The external interface changes less often and hides +more information.) At first, we were just checking their sizes, which +wasn't very good, but I've come up with some macros which check the +assignment compatibility of the types too. This is a sufficiently +useful trick that I thought I'd send it round. It may be useful in +other places where types and structures need to be checked for +compatibility at compile time. + +These macros don't generate warnings on the compilers I've tried. + +.. c:function:: COMPATLVALUE(lvalue1, lvalue2) + +This macro checks the assignment compatibility of two lvalues. It uses +:c:func:`sizeof()` to ensure that the assignments have no effect. :: + + #define COMPATLVALUE(lv1, lv2) \ + ((void)sizeof((lv1) = (lv2)), (void)sizeof((lv2) = (lv1)), TRUE) + +.. c:function:: COMPATTYPE(type1, type2) + +This macro checks that two types are assignment-compatible and equal +in size. The hack here is that it generates an lvalue for each type by +casting zero to a pointer to the type. The use of :c:func:`sizeof()` avoids +the undefined behaviour that would otherwise result from dereferencing +a null pointer. :: + + #define COMPATTYPE(t1, t2) \ + (sizeof(t1) == sizeof(t2) && \ + COMPATLVALUE(*((t1 *)0), *((t2 *)0))) + +.. c:function:: COMPATFIELDAPPROX(structure1, field1, structure2, field2) + +This macro checks that the offset and size of two fields in two +structure types are the same. :: + + #define COMPATFIELDAPPROX(s1, f1, s2, f2) \ + (sizeof(((s1 *)0)->f1) == sizeof(((s2 *)0)->f2) && \ + offsetof(s1, f1) == offsetof(s2, f2)) + +.. c:function:: COMPATFIELD(structure1, field1, structure2, field2) + +This macro checks the offset, size, and assignment-compatibility of +two fields in two structure types. :: + + #define COMPATFIELD(s1, f1, s2, f2) \ + (COMPATFIELDAPPROX(s1, f1, s2, f2) && \ + COMPATLVALUE(((s1 *)0)->f1, ((s2 *)0)->f2)) + + +Binary compatibility issues +--------------------------- + +As in, "Enumeration types are not allowed" (see +mail.richard.1995-09-08.09-28). + +There are two main aspects to run-time compatibility: binary interface +and protocol. The binary interface is all the information needed to +correctly use the library, and includes external symbol linkage, +calling conventions, type representation compatibility, structure +layouts, etc. The protocol is how the library is actually used by the +client code -- whether this is called before that -- and determines +the semantic correctness of the client with respect to the library. + +The binary interface is determined completely by the header file and +the target. The header file specifies the external names and the +types, and the target platform specifies calling conventions and type +representation. There is therefore a many-to-one mapping between the +header file version and the binary interface. + +The protocol is determined by the implementation of the library. + + +Constraints +----------- + +:mps:tag:`cons` The MPS C Interface constrains the MPS in order to provide +useful memory management services to a C or C++ program. + +:mps:tag:`cons.addr` The interface constrains the MPS address type, Addr +(design.mps.type.addr), to being the same as C's generic pointer type, +``void *``, so that the MPS can manage C objects in the natural way. + +:mps:tag:`pun.addr` We pun the type of :c:type:`mps_addr_t` (which is ``void *``) +into :c:type:`Addr` (an incomplete type, see design.mps.type.addr). This +happens in the call to the scan state's fix function, for example. + +:mps:tag:`cons.size` The interface constrains the MPS size type, :c:type:`Size` +(design.mps.type.size), to being the same as C's size type, +``size_t``, so that the MPS can manage C objects in the natural way. + +:mps:tag:`pun.size` We pun the type of ``size_t`` in mps.h into :c:type:`Size` in +the MPM, as an argument to the format methods. We assume this works. + +:mps:tag:`cons.word` The MPS assumes that :c:type:`Word` (design.mps.type.word) +and :c:type:`Addr` (design.mps.type.addr) are the same size, and the +interface constrains :c:type:`Word` to being the same size as C's generic +pointer type, ``void *``. + + +Notes +----- + +The file ``mpstd.h`` is the MPS target detection header. It decodes +preprocessor symbols which are predefined by build environments in +order to determine the target platform, and then defines uniform +symbols, such as :c:macro:`MPS_ARCH_I3`, for use internally by the MPS. + +There is a design document for the mps interface, +design.mps.interface, but it was written before we had the idea of +having a C interface layer. It is quite relevant, though, and could be +updated. We should use it during the review. + +All exported identifiers and file names should begin with ``mps_`` or +:c:macro:`MPS_` so that they don't clash with other systems. + +We should probably have a specialized set of rules and a special +checklist for this interface. + +:mps:tag:`fmt.extend` This paragraph should be an explanation of why +``mps_fmt_A_t`` is so called. The underlying reason is future +extensibility. + +:mps:tag:`thread-safety` Most calls through this interface lock the space +and therefore make the MPM single-threaded. In order to do this they +must recover the space from their parameters. Methods such as +:c:func:`ThreadSpace()` must therefore be callable when the space is *not* +locked. These methods are tagged with the tag of this note. + +:mps:tag:`lock-free` Certain functions inside the MPM are thread-safe and do +not need to be serialized by using locks. They are marked with the tag +of this note. + +:mps:tag:`form` Almost all functions in this implementation simply cast +their arguments to the equivalent internal types, and cast results +back to the external type, where necessary. Only exceptions are noted +in comments. + + diff --git a/mps/manual/html/_sources/design/io.txt b/mps/manual/html/_sources/design/io.txt new file mode 100644 index 00000000000..d5cecd5b936 --- /dev/null +++ b/mps/manual/html/_sources/design/io.txt @@ -0,0 +1,407 @@ +.. _design-io: + + +.. index:: + pair: I/O subsystem; design + + +I/O subsystem +============= + +.. mps:prefix:: design.mps.io + + +Introduction +------------ + +:mps:tag:`intro` This document is the design of the MPS I/O Subsystem, a +part of the plinth. + +:mps:tag:`readership` This document is intended for MPS developers. + + +Background +---------- + +:mps:tag:`bg` This design is partly based on the design of the Internet User +Datagram Protocol (UDP). Mainly I used this to make sure I hadn't left +out anything which we might need. + + +Purpose +------- + +:mps:tag:`purpose` The purpose of the MPS I/O Subsystem is to provide a +means to measure, debug, control, and test a memory manager build +using the MPS. + +:mps:tag:`purpose.measure` Measurement consists of emitting data which can +be collected and analysed in order to improve the attributes of +application program, quite possibly by adjusting parameters of the +memory manager (see overview.mps.usage). + +:mps:tag:`purpose.control` Control means adjusting the behaviour of the MM +dynamically. For example, one might want to adjust a parameter in +order to observe the effect, then transfer that adjustment to the +client application later. + +:mps:tag:`purpose.test` Test output can be used to ensure that the memory +manager is behaving as expected in response to certain inputs. + + +Requirements +------------ + +General +....... + +:mps:tag:`req.fun.non-hosted` The MPM must be a host-independent system. + +:mps:tag:`req.attr.host` It should be easy for the client to set up the MPM +for a particular host (such as a washing machine). + +Functional +.......... + +:mps:tag:`req.fun.measure` The subsystem must allow the MPS to transmit +quantitative measurement data to an external tool so that the system +can be tuned. + +:mps:tag:`req.fun.debug` The subsystem must allow the MPS to transmit +qualitative information about its operation to an external tool so +that the system can be debugged. + +:mps:tag:`req.fun.control` The subsystem must allow the MPS to receive +control information from an external tool so that the system can be +adjusted while it is running. + +:mps:tag:`req.dc.env.no-net` The subsystem should operate in environments +where there is no networking available. + +:mps:tag:`req.dc.env.no-fs` The subsystem should operate in environments +where there is no filesystem available. + + +Architecture +------------ + +:mps:tag:`arch.diagram` I/O Architecture Diagram + +[missing diagram] + +:mps:tag:`arch.int` The I/O Interface is a C function call interface by +which the MPM sends and receives "messages" to and from the hosted I/O +module. + +:mps:tag:`arch.module` The modules are part of the MPS but not part of the +freestanding core system (see design.mps.exec-env). The I/O module is +responsible for transmitting those messages to the external tools, and +for receiving messages from external tools and passing them to the +MPM. + +:mps:tag:`arch.module.example` For example, the "file implementation" might +just send/write telemetry messages into a file so that they can be +received/read later by an off-line measurement tool. + +:mps:tag:`arch.external` The I/O Interface is part of interface to the +freestanding core system (see design.mps.exec-env). This is so that +the MPS can be deployed in a freestanding environment, with a special +I/O module. For example, if the MPS is used in a washing machine the +I/O module could communicate by writing output to the seven-segment +display. + + +Example configurations +...................... + +:mps:tag:`example.telnet` This shows the I/O subsystem communicating with a +telnet client over a TCP/IP connection. In this case, the I/O +subsystem is translating the I/O Interface into an interactive text +protocol so that the user of the telnet client can talk to the MM. + +[missing diagram] + +:mps:tag:`example.file` This shows the I/O subsystem dumping measurement +data into a file which is later read and analysed. In this case the +I/O subsystem is simply writing out binary in a format which can be +decoded. + +[missing diagram] + +:mps:tag:`example.serial` This shows the I/O subsystem communicating with a +graphical analysis tool over a serial link. This could be useful for a +developer who has two machines in close proximity and no networking +support. + +:mps:tag:`example.local` In this example the application is talking directly +to the I/O subsystem. This is useful when the application is a +reflective development environment (such as MLWorks) which wants to +observe its own behaviour. + +[missing diagram] + + +Interface +--------- + +:mps:tag:`if.msg` The I/O interface is oriented around opaque binary +"messages" which the I/O module must pass between the MPM and external +tools. The I/O module need not understand or interpret the contents of +those messages. + +:mps:tag:`if.msg.opaque` The messages are opaque in order to minimize the +dependency of the I/O module on the message internals. It should be +possible for clients to implement their own I/O modules for unusual +environments. We do not want to reveal the internal structure of our +data to the clients. Nor do we want to burden them with the details of +our protocols. We'd also like their code to be independent of ours, so +that we can expand or change the protocols without requiring them to +modify their modules. + +:mps:tag:`if.msg.dgram` Neither the MPM nor the external tools should assume +that the messages will be delivered in finite time, exactly once, or +in order. This will allow the I/O modules to be implemented using +unreliable transport layers such as the Internet User Datagram Protocl +(UDP). It will also give the I/O module the freedom to drop +information rather than block on a congested network, or stop the +memory manager when the disk is full, or similar events which really +shouldn't cause the memory manager to stop working. The protocols we +need to implement at the high level can be design to be robust against +lossage without much difficulty. + + +I/O module state +................ + +:mps:tag:`if.state` The I/O module may have some internal state to preserve. +The I/O Interface defines a type for this state, :c:type:`mps_io_t`, a +pointer to an incomplete structure :c:type:`mps_io_s`. The I/O module is at +liberty to define this structure. + + +Message types +............. + +:mps:tag:`if.type` The I/O module must be able to deliver messages of +several different types. It will probably choose to send them to +different destinations based on their type: telemetry to the +measurement tool, debugging output to the debugger, etc. :: + + typedef int mps_io_type_t; + enum { + MPS_IO_TYPE_TELEMETRY, + MPS_IO_TYPE_DEBUG + }; + + +Limits +...... + +:mps:tag:`if.message-max` The interface will define an unsigned integral +constant :c:macro:`MPS_IO_MESSAGE_MAX` which will be the maximum size of +messages that the MPM will pass to :c:func:`mps_io_send()` (:mps:ref:`.if.send`) and +the maximum size it will expect to receive from :c:func:`mps_io_receive()`. + + +Interface set-up and tear-down +.............................. + +:mps:tag:`if.create` The MPM will call :c:func:`mps_io_create()` to set up the I/O +module. On success, this function should return :c:macro:`MPS_RES_OK`. It may +also initialize a "state" value which will be passed to subsequent +calls through the interface. + +:mps:tag:`if.destroy` The MPM will call :c:func:`mps_io_destroy()` to tear down +the I/O module, after which it guarantees that the state value will +not be used again. The ``state`` parameter is the state previously +returned by :c:func:`mps_io_create()` (:mps:ref:`.if.create`). + +Message send and receive +........................ + +.. c:function:: extern mps_res_t mps_io_send(mps_io_t state, mps_io_type_t type, void *message, size_t size) + +:mps:tag:`if.send` The MPM will call :c:func:`mps_io_send()` when it wishes to +send a message to a destination. The ``state`` parameter is the state +previously returned by :c:func:`mps_io_create()` (:mps:ref:`.if.create`). The +``type`` parameter is the type (:mps:ref:`.if.type`) of the message. The +``message`` parameter is a pointer to a buffer containing the message, +and ``size`` is the length of that message, in bytes. The I/O module +must make an effort to deliver the message to the destination, but is +not expected to guarantee delivery. The function should return +:c:macro:`MPS_RES_IO` only if a serious error occurs that should cause the +MPM to return with an error to the client application. Failure to +deliver the message does not count. + +.. note:: + + Should there be a timeout parameter? What are the timing + constraints? :c:func:`mps_io_send()` shouldn't block. + +.. c:function:: extern mps_res_t mps_io_receive(mps_io_t state, void **buffer_o, size_t *size_o) + +:mps:tag:`if.receive` The MPM will call :c:func:`mps_io_receive()` when it wants +to see if a message has been sent to it. The ``state`` parameter is +the state previously returned by :c:func:`mps_io_create()` (:mps:ref:`.if.create`). +The ``buffer_o`` parameter is a pointer to a value which should be +updated with a pointer to a buffer containing the message received. +The ``size_o`` parameter is a pointer to a value which should be +updated with the length of the message received. If there is no +message ready for receipt, the length returned should be zero. + +.. note:: + + Should we be able to receive truncated messages? How can this be + done neatly? + + +I/O module implementations +-------------------------- + +Routeing +........ + +The I/O module must decide where to send the various messages. A +file-based implementation could put them in different files based on +their types. A network-based implementation must decide how to address +the messages. In either case, any configuration must either be +statically compiled into the module, or else read from some external +source such as a configuration file. + + +Notes +----- + +The external tools should be able to reconstruct stuff from partial +info. For example, you come across a fragment of an old log containing +just a few old messages. What can you do with it? + +Here's some completely untested code which might do the job for UDP. +:: + + #include "mpsio.h" + + #include + #include + #include + #include + #include + #include + + typedef struct mps_io_s { + int sock; + struct sockaddr_in mine; + struct sockaddr_in telemetry; + struct sockaddr_in debugging; + } mps_io_s; + + static mps_bool_t inited = 0; + static mps_io_s state; + + + mps_res_t mps_io_create(mps_io_t *mps_io_o) + { + int sock, r; + + if(inited) + return MPS_RES_LIMIT; + + state.mine = /* setup somehow from config */; + state.telemetry = /* setup something from config */; + state.debugging = /* setup something from config */; + + /* Make a socket through which to communicate. */ + sock = socket(AF_INET, SOCK_DGRAM, 0); + if(sock == -1) return MPS_RES_IO; + + /* Set socket to non-blocking mode. */ + r = fcntl(sock, F_SETFL, O_NDELAY); + if(r == -1) return MPS_RES_IO; + + /* Bind the socket to some UDP port so that we can receive messages. */ + r = bind(sock, (struct sockaddr *)&state.mine, sizeof(state.mine)); + if(r == -1) return MPS_RES_IO; + + state.sock = sock; + + inited = 1; + + *mps_io_o = &state; + return MPS_RES_OK; + } + + + void mps_io_destroy(mps_io_t mps_io) + { + assert(mps_io == &state); + assert(inited); + + (void)close(state.sock); + + inited = 0; + } + + + mps_res_t mps_io_send(mps_io_t mps_io, mps_type_t type, + void *message, size_t size) + { + struct sockaddr *toaddr; + + assert(mps_io == &state); + assert(inited); + + switch(type) { + MPS_IO_TYPE_TELEMETRY: + toaddr = (struct sockaddr *)&state.telemetry; + break; + + MPS_IO_TYPE_DEBUGGING: + toaddr = (struct sockaddr *)&state.debugging; + break; + + default: + assert(0); + return MPS_RES_UNIMPL; + } + + (void)sendto(state.sock, message, size, 0, toaddr, sizeof(*toaddr)); + + return MPS_RES_OK; + } + + + mps_res_t mps_io_receive(mps_io_t mps_io, + void **message_o, size_t **size_o) + { + int r; + static char buffer[MPS_IO_MESSAGE_MAX]; + + assert(mps_io == &state); + assert(inited); + + r = recvfrom(state.sock, buffer, sizeof(buffer), 0, NULL, NULL); + if(r == -1) + switch(errno) { + /* Ignore interrupted system calls, and failures due to lack */ + /* of resources (they might go away.) */ + case EINTR: case ENOMEM: case ENOSR: + r = 0; + break; + + default: + return MPS_RES_IO; + } + + *message_o = buffer; + *size_o = r; + return MPS_RES_OK; + } + + +Attachments +----------- + +"O Architecture Diagram" +"O Configuration Diagrams" + + diff --git a/mps/manual/html/_sources/design/keyword-arguments.txt b/mps/manual/html/_sources/design/keyword-arguments.txt index eb21b41d92a..179ba64fde9 100644 --- a/mps/manual/html/_sources/design/keyword-arguments.txt +++ b/mps/manual/html/_sources/design/keyword-arguments.txt @@ -1,6 +1,148 @@ +.. _design-keyword-arguments: + + .. index:: pair: keyword arguments; design -.. _design-keyword-arguments: -.. include:: ../../converted/keyword-arguments.rst +Keyword arguments in the MPS +============================ + + + +Introduction +------------ +Up to version 1.111, the `Memory Pool System +`_ used varags to pass arguments +to arena and pool classes, because the general MPS interface can't +specify what arguments those classes might need in C prototypes. This +mechanism was error-prone and did not allow for any optional arguments, +meaning that the client had to specify or predict esoteric tuning +parameters. + +Starting with version 1.112, the MPS uses an idiom for keyword arguments. + + +Overview +-------- +The basic design is not specific to the MPS. The keyword argument list is +passed as an array of argument structures which look like this:: + + typedef struct mps_key_s *mps_key_t; + typedef struct mps_arg_s { + mps_key_t key; + union { + int i; + char c; + void *p; + size_t size; + /* etc. */ + } val; + } mps_arg_s; + +The argument list is assembled and passed like this:: + + mps_arg_s args[3]; + args[0].key = MPS_KEY_MIN_SIZE; + args[0].val.size = 32; + args[1].key = MPS_KEY_MAX_SIZE; + args[1].val.size = 1024; + args[2].key = MPS_KEY_ARGS_END; + mps_pool_create_k(&pool, some_pool_class(), args); + +This can be written quite concisely in C99:: + + mps_pool_create_k(&pool, some_pool_class(), + (mps_arg_s []){{MPS_KEY_MIN_SIZE, {.size = 32}}, + {MPS_KEY_MAX_SIZE, {.size = 1024}}, + {MPS_KEY_ARGS_END}}); + +The arguments that are recognised and used by the function are removed +from the array (and the subsequent arguments moved up) so that if they +are all consumed the array has :c:macro:`MPS_KEY_ARGS_END` in slot zero on +return. This can be checked by the caller. + +- It's not a static error to pass excess arguments. This makes it easy to + substitute one pool or arena class for another (which might ignore some + arguments). The caller can check that ``args[0].key`` is + :c:macro:`MPS_KEY_ARGS_END` if desired. + +- NULL is not a valid argument list. This is in line with general MPS + design principles to avoid accidental omissions. For convenience, we + provide ``mps_args_none`` as a static empty argument list. + +- NULL is not a valid argument key. This is in line with general MPS + design principles to avoid accidental omissions. Every key points to + a structure with a signature that can be checked. This makes it virtually + impossible to get an argument list with bad keys or that is unterminated + past MPS checking. + + +Internals +--------- +Internally, keys are static constant structures which are signed and contain +a checking method for the argument, like this:: + + typedef struct mps_arg_s *Arg; + typedef struct mps_key_s { + Sig sig; /* Always KeySig */ + const char *name; + Bool check(Arg arg); + } KeyStruct; + +They are mostly declared in the modules that consume them, except for a few +common keys. Declarations look like:: + + const KeyStruct _mps_key_extend_by = {KeySig, "extend_by", ArgCheckSize}; + +but ``arg.h`` provides a macro for this:: + + ARG_DEFINE_KEY(extend_by, Size); + +We define keys as static structures (rather than, say, an enum) because: + +- The set of keys can be extended indefinitely. +- The set of keys can be extended by indepdently linked modules. +- The structure contents allow strong checking of argument lists. + +In the MPS Interface, we declare keys like this:: + + extern const struct mps_key_s _mps_key_extend_by; + #define MPS_KEY_EXTEND_BY (&_mps_key_extend_by) + +The underscore on the symbol requests that client code doesn't reference +it, but instead uses the macro. This gives us adaptability to change the +design and replace keys with, say, magic numbers. + + +The varargs legacy +------------------ +For backward compatibility, varargs to arena and pool creation are +converted into keyword arguments by position, using a method in the +arena or pool class. For example:: + + static void MVVarargs(ArgStruct args[], va_list varargs) + { + args[0].key = MPS_KEY_EXTEND_BY; + args[0].val.size = va_arg(varargs, Size); + args[1].key = MPS_KEY_MEAN_SIZE; + args[1].val.size = va_arg(varargs, Size); + args[2].key = MPS_KEY_MAX_SIZE; + args[2].val.size = va_arg(varargs, Size); + args[3].key = MPS_KEY_ARGS_END; + AVER(ArgListCheck(args)); + } + +This leaves the main body of code, and any future code, free to just +handle keyword arguments only. + +The use of varargs is deprecated in the manual and the interface and these +methods can be deleted at some point in the future. + + +References +---------- + +.. [RB_2012-05-24] Richard Brooksby. Ravenbrook Limited. 2012-05-24. "`Keyword and optional arguments `__". + + diff --git a/mps/manual/html/_sources/design/lib.txt b/mps/manual/html/_sources/design/lib.txt new file mode 100644 index 00000000000..e176f8f6995 --- /dev/null +++ b/mps/manual/html/_sources/design/lib.txt @@ -0,0 +1,102 @@ +.. _design-lib: + + +.. index:: + pair: library interface; design + + +Library interface +================= + +.. mps:prefix:: design.mps.lib + + +Introduction +------------ + +:mps:tag:`intro` This document is the design of the MPS Library Interface, a +part of the plinth. + +:mps:tag:`readership` Any MPS developer. Any clients that are prepared to +read this in order to get documentation. + + +Goals +----- + +:mps:tag:`goal` The goals of the MPS library interface are: + +:mps:tag:`goal.host` To control the dependency of the MPS on the hosted ISO +C library so that the core MPS remains freestanding (see +design.mps.exec-env). + +:mps:tag:`goal.free` To allow the core MPS convenient access to ISO C +functionality that is provided on freestanding platforms (see +design.mps.exec-env.std.com.free). + + +Description +----------- + +Overview +........ + +:mps:tag:`overview.access` The core MPS needs to access functionality that +could be provided by an ISO C hosted environment. + +:mps:tag:`overview.hosted` The core MPS must not make direct use of any +facilities in the hosted environment (design.mps.exec-env). However, +it is sensible to make use of them when the MPS is deployed in a +hosted environment. + +:mps:tag:`overview.hosted.indirect` The core MPS does not make any direct +use of hosted ISO C library facilities. Instead, it indirects through +the MPS Library Interface, impl.h.mpslib. + +:mps:tag:`overview.free` The core MPS can make direct use of freestanding +ISO C library facilities and does not need to include any of the +header files ````, ````, and ```` +directly. + +:mps:tag:`overview.complete` The MPS Library Interface can be considered as +the complete "interface to ISO" (in that it provides direct access to +facilities that we get in a freestanding environment and equivalents +of any functionality we require from the hosted environment). + +:mps:tag:`overview.provision.client` In a freestanding environment the +client is expected to provide functions meeting this interface to the +MPS. + +:mps:tag:`overview.provision.hosted` In a hosted environment, +impl.c.mpsliban may be used. It just maps impl.h.mpslib directly onto +the ISO C library equivalents. + +[missing diagram] + + +Outside the interface +..................... + +We provide impl.c.mpsliban to the client, for two reasons: + +1. the client can use it to connect the MPS to the ISO C library if it + exists; + +2. as an example implementation of the MPS Library Interface. + + +Implementation +-------------- + +:mps:tag:`impl` The MPS Library Interface comprises a header file +impl.h.mpslib and some documentation. + +:mps:tag:`impl.decl` The header file defines the interface to definitions +which parallel those parts of the non-freestanding ISO headers which +are used by the MPS. + +:mps:tag:`impl.include` The header file also includes the freestanding +headers ````, ````, and ```` (and not +````, though perhaps it should). + + diff --git a/mps/manual/html/_sources/design/lock.txt b/mps/manual/html/_sources/design/lock.txt index ceb782a14c1..d89df3d7788 100644 --- a/mps/manual/html/_sources/design/lock.txt +++ b/mps/manual/html/_sources/design/lock.txt @@ -1,6 +1,184 @@ +.. _design-lock: + + .. index:: pair: locking; design -.. _design-lock: -.. include:: ../../converted/lock.rst +The lock module +=============== + +.. mps:prefix:: design.mps.lock + + +Purpose +------- + +:mps:tag:`purpose` Support the locking needs of the thread-safe design. In +particular: + +- recursive locks; +- binary locks; +- recursive "global" lock that need not be allocated or initialized by + the client; +- binary "global" lock that need not be allocated or initialized by + the client. + +:mps:tag:`context` The MPS has to be able to operate in a multi-threaded +environment. The thread-safe design (design.mps.thread-safety) +requires client-allocatable binary locks, a global binary lock and a +global recursive lock. An interface to client-allocatable recursive +locks is also present to support any potential use, because of +historic requirements, and because the implementation will presumably +be necessary anyway for the global recursive lock. + + +Background +---------- + +:mps:tag:`need` In an environment where multiple threads are accessing +shared data. The threads which access data which is shared with other +threads need to cooperate with those threads to maintain consistency. +Locks provide a simple mechanism for doing this. + +:mps:tag:`ownership` A lock is an object which may be "owned" by a single +thread at a time. By claiming ownership of a lock before executing +some piece of code a thread can guarantee that no other thread owns +the lock during execution of that code. If some other thread holds a +claim on a lock, the thread trying to claim the lock will suspend +until the lock is released by the owning thread. + +:mps:tag:`data` A simple way of using this behaviour is to associate a lock +with a shared data structure. By claiming that lock around accesses to +the data, a consistent view of the structure can be seen by the +accessing thread. More generally any set of operations which are +required to be mutually exclusive may be performed so by using locks. + + +Overview +-------- + +:mps:tag:`adt` There is an abstract datatype :c:type:`Lock` which points to a +locking structure :c:type:`LockStruct`. This structure is opaque to any +client, although an interface is provided to supply the size of the +structure for any client wishing to make a new lock. The lock is not +allocated by the module as allocation itself may require locking. +:c:type:`LockStruct` is implementation specific. + +:mps:tag:`simple-lock` There are facilities for claiming and releasing +locks. :c:type:`Lock` is used for both binary and recursive locking. + +:mps:tag:`global-locks` "Global" locks are so called because they are used +to protect data in a global location (such as a global variable). The +lock module provides two global locks; one recursive and one binary. +There are facilities for claiming and releasing both of these locks. +These global locks have the advantage that they need not be allocated +or atomically initialized by the client, so they may be used for +locking the initialization of the allocator itself. The binary global +lock is intended to protect mutable data, possibly in conjunction with +other local locking strategies. The recursive global lock is intended +to protect static read-only data during one-off initialization. See +design.mps.thread-safety. + +:mps:tag:`deadlock` This module does not provide any deadlock protection. +Clients are responsible for avoiding deadlock by using traditional +strategies such as ordering of locks. (See +design.mps.thread-safety.deadlock.) + +:mps:tag:`single-thread` In the single-threaded configuration, locks are not +needed and the claim/release interfaces defined to be no-ops. + + +Detailed design +--------------- + +:mps:tag:`interface` The interface comprises the following functions: + +.. c:function:: size_t LockSize(void) + +Return the size of a :c:type:`LockStruct` for allocation purposes. + +.. c:function:: void LockInit(Lock lock) + +After initialisation the lock is not owned by any thread. + +.. c:function:: void LockFinish(Lock lock) + +Before finalisation the lock must not beowned by any thread. + +.. c:function:: void LockClaim(Lock lock) + +Claims ownership of a lock that was previously not held by current +thread. + +.. c:function:: void LockReleaseMPM(Lock lock) + +Releases ownership of a lock that is currently owned. + +.. c:function:: void LockClaimRecursive(Lock lock) + +Remembers the previous state of the lock with respect to the current +thread and claims the lock (if not already held). + +.. c:function:: void LockReleaseRecursive(Lock lock) + +Testores the previous state of the lock stored by corresponding +:c:func:`LockClaimRecursive()` call. + +.. c:function:: void LockClaimGlobal(void) + +Claims ownership of the binary global lock which was previously not +held by current thread. + +.. c:function:: void LockReleaseGlobal(void) + +Releases ownership of the binary global lock that is currently owned. + +.. c:function:: void LockClaimGlobalRecursive(void) + +Remembers the previous state of the recursive global lock with respect +to the current thread and claims the lock (if not already held). + +.. c:function:: void LockReleaseGlobalRecursive(void) + +Restores the previous state of the recursive global lock stored by +corresponding :c:func:`LockClaimGlobalRecursive()` call. + +:mps:tag:`impl.recursive` For recursive claims, the list of previous states +can be simply implemented by keeping a count of the number of claims +made by the current thread so far. In multi-threaded implementation +below this is handled by the operating system. A count is still kept +and used to check correctness. + +:mps:tag:`impl.global` The binary and recursive global locks may actually be +implemented using the same mechanism as normal locks. + +:mps:tag:`impl.ansi` Single-Threaded Generic Implementation: + +- single-thread; +- no need for locking; +- locking structure contains count; +- provides checking in debug version; +- otherwise does nothing except keep count of claims. + +:mps:tag:`impl.win32` Win32 Implementation: + +- supports Win32's threads; +- uses Critical Sections [ref?]; +- locking structure contains a Critical Section; +- both recursive and non-recursive calls use same Windows function; +- also performs checking. + +:mps:tag:`impl.linux` LinuxThreads Implementation (possibly suitable for all +PThreads implementations): + +- supports LinuxThreads threads, which are an implementation of + PThreads (see ``_); +- locking structure contains a mutex, initialized to check for + recursive locking; +- locking structure contains a count of the number of active claims; +- non-recursive locking calls :c:func:`pthread_mutex_lock()` and expects success; +- recursive locking calls :c:func:`pthread_mutex_lock()` and expects either + success or :c:macro:`EDEADLK` (indicating a recursive claim); +- also performs checking. + diff --git a/mps/manual/html/_sources/design/locus.txt b/mps/manual/html/_sources/design/locus.txt new file mode 100644 index 00000000000..3525778a872 --- /dev/null +++ b/mps/manual/html/_sources/design/locus.txt @@ -0,0 +1,669 @@ +.. _design-locus: + + +.. index:: + pair: locus manager; design + + +MPS Configuration +================= + +.. mps:prefix:: design.mps.locus + + +Introduction +------------ + +:mps:tag:`intro` The locus manager coordinates between the pools and takes +the burden of having to be clever about tract/group placement away +from the pools, preserving trace differentiability and contiguity +where appropriate. + +:mps:tag:`source` mail.gavinm.1998-02-05.17-52(0), mail.ptw.1998-02-05.19-53(0), +mail.pekka.1998-02-09.13-58(0), and mail.gavinm.1998-02-09.14-05(0). + +:mps:tag:`readership` Any MPS developer. + + +Overview +-------- + +The MPS manages three main resources: + +1. storage; +2. address space; +3. time. + +The locus manager manages address space at the arena level. + +.. note: + + Tucker was right: see mail.ptw.1998-11-02.14-25. Richard Kistruck, + 2007-04-24. + +When a pool wants some address space, it expresses some preferences to +the locus manager. The locus manager and the arena (working together) +try to honour these preferences, and decide what address space the +pool gets. + +Preferences are expressed by the ``SegPref`` argument to +:c:func:`SegAlloc()`. Note that, when they call :c:func:`SegAlloc()`, pools are +asking for address space and writeable storage simultaneously, in a +single call. There is currently no way for pools to reserve address +space without requesting storage. + + +Why is it important to manage address space? +............................................ + +1. Trace differentiability + + Carefully chosen addresses are used by reference tracing systems + (ie. automatic pools), to categorise objects into clumps; and to + summarise and cheaply find references between clumps. + + Different clumps will become worth collecting at different times + (the classic example, of course, is generations in a generational + collector). For these partial collections to be efficient, it must + be cheap to keep these clumps differentiable, cheap to condemn + (Whiten) a particular clump, and cheap to find a good conservative + approximation to all inward references to a clump (both initially + to construct the Grey set, and to make scanning the Grey set + efficient). + + This is what the MPS zone mechanism is all about. + + The locus manager manages the mapping from clumps to zones. + + To specify a clump, pools use the ``SegPrefGen`` argument to + :c:func:`SegPrefExpress()`. + + .. note:: + + The name is misleading: generations are only one sort of clump. + Richard Kistruck, 2007-04-24. + +2. Prevent address space fragmentation (within the arena) + + Address space is not infinite. + + In some use cases, the MPS is required to remain efficient when + using very nearly all available address space and storage. For + example, with the client-arena class, where the only address space + available is that of the storage available. + + Even with the VM arena class, typical storage sizes (as of 2007) + can make 32-bit address space constrained: the client may need + several gigabytes, which leaves little spare address space. + + Address space fragmentation incurs failure when there is no way to + allocate a big block of address space. The big block may be + requested via the MPS (by the client), or by something else in the + same process, such as a third-party graphics library, image + library, etc. + + Address space fragmentation incurs cost when: + + - desired large-block requests (such as for buffering) are denied, + causing them to be re-requested as a smaller block, or as several + smaller blocks; + + - possible operating-system costs in maintaining a fragmented + mapping? + +3. Prevent storage fragmentation (within tracts and segments) + + Storage is not infinite: it is allocated in multiples of a + fixed-size tract. Small lonely objects, each retaining a whole + tract, cause storage fragmentation. + + Non-moving pools manage this fragmentation with placement + strategies that use: + + - co-located death (in space and time); + - segment merging and splitting. + + These pool-level strategies always care about contiguity of object + storage. They also often care about the *ordering* of addresses, + because pool code uses an address-ordered search when choosing + where to place a new object. For these two reasons, the address + chosen (by the locus manager and arena) for new tracts is + important. + + Certain specialised pools, and/or some client programs that use + them, have carefully tuned segment sizes, positioning, and search + order. Be careful: seemingly inconsequential changes can + catastrophically break this tuning. + + Pools can specify a preference for High and Low ends of address + space, which implies a search-order. Pools could also specify + clumping, using either ``SegPrefGen`` or ``SegPrefZoneSet``. + + +Discovering the layout +...................... + +The locus manager is not given advance notice of how much address +space will be required with what preferences. Instead, the locus +manager starts with an empty layout, and adapts it as more requests +come in over time. It is attempting to discover a suitable layout by +successive refinement. This is ambitious. + + +Definitions +----------- + +:mps:tag:`note.cohort` We use the word "cohort" in its usual sense here, but +we're particularly interested in cohorts that have properties relevant +to tract placement. It is such cohorts that the pools will try to +organize using the services of the locus manager. Typical properties +would be trace differentiability or (en masse) death-time +predictability. Typical cohorts would be instances of a +non-generational pool, or generations of a collection strategy. + +:mps:tag:`def.trace.differentiability` Objects (and hence tracts) that are +collected, may or may not have "trace differentiability" from each +other, depending on their placement in the different zones. Objects +(or pointers to them) can also have trace differentiability (or not) +from non-pointers in ambiguous references; in practice, we will be +worried about low integers, that may appear to be in zones 0 or -1. + + +Requirements +------------ + +:mps:tag:`req.cohort` Tract allocations must specify the cohort they +allocate in. These kind of cohorts will be called loci, and they will +have such attributes as are implied by the other requirements. +Critical. + +:mps:tag:`req.counter.objects` As a counter-requirement, pools are expected +to manage objects. Objects the size of a tract allocation request +(segment-sized) are exceptional. Critical. +:mps:tag:`req.counter.objects.just` This means the locus manager is not +meant to solve the problems of allocating large objects, and it isn't +required to know what goes on in pools. + +:mps:tag:`req.contiguity` Must support a high level of contiguity within +cohorts when requested. This means minimizing the number of times a +cohort is made aware of discontiguity. Essential (as we've effectively +renegotiated this in SW, down to a vague hope that certain critical +cohorts are not too badly fragmented). :mps:tag:`req.contiguity.just` TSBA. + +:mps:tag:`req.contiguity.specific` It should be possible to request another +allocation next to a specific tract on either side (or an extension in +that direction, as the case may be). Such a request can fail, if +there's no space there. Nice. It would also be nice to have one for +"next to the largest free block". + +:mps:tag:`req.differentiable` Must support the trace differentiability of +segments that may be condemned separately. Due to the limited number +of zones, it must be possible to place several cohorts into the same +zone. Essential. + +:mps:tag:`req.differentiable.integer` It must be possible to place +collectable allocations so that they are trace-differentiable from +small integers. Essential. + +:mps:tag:`req.disjoint` Must support the disjointness of pages that have +different VM properties (such as mutable/immutable, +read-only/read-write, and different lifetimes). Optional. + +.. note:: + + I expect the implementation will simply work at page or larger + granularity, so the problem will not arise, but Tucker insisted on + stating this as a requirement. Pekka P. Pirinen, 1998-10-28. + +:mps:tag:`req.low-memory` The architecture of the locus manager must not +prevent the design of efficient applications that often use all +available memory. Critical. :mps:tag:`req.low-memory.expl` This basically +says it must be designed to perform well in low-memory conditions, but +that there can be configurations where it doesn't do as well, as long +as this is documented for the application programmer. Note that it +doesn't say all applications are efficient, only that if you manage to +design an otherwise efficient application, the locus manager will not +sink it. + +:mps:tag:`req.address` Must conserve address space in VM arenas to a +reasonable extent. Critical. + +:mps:tag:`req.inter-pool` Must support the association of sets of tracts in +different pools into one cohort. Nice. + +:mps:tag:`req.ep-style` Must support the existing EP-style of allocation +whereby allocation is from one end of address space either upwards or +downwards (or a close approximation thereto with the same behavior). +:mps:tag:`req.ep-style.just` We cannot risk disrupting a policy with +well-known properties when this technology is introduced. + +:mps:tag:`req.attributes` There should be a way to inform the locus manager +about various attributes of cohorts that might be useful for +placement: deathtime, expected total size, and so on. Optional. It's a +given that the cohorts must then have these attributes, within the +limits set in the contract of the appropriate interface. +:mps:tag:`req.attributes.action` The locus manager should use the attributes +to guide its placement decisions. Nice. + +:mps:tag:`req.blacklisting` There should be a way of maintaining at least +one blacklist for pages (or some other small unit), that can +not/should not be allocated to collectable pools. Optional. + +.. note:: + + How to do blacklist breaking for ambiguous refs? + +:mps:tag:`req.hysteresis` There should be a way to indicate which cohorts +fluctuate in size and by how much, to guide the arena hysteresis to +hold on to suitable pages. Optional. + + +Analysis +-------- + +:mps:tag:`anal.sw` Almost any placement policy would be an improvement on +the current SW one. + +:mps:tag:`anal.cause-and-effect` The locus manager doesn't usually need to +know *why* things need to be differentiable, disjoint, contiguous, and +so on. Abstracting the reason away from the interface makes it more +generic, more likely to have serendipitous new uses. Attributes +described by a quantity (deathtime, size, etc.) are an exception to +this, because we can't devise a common measure. + +:mps:tag:`anal.stable` The strategy must be stable: it must avoid repeated +recomputation, especially the kind that switches between alternatives +with a short period (repeated "bites" out the same region or +flip-flopping between two regions). + +:mps:tag:`anal.fragmentation` There's some call to avoid fragmentation in +cohorts that don't need strict contiguity, but this is not a separate +requirement, since fragmentation is a global condition, and can only +be ameliorated if there's a global strategy that clumps allocations +together. + +:mps:tag:`anal.deathtime` Cohorts with good death-time clumping of their +objects could use some locality of tract allocation, because it +increases the chances of creating large holes in the address space +(for other allocation to use). OTOH. many cohorts will not do multiple +frees in short succession, or at least cannot reasonably be predicted +to do so. This locality is not contiguity, nor is it low +fragmentation, it's just the requirement to place the new tracts next +to the tract where the last object was allocated in the cohort. Note +that the placement of objects is under the control of the pool, and +the locus manager will not know it, therefore this requirement should +be pursued by requesting allocation next to a particular tract (which +we already have a requirement for). + +:mps:tag:`anal.asymmetrical` The strategy has to be asymmetrical with +respect to cohorts growing and shrinking. The reason of this asymmetry +is that it can choose where to grow, but it cannot choose where to +shrink (except in a small way by growing with good locality). + + +Interface +--------- + +:mps:tag:`interface.locus` A cohort will typically reside on multiple tracts +(and the pools will avoid putting objects of other cohorts on them), +so there should be an interface to describe the properties of the +cohort, and associate each allocation request with the cohort. We +shall call such an object, created to represent a cohort, a locus (pl. +loci). + +:mps:tag:`interface.locus.pool` Loci will usually be created by the pool +that uses it. Some of the locus attributes will be inherited from +client-specified pool attributes [this means there will be additional +pool attributes]. + +:mps:tag:`interface.detail` This describes interface in overview; for +details, see implementation section and code, or user doc. + + +Loci +.... + +.. c:function:: Res LocusCreate(Locus *locusReturn, LocusAttrs attrs, ZoneGroup zg, LocusAllocDesc adesc) + +:mps:tag:`function.create` A function to create a locus: ``adesc`` contains +the information about the allocation sequences in the locus, ``zg`` is +used for zone differentiability, and ``attrs`` encodes the following: + +- :mps:tag:`locus.contiguity` A locus can be contiguous. This means + performing as required in :mps:ref:`.req.contiguity`, non-contiguous + allocations can be freely placed anywhere (but efficiency dictates + that similar allocations are placed close together and apart from + others). + +- :mps:tag:`locus.blacklist` Allocations in the locus will avoid blacklisted + pages (for collectable segments). + +- :mps:tag:`locus.zero` Allocations in the locus are zero-filled. + +.. note:: + + Other attributes will be added, I'm sure. + +:mps:tag:`interface.zone-group` The locus can be made a member of a zone +group. Passing ``ZoneGroupNONE`` means it's not a member of any group +(allocations will be placed without regard to zone, except to keep +them out of stripes likely to be needed for some group). + +.. note:: + + I propose no mechanism for managing zone groups at this time, + since it's only used internally for one purpose. Pekka P. Pirinen, + 2000-01-17. + +:mps:tag:`interface.size` An allocation descriptor (``LocusAllocDesc``) +contains various descriptions of how the locus will develop over time +(inconsistent specifications are forbidden, of course): + +- :mps:tag:`interface.size.typical-alloc` Size of a typical allocation in + this locus, in bytes. This will mainly affect the grouping of + non-contiguous loci. + +- :mps:tag:`interface.size.large-alloc` Typical large allocation that the + manager should try to allow for (this allows some relief from + :mps:ref:`.req.counter.objects`), in bytes. This will mainly affect the size + of gaps that will be allotted adjoining this locus. + +- :mps:tag:`interface.size.direction` Direction of growth: up/down/none. + Only useful if the locus is contiguous. + +- :mps:tag:`interface.size.lifetime` Some measure of the lifetime of tracts + (not objects) in the cohort. + + .. note:: + + Don't know the details yet, probably only useful for placing + similar cohorts next to each other, so the details don't + actually matter. Pekka P. Pirinen, 2000-01-17. + +- :mps:tag:`interface.size.deathtime` Some measure of the deathtime of + tracts (not objects) in the cohort. + + .. note:: + + Ditto. Pekka P. Pirinen, 2000-01-17. + +:mps:tag:`function.init` :c:func:`LocusInit()` is like :c:func:`LocusCreate()`, but +without the allocation. This is the usual interface, since most loci +are embedded in a pool or something. + +:mps:tag:`function.alloc` :c:func:`ArenaAlloc()` to take a locus argument. +:c:func:`ArenaAllocHere()` is like it, plus it takes a tract and a +specification to place the new allocation immediately above/below a +given tract; if that is not possible, it returns ``ResFAIL`` (this +will make it useful for reallocation functionality). + +.. c:function:: ArenaSetTotalLoci(Arena arena, Size nLoci, Size nZoneGroups) + +:mps:tag:`function.set-total` A function to tell the arena the expected +number of (non-miscible client) loci, and of zone groups. + + +Peaks +..... + +.. c:function:: mps_res_t mps_peak_create(mps_peak_t*, mps_arena_t) + +:mps:tag:`function.peak.create` A function to create a peak. A newly-created +peak is open, and will not be used to guide the strategy of the locus +manager. + +.. c:function:: mps_res_t mps_peak_describe_pool(mps_peak_t, mps_pool_t, mps_size_desc_t) + +:mps:tag:`function.peak.add` A function to add a description of the state of +one pool into the peak. Calling this function again for the same peak and pool instance will replace +the earlier description. + +:mps:tag:`function.peak.add.size` The size descriptor contains a total size +in bytes or percent of arena size. + +.. note:: + + Is this right? Pekka P. Pirinen, 2000-01-17. + +:mps:tag:`function.peak.add.remove` Specifying a :c:macro:`NULL` size will remove +the pool from the peak. The client is not allowed to destroy a pool +that is mentioned in any peak; it must be first removed from the peak, +or the peak must be destroyed. This is to ensure that the client +adjusts the peaks in a manner that makes sense to the application; the +locus manager can't know how to do that. + +.. c:function:: mps_res_t mps_peak_close(mps_peak_t) + +:mps:tag:`function.peak.close` A function to indicate that all the +significant pools have been added to the peak, and it can now be used +to guide the locus manager. For any pool not described in the peak, +the locus manager will take its current size at any given moment as +the best prediction of its size at the peak. + +:mps:tag:`function.peak.close.after` It is legal to add more descriptions to +the peak after closing, but this will reopen the peak, and it will +have to be closed before the locus manager will use it again. The +locus manager uses the previous closed state of the peak, while this +is going on. + +.. c:function:: void mps_peak_destroy(mps_peak_t) + +:mps:tag:`function.peak.destroy` A function to destroy a peak. + +:mps:tag:`interface.ep-style` This satisfies :mps:ref:`.req.ep-style` by allowing SW +to specify zero size for most pools (which will cause them to be place +next to other loci with the same growth direction). + +.. note:: + + Not sure this is good enough, but we'll try it first. Pekka P. + Pirinen, 2000-01-17. + + +Architecture +------------ + +Data objects +............ + +:mps:tag:`arch.locus` To represent the cohorts, we have locus objects. +Usually a locus is embedded in a pool instance, but generations are +separate loci. + +:mps:tag:`arch.locus.attr` contiguity, blacklist, zg, current region, @@@@ + +:mps:tag:`arch.locus.attr.exceptional` The client can define a typical large +allocation for the locus. Requests substantially larger than that are +deemed exceptional. + +:mps:tag:`arch.zone-group` To satisfy :mps:ref:`.req.condemn`, we offer zone groups. +Each locus can be a member of a zone group, and the locus manager will +attempt to place allocations in this locus in different zones from all +the other zone groups. A zone-group is represented as @@@@. + +:mps:tag:`arch.page-table` A page table is maintained by the arena, as usual +to track association between tracts, pools and segments, and mapping +status for VM arenas. + +:mps:tag:`arch.region` All of the address space is divided into disjoint +regions, represented by region objects. These objects store their +current limits, and high and low watermarks of currently allocated +tracts (we hope there's usually a gap of empty space between regions). +The limits are actually quite porous and flexible. + +:mps:tag:`arch.region.assoc` Each region is associated with one contiguous +locus or any number of non-contiguous loci (or none). We call the +first kind of region "contiguous". :mps:tag:`arch.locus.assoc` Each locus +remembers all regions where it has tracts currently, excepting the +badly-placed allocations (see below). It is not our intention that any +locus would have very many, or that loci that share regions would have +any reason to stop doing do. + +:mps:tag:`arch.region.more` Various quantities used by the placement +computation are also stored in the regions and the loci. Regions are +created (and destroyed) by the placement recomputation. Regions are +located in stripes (if it's a zoned region), but they can extend into +neighboring stripes if an exceptionally large tract allocation is +requested (to allow for large objects). + +:mps:tag:`arch.chunk` Arenas may allocate more address space in additional +chunks, which may be disjoint from the existing chunks. Inter-chunk +space will be represented by dummy regions. There are also sentinel +regions at both ends of the address space. + + +Overview of strategy +.................... + +:mps:tag:`arch.strategy.delay` The general strategy is to delay placement +decisions until they have to be made, but no later. + +:mps:tag:`arch.strategy.delay.until` Hence, the locus manager only makes +placement decisions when an allocation is requested (frees and other +operations might set a flag to cause the next allocation to redecide). +This also allows the client to change the peak and pool configuration +in complicated ways without causing a lot of recomputation, by doing +all the changes without allocating in the middle (unless the control +pool needs more space because of the changes). + +:mps:tag:`arch.strategy.normal` While we want the placement to be +sophisticated, we do not believe it is worth the effort to consider +all the data at each allocation. Hence, allocations are usually just +placed in one of the regions used previously (see :mps:ref:`.arch.alloc`) +without reconsidering the issues. + +:mps:tag:`arch.strategy.normal.limit` However, the manager sets +precautionary limits on the regions to ensure that the placement +decisions are revisited when an irrevocable placement is about to be +made. + +:mps:tag:`arch.strategy.create` The manager doesn't create new regions until +they are needed for allocation (but it might compute where they could +be placed to accommodate a peak). + + +Allocation +.......... + +:mps:tag:`arch.alloc` Normally, each allocation to a locus is placed in its +current region. New regions are only sought when necessary to fulfill +an allocation request or when there is reason to think the situation +has changed significantly (see :mps:ref:`.arch.significant`). + +:mps:tag:`arch.alloc.same` An allocation is first attempted next to the +previous allocation in the same locus, respecting growth direction. If +that is not possible, a good place in the current region is sought. +:mps:tag:`arch.alloc.same.hole` At the moment, for finding a good place +within a region, we just use the current algorithm, limited to the +region. In future, the placement within regions will be more clever. + +:mps:tag:`arch.alloc.extend` If there's no adequate hole in the current +region and the request is not exceptional, the neighboring regions are +examined to see if the region could be extended at one border. (This +will basically only be done if the neighbor has shrunk since the last +placement recomputation, because the limit was set on sophisticated +criteria, and should not be changed without justification.) +:mps:tag:`arch.alloc.extend.here` When an allocation is requested next to a +specific tract (:c:func:`ArenaAllocHere()`), we try to extend a little +harder (at least for ``change_size``, perhaps not for locality). + +:mps:tag:`arch.alloc.other` If no way can be found to allocate in the +current region, other regions used for this locus are considered in +the same way, to see if space can be found there. [Or probably look at +other regions before trying to extend anything?] + +:mps:tag:`arch.alloc.recompute` When no region of this locus has enough +space for the request, or when otherwise required, region placement is +recomputed to find a new region for the request (which might be the +same region, after extension). + +:mps:tag:`arch.alloc.current` This region where the allocation was placed +then becomes the current region for this locus, except when the +request was exceptional, or when the region chosen was "bad" (see +@@@@). + +:mps:tag:`arch.significant` Significant changes to the parameters affecting +placement are deemed to have happened at certain client calls and when +the total allocation has changed substantially since the last +recomputation. Such conditions set a flag that causes the next +allocation to recompute even if its current region is not full +(possibly second-guess the decision to recompute after some +investigation of the current state?). + + +Deallocation +............ + +:mps:tag:`arch.free` Deallocation simply updates the counters in the region +and the locus. For some loci, it will make the region of the +deallocation the current region. :mps:tag:`arch.free.remove` If a region +becomes entirely empty, it is deleted (and the neighbors limits might +be adjusted). + +.. note:: + + This is quite tricky to get right. + + +Region placement recomputation +.............................. + +:mps:tag:`arch.gap` When doing placement computations, we view the arena as +a sequence of alternating region cores and gaps (which can be small, +even zero-sized). Initially, we'll take the core of a region to be the +area between the high and low watermark, but in the future we might be +more flexible about that. + +.. note:: + + Edge determination is actually a worthwhile direction to explore. + +:mps:tag:`arch.reach` The gap between two cores could potentially end up +being allocated to either region, if they grow in that direction, or +one or neither, if they don't. The set of states that the region +assignment could reach by assigning the gaps to their neighbors is +called the reach of the current configuration. + +:mps:tag:`arch.placement.object` The object of the recomputation is to find +a configuration of regions that is not too far from the current +configuration and that keeps all the peaks inside its reach; if that +is not possible, keep the nearest ones in the reach and then minimize +the total distance from the rest. + +:mps:tag:`arch.placement.hypothetical` The configurations that are +considered will include hypothetical placements for new regions for +loci that cannot fit in their existing regions at the peak. This is +necessary to avoid choosing a bad alternative. + +:mps:tag:`arch.placement.interesting` The computation will only consider new +regions of loci that are deemed interesting, that is, far from their +peak state. This will reduce the computational burden and avoid +jittering near a peak. + +.. note:: + + Details missing. + + +Implementation +-------------- + +[missing] + + +Notes +----- + +:mps:tag:`idea.change` Even after the first segment, be prepared to change +your mind, if by the second segment a lot of new loci have been +created. + +:mps:tag:`distance` If the current state is far from a peak, there's time to +reassign regions and for free space to appear (in fact, under the +steady arena assumption, enough free space *will* appear). + +:mps:tag:`clear-pool` Need to have a function to deallocate all objects in a +pool, so that :c:func:`PoolDestroy()` won't have to be used for that +purpose. + + diff --git a/mps/manual/html/_sources/design/message-gc.txt b/mps/manual/html/_sources/design/message-gc.txt new file mode 100644 index 00000000000..e0bbead9427 --- /dev/null +++ b/mps/manual/html/_sources/design/message-gc.txt @@ -0,0 +1,292 @@ +.. _design-message-gc: + + +.. index:: + pair: garbage collection messages; design + + +GC messages +=========== + +.. mps:prefix:: design.mps.config + + +Introduction +------------ + +:mps:tag:`intro` This document describes the design of the MPS garbage +collection messages. For a guide to the MPS message system in general, +see design.mps.message. + +:mps:tag:`readership` Any MPS developer. + + +Overview +-------- + +The MPS provides two types of GC messages: + +- :c:func:`mps_message_type_gc_start()`; +- :c:func:`mps_message_type_gc()`. + +They are called "trace start" and "trace end" messages in this +document and in most MPS source code. + + +Introduction +------------ + +The MPS posts a trace start message (:c:func:`mps_message_type_gc_start()`) +near the start of every trace (but after calculating the condemned +set, so we can report how large it is). + +The MPS posts a trace end message (:c:func:`mps_message_type_gc()`) near the +end of every trace. + +These messages are extremely flexible: they can hold arbitrary +additional data simply by writing new accessor functions. If there is +more data to report at either of these two events, then there is a +good argument for adding it into these existing messages. + +.. note:: + + In previous versions of this design document, there was a partial + unimplemented design for an :c:func:`mps_message_type_gc_generation()` + message. This would not have been a good design, because managing + and collating multiple messages is much more complex for both MPS + and client than using a single message. Richard Kistruck, + 2008-12-19. + + +Purpose +------- + +:mps:tag:`purpose` The purpose of these messages is to allow the client +program to be aware of GC activity, in order to: + +- adjust its own behaviour programmatically; +- show or report GC activity in a custom way, such as an in-client + display, in a log file, etc. + +The main message content should be intelligible and helpful to +client-developers (with help from MPS staff if necessary). There may +be extra content that is only meaningful to MPS staff, to help us +diagnose client problems. + +While there is some overlap with the Diagnostic Feedback system +(design.mps.diag), the main contrasts are that these GC messages are +present in release builds, are stable from release to release, and are +designed to be parsed by the client program. + + +Names and parts +--------------- + +Here's a helpful list of the names used in the GC message system: + +Implementation is mostly in the source file ``traceanc.c`` (trace +ancillary). + +============================= ============================== ====================== +Internal name "trace start" "trace end" +Internal type ``TraceStartMessage`` ``TraceMessage`` +:c:type:`ArenaStruct` member ``tsMessage[]`` ``tMessage`` +Message type ``MessageTypeGCSTART`` ``MessageTypeGC`` +External name ``mps_message_type_gc_start`` ``mps_message_type_gc`` +============================= ============================== ====================== + +.. note:: + + The names of these messages are unconventional; they should + properly be called "gc (or trace) *begin*" and "gc (or trace) + *end*". But it's much too late to change them now. Richard + Kistruck, 2008-12-15. + +Collectively, the trace-start and trace-end messages are called the +"trace id messages", and they are managed by the functions +:c:func:`TraceIdMessagesCheck()`, :c:func:`TraceIdMessagesCreate()`, and :c:func:`TraceIdMessagesDestroy()`. + +The currently supported message-field accessor methods are: +:c:func:`mps_message_gc_start_why()`, :c:func:`mps_message_gc_live_size()`, +:c:func:`mps_message_gc_condemned_size()`, and +:c:func:`mps_message_gc_not_condemned_size()`. These are documented in the +Reference Manual. + + +Lifecycle +--------- + +:mps:tag:`lifecycle` for each trace id, pre-allocate a pair of start/end +messages by calling :c:func:`ControlAlloc()`. Then, when a trace runs using +that trace id, fill in and post these messages. As soon as the trace +has posted both messages, immediately pre-allocate a new pair of +messages, which wait in readiness for the next trace to use that +trace id. + + +Requirements +............ + +:mps:tag:`req.no-start-alloc` Should avoid attempting to allocate memory at +trace start time. :mps:tag:`req.no-start-alloc.why` There may be no free +memory at trace start time. Client would still like to hear about +collections in those circumstances. + +:mps:tag:`req.queue` Must support a client that enables, but does not +promptly retrieve, GC messages. Messages that have not yet been +retrived must remain queued, and the client must be able to retrieve +them later without loss. It is not acceptable to stop issuing GC +messages for subsequent collections merely because messages from +previous collections have not yet been retrieved. :mps:tag:`req.queue.why` +This is because there is simply no reasonable way for a client to +guarantee that it always promptly collects GC messages. + +:mps:tag:`req.match` Start and end messages should always match up: never +post one of the messages but fail to post the matching one. + +:mps:tag:`req.match.why` This makes client code much simpler -- it does not +have to handle mismatching messages. + +:mps:tag:`req.errors-not-direct` Errors (such as a :c:func:`ControlAlloc()` +failure) cannot be reported directly to the client, because +collections often happen automatically, without an explicit client +call to the MPS interface. + +:mps:tag:`req.multi-trace` Up to ``TraceLIMIT`` traces may be running, and +emitting start/end messages, simultaneously. + +:mps:tag:`req.early` Nice to tell client as much as possible about the +collection in the start message, if we can. + +:mps:tag:`req.similar` Start and end messages are conceptually similar -- it +is quite okay, and may be helpful to the client, for the same datum +(for example: the reason why the collection occurred) to be present in +both the start and end message. + + +Storage +....... + +For each trace-id (:mps:ref:`.req.multi-trace`) a pair (:mps:ref:`.req.match`) of +start/end messages is dynamically allocated (:mps:ref:`.req.queue`) in advance +(:mps:ref:`.req.no-start-alloc`). Messages are allocated in the control pool +using :c:func:`ControlAlloc()`. + +.. note:: + + Previous implementations of the trace start message used static + allocation. This does not satisfy :mps:ref:`.req.queue`. See also + job001570_. Richard Kistruck, 2008-12-15. + + .. _job001570: http://www.ravenbrook.com/project/mps/issue/job001570/ + +Poiters to these messages are stored in ``tsMessage[ti]`` and +``tMessage[ti]`` arrays in the :c:type:`ArenaStruct`. + +.. note:: + + We must not> keep the pre-allocated messages, or pointers to them, + in :c:type:`TraceStruct`: the memory for these structures is statically + allocated, but the values in them are re-initialised by + :c:func:`TraceCreate()` each time the trace id is used, so the + :c:func:`TraceStruct()` is invalid (that is: to be treated as random + uninitialised memory) when not being used by a trace. See also + job001989_. Richard Kistruck, 2008-12-15. + + .. _job001989: http://www.ravenbrook.com/project/mps/issue/job001989/ + + +Creating and Posting +.................... + +In :c:func:`ArenaCreate()` we use :c:macro:`TRACE_SET_ITER` to initialise the +``tsMessage[ti]`` and ``tMessage[ti]`` pointers to :c:macro:`NULL`, and then +(when the control pool is ready) :c:macro:`TRACE_SET_ITER` calling +:c:func:`TraceIdMessagesCreate()`. This performs the initial pre-allocation +of the trace start/end messages for each trace id. Allocation failure +is not tolerated here: it makes :c:func:`ArenaCreate()` fail with an error +code, because the arena is deemed to be unreasonably small. + +When a trace is running using trace id ``ti``, it finds a +pre-allocated message via ``tsMessage[ti]`` or ``tMessage[ti]`` in the +:c:func:`ArenaStruct()`, fills in and posts the message, and nulls-out the +pointer. (If the pointer was null, no message is sent; see below.) The +message is now reachable only from the arena message queue (but the +control pool also knows about it). + +When the trace completes, it calls :c:func:`TraceIdMessagesCreate()` for its +trace id. This performs the ongoing pre-allocation of the trace +start/end messages for the next use of this trace id. The expectation +is that, after a trace has completed, some memory will have been +reclaimed, and the :c:func:`ControlAlloc()` will succeed. + +But allocation failure here is permitted: if it happens, both the +start and the end messages are freed (if present). This means that, +for the next collection using this trace id, neither a start nor an +end message will be sent (:mps:ref:`.req.match`). There is no direct way to +report this failure to the client (:mps:ref:`.req.errors-not-direct`), so we +just increment the ``droppedMessages`` counter in the :c:type:`ArenaStruct`. +Currently this counter is never reported to the client (except in +diagnostic varieties). + + +Getting and discarding +...................... + +If the client has not enabled that message type, the message is +discarded immediately when posted, calling :c:func:`ControlFree()` and +reclaiming the memory. + +If the client has enabled but never gets the message, it remains on +the message queue until :c:func:`ArenaDestroy()`. Theoretically these +messages could accumulate forever until they exhaust memory. This is +intentional: the client should not enable a message type and then +never get it! + +Otherwise, when the client gets a message, it is dropped from the +arena message queue: now only the client (and the control pool) hold +references to it. The client must call :c:func:`mps_message_discard()` once +it has finished using the message. This calls :c:func:`ControlFree()` and +reclaims the memory. + +If the client simply drops its reference, the memory will not be +reclaimed until :c:func:`ArenaDestroy()`. This is intentional: the control +pool is not garbage-collected. + + +Final clearup +............. + +Final clearup is performed at :c:func:`ArenaDestroy()`, as follows: + +- Unused and unsent pre-allocated messages (one per trace id) are + freed with :c:macro:`TRACE_SET_ITER` calling :c:func:`TraceIdMessagesDestroy()` + which calls the message Delete functions (and thereby + :c:func:`ControlFree()`) on anything left in ``tsMessage[ti]`` and + ``tMessage[ti]``. + +- Unretrieved messages are freed by emptying the arena message queue + with :c:func:`MessageEmpty()`. + +- Retrieved but undiscarded messages are freed by destroying the + control pool. + + +Testing +------- + +The main test is "``zmess.c``". See notes there. + +Various other tests, including ``amcss.c``, also collect and report +:c:func:`mps_message_type_gc()` and :c:func:`mps_message_type_gc_start()`. + + +Coverage +........ + +Current tests do not check: + +- The less common why-codes (reasons why a trace starts). These should + be added to ``zmess.c``. + + diff --git a/mps/manual/html/_sources/design/message.txt b/mps/manual/html/_sources/design/message.txt index 12413437cbd..c46909e8b69 100644 --- a/mps/manual/html/_sources/design/message.txt +++ b/mps/manual/html/_sources/design/message.txt @@ -1,7 +1,374 @@ +.. _design-message: + + .. index:: pair: messages; design single: client message protocol -.. _design-message: -.. include:: ../../converted/message.rst +Client message protocol +======================= + +.. mps:prefix:: design.mps.message + pair: messages; design + single: client message protocol + + +Introduction +------------ + +:mps:tag:`intro` The client message protocol provides a means by which +clients can receive messages from the MPS asynchronously. Typical +messages may be low memory notification (or in general low utility), +finalization notification, soft-failure notification. There is a +general assumption that it should not be disastrous for the MPS client +to ignore messages, but that it is probably in the clients best +interest to not ignore messages. The justification for this is that +the MPS cannot force the MPS client to read and act on messages, so no +message should be critical. + +.. note:: + + Bogus, since we cannot force clients to check error codes either. + Pekka P. Pirinen, 1997-09-17. + +:mps:tag:`contents` This document describes the design of the external and +internal interfaces and concludes with a sketch of an example design +of an internal client. The example is that of implementing +finalization using PoolMRG. + +:mps:tag:`readership` Any MPS developer. + + +Requirements +------------ + +:mps:tag:`req` The client message protocol will be used for implementing +finalization (see design.mps.finalize and req.dylan.fun.final). It +will also be used for implementing the notification of various +conditions (possibly req.dylan.prot.consult is relevant here). + + +External interface +------------------ + +:mps:tag:`if.queue` Messages are presented as a single queue per arena. +Various functions are provided to inspect the queue and inspect +messages in it (see below). + + +Functions +......... + +:mps:tag:`if.fun` The following functions are provided: + +:mps:tag:`if.fun.poll` :c:func:`mps_message_poll()` sees whether there are any +messages pending. Returns 1 only if there is a message on the queue of +arena. Returns 0 otherwise. + +:mps:tag:`if.fun.enable` :c:func:`mps_message_type_enable()` enables the flow of +messages of a certain type. The queue of messages of a arena will +contain only messages whose types have been enabled. Initially all +message types are disabled. Effectively this function allows the +client to declare to the MPS what message types the client +understands. The MPS does not generate any messages of a type that +hasn't been enabled. This allows the MPS to add new message types (in +subsequent releases of a memory manager) without confusing the client. +The client will only be receiving the messages if they have explicitly +enabled them (and the client presumably only enables message types +when they have written the code to handle them). + +:mps:tag:`if.fun.disable` :c:func:`mps_message_type_disable()` disables the flow +of messages of a certain type. The antidote to +:c:func:`mps_message_type_enable()`. Disables the specified message type. +Flushes any existing messages of that type on the queue, and stops any +further generation of messages of that type. This permits clients to +dynamically decline interest in a message type, which may help to +avoid a memory leak or bloated queue when the messages are only +required temporarily. + +:mps:tag:`if.fun.get` :c:func:`mps_message_get()` begins a message "transaction". +If there is a message of the specified type on the queue then the +first such message will be removed from the queue and a handle to it +will be returned to the client via the ``messageReturn`` argument; in +this case the function will return :c:macro:`TRUE`. Otherwise it will return +:c:macro:`FALSE`. Having obtained a handle on a message in this way, the +client can use the type-specific accessors to find out about the +message. When the client is done with the message the client should +call :c:func:`mps_message_discard()`; failure to do so will result in a +resource leak. + +:mps:tag:`if.fun.discard` :c:func:`mps_message_discard()` ends a message +"transaction". It indicates to the MPS that the client is done with +this message and its resources may be reclaimed. + +:mps:tag:`if.fun.type.any` :c:func:`mps_message_queue_type()` determines the type +of a message in the queue. Returns :c:macro:`TRUE` only if there is a message +on the queue of arena, and in this case updates the ``typeReturn`` +argument to be the type of a message in the queue. Otherwise returns +:c:macro:`FALSE`. + +:mps:tag:`if.fun.type` :c:func:`mps_message_type()` determines the type of a +message (that has already been got). Only legal when inside a message +transaction (that is, after :c:func:`mps_message_get()` and before +:c:func:`mps_message_discard()`). Note that the type will be the same as the +type that the client passed in the call to :c:func:`mps_message_get()`. + + +Types of messages +................. + +:mps:tag:`type` The type governs the "shape" and meaning of the message. + +:mps:tag:`type.int` Types themselves will just be a scalar quantity, an +integer. + +:mps:tag:`type.semantics` A type indicates the semantics of the message. + +:mps:tag:`type.semantics.interpret` The semantics of a message are +interpreted by the client by calling various accessor methods on the +message. + +:mps:tag:`type.accessor` The type of a message governs which accessor +methods are legal to apply to the message. + +:mps:tag:`type.example` Some example types: + +:mps:tag:`type.finalization` There will be a finalization type. The type is +abstractly: ``FinalizationMessage(Ref)``. + +:mps:tag:`type.finalization.semantics` A finalization message indicates that +an object has been discovered to be finalizable (see +design.mps.poolmrg.def.final.object for a definition of finalizable). + +:mps:tag:`type.finalization.ref` There is an accessor to get the reference +of the finalization message (i.e. a reference to the object which is +finalizable) called :c:func:`mps_message_finalization_ref()`. + +:mps:tag:`type.finalization.ref.scan` Note that the reference returned +should be stored in scanned memory. + + +Compatibility issues +.................... + +:mps:tag:`compatibility` The following issues affect future compatibility of +the interface: + +:mps:tag:`compatibility.future.type-new` Notice that message of a type that +the client doesn't understand are not placed on the queue, therefore +the MPS can introduce new types of message and existing client will +still function and will not leak resources. This has been achieved by +getting the client to declare the types that the client understands +(with :c:func:`mps_message_type_enable()`, :mps:ref:`.if.fun.enable`). + +:mps:tag:`compatibility.future.type-extend` The information available in a +message of a given type can be extended by providing more accessor +methods. Old clients won't get any of this information but that's +okay. + + +Internal interface +------------------ + +Types +..... + +.. c:type:: struct MessageStruct *Message + +:mps:tag:`message.type` :c:type:`Message` is the type of messages. + +:mps:tag:`message.instance` Messages are instances of Message Classes. + +.. c:type:: struct MessageStruct *MessageStruct + +:mps:tag:`message.concrete` Concretely a message is represented by a +:c:type:`MessageStruct`. A :c:type:`MessageStruct` has the usual signature field +(see design.mps.sig). A :c:type:`MessageStruct` has a type field which +defines its type, a ring node, which is used to attach the message to +the queue of pending messages, a class field, which identifies a +:c:type:`MessageClass` object. + +:mps:tag:`message.intent` The intention is that a :c:type:`MessageStruct` will be +embedded in some richer object which contains information relevant to +that specific type of message. + +:mps:tag:`message.struct` The structure is declared as follows:: + + struct MessageStruct { + Sig sig; + MessageType type; + MessageClass class; + RingStruct node; + } MessageStruct; + + +.. c:type:: struct MessageClassStruct *MessageClass + +:mps:tag:`class` A message class is an encapsulation of methods. It +encapsulates methods that are applicable to all types of messages +(generic) and methods that are applicable to messages only of a +certain type (type-specific). + +:mps:tag:`class.concrete` Concretely a message class is represented by a +:c:type:`MessageClassStruct` (a struct). Clients of the Message module are +expected to allocate storage for and initialise the +:c:type:`MessageClassStruct`. It is expected that such storage will be +allocated and initialised statically. + +:mps:tag:`class.one-type` A message class implements exactly one message +type. The identifier for this type is stored in the ``type`` field of +the :c:type:`MessageClassStruct`. Note that the converse is not true: a +single message type may be implemented by two (or more) different +message classes (for example: for two pool classes that require +different implementations for that message type). + +:mps:tag:`class.methods.generic` The generic methods are as follows: + +* ``delete`` -- used when the message is destroyed (by the client + calling :c:func:`mps_message_discard()`). The class implementation should + finish the message (by calling :c:func:`MessageFinish()`) and storage for + the message should be reclaimed (if applicable). + +:mps:tag:`class.methods.specific` The type specific methods are: + +:mps:tag:`class.methods.specific.finalization` Specific to +``MessageTypeFinalization``: + +* ``finalizationRef`` -- returns a reference to the finalizable object + represented by this message. + +:mps:tag:`class.methods.specific.collectionstats` Specific to ``MessageTypeCollectionStats``: + +* ``collectionStatsLiveSize`` -- returns the number of bytes (of + objects) that were condemned but survived. + +* ``collectionStatsCondemnedSize`` -- returns the number of bytes + condemned in the collection. + +* ``collectionStatsNotCondemnedSize`` -- returns the the number of + bytes (of objects) that are subject to a GC policy (that is, + collectable) but were not condemned in the collection. + +:mps:tag:`class.sig.double` The :c:type:`MessageClassStruct` has a signature field +at both ends. This is so that if the :c:type:`MessageClassStruct` changes +size (by adding extra methods for example) then any static +initializers will generate errors from the compiler (there will be a +type error causes by initialising a non-signature type field with a +signature) unless the static initializers are changed as well. + +:mps:tag:`class.struct` The structure is declared as follows:: + + typedef struct MessageClassStruct { + Sig sig; /* design.mps.sig */ + const char *name; /* Human readable Class name */ + + /* generic methods */ + MessageDeleteMethod delete; /* terminates a message */ + + /* methods specific to MessageTypeFinalization */ + MessageFinalizationRefMethod finalizationRef; + + /* methods specific to MessageTypeCollectionStats */ + MessageCollectionStatsLiveSizeMethod collectionStatsLiveSize; + MessageCollectionStatsCondemnedSizeMethod collectionStatsCondemnedSize; + MessageCollectionStatsNotCondemnedSizeMethod collectionStatsNotCondemnedSize; + + Sig endSig; /* design.mps.message.class.sig.double */ + } MessageClassStruct; + + +:mps:tag:`space.queue` The arena structure is augmented with a structure for +managing for queue of pending messages. This is a ring in the +:c:type:`ArenaStruct`:: + + struct ArenaStruct + { + ... + RingStruct messageRing; + ... + } + + +Functions +......... + +.. c:function:: void MessageInit(Arena arena, Message message, MessageClass class) + +:mps:tag:`fun.init` Initializes the :c:type:`MessageStruct` pointed to by +``message``. The caller of this function is expected to manage the +store for the :c:type:`MessageStruct`. + +.. c:function:: void MessageFinish(Message message) + +:mps:tag:`fun.finish` Finishes the :c:type:`MessageStruct` pointed to by +``message``. The caller of this function is expected to manage the +store for the :c:type:`MessageStruct`. + +.. c:function:: void MessagePost(Arena arena, Message message) + +:mps:tag:`fun.post` Places a message on the queue of an arena. + +:mps:tag:`fun.post.precondition` Prior to calling the function, the node +field of the message must be a singleton. After the call to the +function the message will be available for MPS client to access. After +the call to the function the message fields must not be manipulated +except from the message's class's method functions (that is, you +mustn't poke about with the node field in particular). + +.. c:function:: void MessageEmpty(Arena arena) + +:mps:tag:`fun.empty` Empties the message queue. This function has the same +effect as discarding all the messages on the queue. After calling this +function there will be no messages on the queue. + +:mps:tag:`fun.empty.internal-only` This functionality is not exposed to +clients. We might want to expose this functionality to our clients in +the future. + + +Message life cycle +------------------ + +:mps:tag:`life` A message will be allocated by a client of the message +module, it will be initialised by calling :c:func:`MessageInit()`. The +client will eventually post the message on the external queue (in fact +most clients will create a message and then immediately post it). The +message module may then apply any of the methods to the message. The +message module will eventually destroy the message by applying the +``delete`` method to it. + + +Examples +-------- + +Finalization +............ + +.. note:: + + Possibly out of date, see design.mps.finalize and + design.mps.poolmrg instead. David Jones, 1997-08-28. + +This subsection is a sketch of how PoolMRG will use Messages for +finalization (see design.mps.poolmrg). + +PoolMRG has guardians (see design.mps.poolmrg.guardian). Guardians are +used to manage final references and detect when an object is +finalizable. + +The link part of a guardian will include a :c:type:`MessageStruct`. + +The :c:type:`MessageStruct` is allocated when the final reference is created +(which is when the referred to object is registered for finalization). +This avoids allocating at the time when the message gets posted (which +might be a tricky, undesirable, or impossible, time to allocate). + +PoolMRG has two queues: the entry queue, and the exit queue. The entry +queue will use a ring; the exit queue of MRG will simply be the +external message queue. + +The ``delete`` method frees both the link part and the reference part +of the guardian. + + diff --git a/mps/manual/html/_sources/design/object-debug.txt b/mps/manual/html/_sources/design/object-debug.txt index 0c82ad04912..d8072476c52 100644 --- a/mps/manual/html/_sources/design/object-debug.txt +++ b/mps/manual/html/_sources/design/object-debug.txt @@ -1,6 +1,405 @@ +.. _design-object-debug: + + .. index:: pair: debugging; design -.. _design-object-debug: -.. include:: ../../converted/Object-debug.rst +Debugging features for client objects +===================================== + +.. mps:prefix:: design.mps.object-debug + + +Introduction +------------ + +:mps:tag:`intro` This is the design for all the various debugging features +that MPS clients (and sometimes MPS developers) can use to discover +what is happening to their objects and the memory space. + +:mps:tag:`readership` MPS developers. + + +Overview +-------- + +:mps:tag:`over.fenceposts` In its current state, this document mostly talks +about fenceposts, straying a little into tagging where theses features +have an effect on each other. + +.. note:: + + There exist other documents that list other required features, and + propose interfaces and implementations. These will eventually be + folded into this one. Pekka P. Pirinen, 1998-09-10. + + +Requirements +------------ + +:mps:tag:`req.fencepost` Try to detect overwrites and underwrites of +allocated blocks by adding fenceposts (source req.product.??? VC++, +req.epcore.fun.debug.support). + +:mps:tag:`req.fencepost.size` The fenceposts should be at least 4 bytes on +either side or 8 bytes if on one side only, with an adjustable content +(although VC++ only has 4 bytes with pattern 0xFDFDFDFD, having +unwisely combined the implementation with other debug features). + +:mps:tag:`req.fencepost.check` There should be a function to check all the +fenceposts (source req.epcore.fun.debug.support). + +:mps:tag:`req.free-block` Try to detect attempts to write and read free +blocks. + +:mps:tag:`req.walk` There should be a way to map ("walk") a user function +over all allocated objects (except PS VM objects), possibly only in a +separate debugging variety/mode (source req.epcore.fun.debug.support). + +:mps:tag:`req.tag` There should be a way to store at least a word of user +data (a "tag", borrowing the SW term) with every object in debugging +mode, to be used in memory dumps (source req.product.??? VC++). + +:mps:tag:`req.tag.walk` The walking function (as required by :mps:ref:`.req.walk`) +should have access to this data (source req.epcore.fun.debug.support). + +:mps:tag:`req.dump.aver` It must be possible to perform a memory dump after +an :c:func:`AVER()` has fired. Naturally, if the information required for +the dump has been corrupted, it will fail, as softly as possible +(source @@@@). + +.. note:: + + There are more requirements, especially about memory dumps and + allocation locations. Pekka P. Pirinen, 1998-09-10. + + +Solution ideas +-------------- + +:mps:tag:`note.assumptions` I've tried not to assume anything about the +coincidence of manual/automatic, formatted/unformatted, and +ap/mps_alloc. I think those questions deserve to be decided on their +own merits. instead of being constrained by a debug feature. + +:mps:tag:`fence.content.repeat` The content of a fencepost could be +specified as a byte/word which used repeatedly to fill the fencepost. + +:mps:tag:`fence.content.template` The content could be given as a template +which is of the right size and is simply copied onto the fencepost. + +:mps:tag:`fence.walk` :mps:ref:`.req.fencepost.check` requires the ability to find +all the allocated objects. In formatted pools, this is not a problem. +In unformatted pools, we could use the walker. It's a feasible +strategy to bet that any pool that might have to support fenceposting +will also have a walking requirement. + +:mps:tag:`fence.tag` Fenceposting also needs to keep track which objects +have fenceposts. unless we manage to do them all. It would be easiest +to put this in the tags. + +:mps:tag:`fence.check.object` A function to check the fenceposts on a given +object would be nice. + +:mps:tag:`fence.ap` AP's could support fenceposting transparently by having +a mode where :c:func:`mps_reserve()` always goes out-of-line and fills in the +fenceposts (the pool's :c:func:`BufferFill()` method isn't involved). This +would leave the MPS with more freedom of implementation, especially +when combined with some of the other ideas. We think doing a function +call for every allocation is not too bad for debugging. + +:mps:tag:`fence.outside-ap` We could also let the client insert their own +fenceposts outside the MPS allocation mechanism. Even if fenceposting +were done like this, we'd still want it to be an MPS feature, so we'd +offer sample C macros for adding the size of the fencepost and filling +in the fencepost pattern. Possibly something like this (while we could +still store the parameters in the pool or allocation point, there +seems little point in doing so in this case, and having them as +explicit parameters to the macros allows the client to specify +constants to gain effiency):: + + #define mps_add_fencepost(size, fp_size) + #define mps_fill_fenceposts(obj, size, fp_size, fp_pattern) + +The client would need to supply their own fencepost checking function, +obviously, but again we could offer one that matches the sample +macros. + +:mps:tag:`fence.tail-only` In automatic pools, the presence of a fencepost +at the head of the allocated block results in the object reference +being an internal pointer. This means that the format or the pool +would need to know about fenceposting and convert between references +and pointers. This would slow down the critical path when fenceposting +is used. This can be ameliorated by putting a fencepost at the tail of +the block only: this obviates the internal pointer problem and could +provide almost the same degree of checking (provided the size was +twice as large), especially in copying pools, where there are normally +no gaps between allocated blocks. In addition to the inescapable +effects on allocation and freeing (including copying and reclaim +thereunder), only scanning would have to know about fenceposts. + +:mps:tag:`fence.tail-only.under` Walking over all the objects in the pool +would be necessary to detect underwrites, as one couldn't be sure that +there is a fencepost before any given object (or where it's located +exactly). If the pool were doing the checking, it could be sure: it +would know about alignments and it could put fenceposts in padding +objects (free blocks will have them because they were once allocated) +so there'd be one on either side of any object (except at the head of +a segment, which is not a major problem, and could be fixed by adding +a padding object at the beginning of every segment). This requires +some cleverness to avoid splinters smaller than the fencepost size, +but it can be done. + +:mps:tag:`fence.wrapper` On formatted pools, fenceposting could be +implemented by "wrapping" the client-supplied format at creation time. +The wrapper can handle the conversion from the fenceposted object and +back. This will be invisible to the client and gives the added benefit +that the wrapper can validate fenceposts on every format operation, +should it desire. That is, the pool would see the fenceposts as part +of the client object, but the client would only see its object; the +format wrapper would translate between the two. Note that hiding the +fenceposts from scan methods, which are required to take a contiguous +range of objects, is a bit complicated. + +:mps:tag:`fence.client-format` The MPS would supply such a wrapper, but +clients could also be allowed to write their own fenceposted formats +(provided they coordinate with allocation, see below). This would make +scanning fenceposted segments more efficient. + +:mps:tag:`fence.wrapper.variable` Furthermore, you could create different +classes of fencepost within a pool, because the fencepost itself could +have a variable format. For instance, you might choose to have the +fencepost be minimal (one to two words) for small objects, and more +detailed/complex for large objects (imagining that large objects are +likely vector-ish and subject to overruns). You could get really fancy +and have the fencepost class keyed to the object class (for example, +different allocation points create different classes of fenceposting). + +:mps:tag:`fence.wrapper.alloc` Even with a wrapped format, allocation and +freeing would still have know about the fenceposts. If allocation +points are used, either MPS-side (:mps:ref:`.fence.ap`) or client-side +(:mps:ref:`.fence.outside-ap`) fenceposting could be used, with the obvious +modifications. + +:mps:tag:`fence.wrapper.alloc.format` We could add three format methods, to +adjust the pointer and the size for alloc and free, to put down the +fenceposts during alloc, and to check them; to avoid slowing down all +allocation, this would require some MOPping to make the format class +affect the choice of the alloc and free methods (see +mail.pekka.1998-06-11.18-18). + +:mps:tag:`fence.wrapper.alloc.size` We could just communicate the size of +the fenceposts between the format and the allocation routines, but +then you couldn't use variable fenceposts (.fence.wrapper.variable). + +.. note:: + + All this applies to copying and reclaim in a straight-forward + manner, I think. + +:mps:tag:`fence.pool.wrapper` Pools can be wrapped as well. This could be a +natural way to represent/implement the fenceposting changes to the +Alloc and Free methods. [@@@@alignment] + +:mps:tag:`fence.pool.new-class` We could simply offer a debugging version of +each pool class (e.g., :c:func:`mps_pool_class_mv_debug()`). As we have seen, +debugging features have synergies which make it advantageous to have a +coordinated implementation, so splitting them up would not just +complicate the client interface, it would also be an implementation +problem; we can turn features on or off with pool init parameters. + +:mps:tag:`fence.pool.abstract` We could simply use pool init parameters only +to control all debugging features (optargs would be useful here). +While there migh be subclasses and wrappers internally, the client +would only see a single pool class; in the internal view, this would +be an abstract class, and the parameters would determine which +concrete class actually gets instantiated. + +:mps:tag:`tag.out-of-line` It would be nice if tags were stored out-of-line, +so they can be used to study allocation patterns and fragmentation +behaviours. Such an implementation of tagging could also easily be +shared among several pools. + + +Architecture +------------ + +:mps:tag:`pool` The implementation is at the pool level, because pools +manage allocated objects. A lot of the code will be generic, +naturally, but the data structures and the control interfaces attach +to pools. In particular, clients will be able to use tagging and +fenceposting separately on each pool. + +:mps:tag:`fence.size` Having fenceposts of adjustable size and pattern is +quite useful. We feel that restricting the size to an integral +multiple of the [pool or format?] alignment is harmless and simplifies +the implementation enormously. + +:mps:tag:`fence.template` We use templates (:mps:ref:`.fence.content.template`) to +fill in the fenceposts, but we do not give any guarantees about the +location of the fenceposts, only that they're properly aligned. This +leaves us the opportunity to do tail-only fenceposting, if we choose. + +:mps:tag:`fence.slop` [see impl.c.dbgpool.FenceAlloc @@@@] + +:mps:tag:`fence.check.free` We check the fenceposts when freeing an object. + +:mps:tag:`unified-walk` Combine the walking and tagging requirements +(:mps:ref:`.req.tag.walk` and @@@@) into a generic facility for walking and +tagging objects with just one interface and one name: tagging. Also +combine the existing formatted object walker into this metaphor, but +allowing the format and tag parameters of the step function be +optional. + +.. note:: + + This part has not been implemented yet Pekka P. Pirinen, + 1998-09-10. + +:mps:tag:`init` It simplifies the implementation of both tagging and +fenceposting if they are always on, so that we don't have to keep +track of which objects have been fenceposted and which have not, and +don't have to have three kinds of tags: for user data, for +fenceposting, and for both. So we determine this at pool init time +(and let fenceposting turn on tagging, if necessary). + +:mps:tag:`pool-parameters` Fencepost templates and tag formats are passed in +as pool parameters. + +:mps:tag:`modularity` While a combined generic implementation of tags and +fenceposts is provided, it is structured so that each part of it could +be implemented by a pool-specific mechanism with a minimum of new +protocol. + +.. note:: + + This will be improved, when we figure out formatted pools -- they + don't need tags for fenceposting. + +:mps:tag:`out-of-space` If there's no room for tags, we will not dip into +the reservoir, just fail to allocate the tag. If the alloc call had a +reservoir permit, we let it succeed even without a tag, and just make +sure the free method will not complain if it can't find a tag. If the +call didn't have a reservoir permit, we free the block allocated for +the object and fail the allocation, so that the client gets a chance +to do whatever low-memory actions they might want to do. + +.. note:: + + Should this depend on whether there is anything in the reservoir? + +This breaks the one-to-one relationship between tags and objects, so +some checks cannot be made, but we do count the "lost" tags. + +.. note:: + + Need to hash out how to do fenceposting in formatted pools. + + +Client interface +---------------- + +:mps:tag:`interface.fenceposting.check` +:c:func:`mps_pool_check_fenceposts()` is a function to check all +fenceposts in a pool (:c:func:`AVER()` if a problem is found) + +.. note:: + + From here on, these are tentative and incomplete. + +.. c:function:: mps_res_t mps_fmt_fencepost_wrap(mps_fmt_t *format_return, mps_arena_t arena, mps_fmt_t format, ...) + +:mps:tag:`interface.fenceposting.format` A function to wrap a format +(class) to provide fenceposting. + +.. c:function:: void (*mps_fmt_adjust_fencepost_t)(size_t *size_io) + +:mps:tag:`interface.fenceposting.adjust` A format method to adjust size of a +block about to be allocted to allow for fenceposts. + +.. c:function:: void (*mps_fmt_put_fencepost_t)(mps_addr_t * addr_io, size_t size) + +:mps:tag:`interface.fenceposting.add` A format method to add a fencepost +around a block about to be allocated. The :c:macro:`NULL` method adds a tail +fencepost. + +.. c:function:: mps_bool_t (*mps_fmt_check_fenceposts_t)(mps_addr_t) + +:mps:tag:`interface.fenceposting.checker` A format method to check the +fenceposts around an object. The :c:macro:`NULL` method checks tails. + +.. c:function:: mps_class_t mps_debug_class(mps_class_t class) + +:mps:tag:`interface.fenceposting.pool` A function to wrap a pool class +to provide fenceposting (note absence of arena parameter). + +``mps_res_t mps_alloc(mps_addr_t *, mps_pool_t, size_t);`` +``mps_res_t mps_alloc_dbg(mps_addr_t *, mps_pool_t, size_t, ...);`` +``mps_res_t mps_alloc_dbg_v(mps_addr_t *, mps_pool_t, size_t, va_list);`` + +:mps:tag:`interface.tags.alloc` Three functions to replace existing +:c:func:`mps_alloc()` (request.???.??? proposes to remove the varargs) + +.. c:function:: void (*mps_objects_step_t)(mps_addr_t addr, size_t size, mps_fmt_t format, mps_pool_t pool, void *tag_data, void *p) +.. c:function:: void mps_pool_walk(mps_arena_t arena, mps_pool_t pool, mps_objects_step_t step, void *p) +.. c:function:: void mps_arena_walk(mps_arena_t arena, mps_objects_step_t step, void *p) + +:mps:tag:`interface.tags.walker` Functions to walk all the allocated +objects in a pool or an arena (only client pools in this case), +``format`` and ``tag_data`` can be :c:macro:`NULL` (``tag_data`` really wants +to be ``void *``, not :c:type:`mps_addr_t`, because it's stored +together with the internal tag data in an MPS internal pool) + + +Examples +-------- + +:mps:tag:`example.debug-alloc` :: + + #define MPS_ALLOC_DBG(res_io, addr_io, pool, size) + MPS_BEGIN + static mps_tag_A_s _ts = { __FILE__, __LINE__ }; + + *res_io = mps_alloc(addr_io, pool, size, _ts_) + MPS_END + + +Implementation +-------------- + +:mps:tag:`new-pool` The client interface to control fenceposting +consists of the new classes :c:func:`mps_pool_class_mv_debug()`, +:c:func:`mps_pool_class_epdl_debug()`, and +:c:func:`mps_pool_class_epdr_debug()`, and their new init parameter of +type :c:type:`mps_pool_debug_option_s`. + +.. note:: + + This is a temporary solution, to get it out without writing lots + of new interface. Pekka P. Pirinen, 1998-09-10. + +:mps:tag:`new-pool.impl` The debug pools are implemented using the "class +wrapper" :c:func:`EnsureDebugClass()`, which produces a subclass with +modified ``init``, ``finish``, ``alloc``, and ``free`` methods. These +methods are implemented in the generic debug class code +(``impl.c.dbgpool``), and are basically wrappers around the superclass +methods (invoked through the ``pool->class->super`` field). To find +the data stored in the class for the debugging features, they use the +``debugMixin`` method provided by the subclass. So to make a debug +subclass, three things should be provided: a structure definition of +the instance containing a :c:type:`PoolDebugMixinStruct`, a pool class +function that uses :c:func:`EnsureDebugClass()`, and a ``debugMixin`` method +that locates the :c:type:`PoolDebugMixinStruct` within an instance. + +:mps:tag:`tags.splay` The tags are stored in a splay tree of tags +allocated from a subsidiary MFS pool. The client needs to specify the +(maximum) size of the client data in a tag, so that the pool can be +created. + +.. note:: + + Lots more should be said, eventually. Pekka P. Pirinen, + 1998-09-10. + + diff --git a/mps/manual/html/_sources/design/old.txt b/mps/manual/html/_sources/design/old.txt index f6999e47531..29525beab6d 100644 --- a/mps/manual/html/_sources/design/old.txt +++ b/mps/manual/html/_sources/design/old.txt @@ -14,32 +14,55 @@ Old design .. toctree:: :numbered: + alloc-frame arena + arenavm bt - cbs + buffer check class-interface collection + diag finalize fix + interface-c + io + lib lock + locus message + message-gc object-debug pool poolamc + poolams + poolawl + poollo + poolmfs + poolmrg poolmvff prot + protan + protli + protsu protocol + pthreadext reservoir root scan seg + shield splay + sso1al telemetry + thread-manager thread-safety trace type version-library version vm + vman + vmo1 + vmso writef diff --git a/mps/manual/html/_sources/design/pool.txt b/mps/manual/html/_sources/design/pool.txt index 992eac425ff..fbfb9fcd36c 100644 --- a/mps/manual/html/_sources/design/pool.txt +++ b/mps/manual/html/_sources/design/pool.txt @@ -1,6 +1,63 @@ +.. _design-pool: + + .. index:: pair: pool class mechanism; design -.. _design-pool: -.. include:: ../../converted/pool.rst +Pool and pool class mechanisms +============================== + +.. mps:prefix:: design.mps.pool + + +Definitions +----------- + +:mps:tag:`def.outer-structure` The "outer structure" (of a pool) is a C +object of type :c:type:`PoolXXXStruct` or the type ``struct PoolXXXStruct`` +itself. + +:mps:tag:`def.generic-structure` The "generic structure" is a C object of +type :c:type:`PoolStruct` (found embedded in the outer-structure) or the +type ``struct PoolStruct`` itself. + + +Defaults +-------- + +:mps:tag:`align` When initialised, the pool gets the default alignment +(:c:macro:`ARCH_ALIGN`). + +:mps:tag:`no` If a pool class doesn't implement a method, and doesn't expect +it to be called, it should use a non-method (``PoolNo*``) which will +cause an assertion failure if they are reached. + +:mps:tag:`triv` If a pool class supports a protocol but does not require any +more than a trivial implementation, it should use a trivial method +(``PoolTriv*``) which will do the trivial thing. + +:mps:tag:`outer-structure.sig` It is good practice to put the signature for +the outer structure at the end (of the structure). This is because +there's already one at the beginning (in the poolStruct) so putting it +at the end gives some extra fencepost checking. + + +Requirements +------------ + +.. note:: + + Placeholder: must derive the requirements from the architecture. + +:mps:tag:`req.fix` :c:func:`PoolFix()` must be fast. + + +Other +----- + +Interface in mpm.h +Types in mpmst.h +See also design.mps.poolclass + + diff --git a/mps/manual/html/_sources/design/poolamc.txt b/mps/manual/html/_sources/design/poolamc.txt index 6bd304ff52e..8ececc616a4 100644 --- a/mps/manual/html/_sources/design/poolamc.txt +++ b/mps/manual/html/_sources/design/poolamc.txt @@ -1,7 +1,798 @@ -.. index:: - pair: AMC pool; design - single: pool; AMC design - .. _design-poolamc: -.. include:: ../../converted/poolamc.rst + +.. index:: + pair: AMC pool class; design + single: pool class; AMC design + + +AMC pool class +============== + +.. mps:prefix:: design.mps.poolamc + pair: AMC pool class; design + single: pool class; AMC design + + +Introduction +~~~~~~~~~~~~ + +:mps:tag:`intro` This document contains a guide (:mps:ref:`.guide`) to the MPS AMC +pool class, followed by the historical initial design +(:mps:ref:`.initial-design`). + +:mps:tag:`readership` Any MPS developer. + + +Guide +~~~~~ + +:mps:tag:`guide` The AMC pool class is a general-purpose automatic +(collecting) pool class. It is intended for most client objects. AMC +is "Automatic, Mostly Copying": it preserves objects by copying, +except when an ambiguous reference 'nails' the object in place. It is +generational. Chain: specify capacity and mortality of generations 0 +to *N* − 1. Survivors from generation *N* − 1 get promoted into an +arena-wide "top" generation (often anachronistically called the +"dynamic" generation, which was the term on the Lisp Machine). + + +Segment states +-------------- + +:mps:tag:`seg.state` AMC segments are in one of three states: "mobile", +"boarded", or "stuck". + +:mps:tag:`seg.state.mobile` Segments are normally **mobile**: all objects on +the seg are un-nailed, and thus may be preserved by copying. + +:mps:tag:`seg.state.boarded` An ambiguous reference to any address within an +segment makes that segment **boarded**: a nailboard is allocated to +record ambiguous references ("nails"), but un-nailed objects on the +segment are still preserved by copying. + +:mps:tag:`seg.state.stuck` Stuck segments only occur in emergency tracing: a +discovery fix to an object in a mobile segment is recorded in the only +non-allocating way available: by making the entire segment **stuck**. + + +Pads +---- + +(See job001809_ and job001811_, and mps/branch/2009-03-31/padding.) + +.. _job001809: http://www.ravenbrook.com/project/mps/issue/job001809/ +.. _job001811: http://www.ravenbrook.com/project/mps/issue/job001811/ + +:mps:tag:`pad` A pad is logically a trivial client object. Pads are created +by the MPS asking the client's format code to create them, to fill up +a space in a segment. Thereafter, the pad appears to the MPS as a +normal client object (that is: the MPS cannot distinguish a pad from a +client object). + +:mps:tag:`pad.reason` AMC creates pads for three reasons: buffer empty +fragment (BEF), large segment padding (LSP), and non-mobile reclaim +(NMR). (Large segment pads were new with job001811_.) + +:mps:tag:`pad.reason.bef` Buffer empty fragment (BEF) pads are made by +:c:func:`AMCBufferEmpty()` whenever it detaches a non-empty buffer from an +AMC segment. Buffer detachment is most often caused because the buffer +is too small for the current buffer reserve request (which may be +either a client requested or a forwarding allocation). Detachment may +happen for other reasons, such as trace flip. + +:mps:tag:`pad.reason.lsp` Large segment padding (LSP) pads are made by +:c:func:`AMCBufferFill()` when the requested fill size is "large" (see `The +LSP payoff calculation`_ below). :c:func:`AMCBufferFill()` fills the buffer +to exactly the size requested by the current buffer reserve operation; +that is: it does not round up to the whole segment size. This prevents +subsequent small objects being placed in the same segment as a single +very large object. If the buffer fill size is less than the segment +size, :c:func:`AMCBufferFill()` fills any remainder with an large segment +pad. + +:mps:tag:`pad.reason.nmr` Non-mobile reclaim (NMR) pads are made by +:c:func:`amcReclaimNailed()`, when performing reclaim on a non-mobile (that +is, either boarded or stuck) segment: + +The more common NMR scenario is reclaim of a boarded segment after a +non-emergency trace. Ambiguous references into the segment are +recorded as nails. Subsequent exact references to a nailed object do +nothing further, but exact refs that do not match a nail cause +preserve-by-copy and leave a forwarding object. Unreachable objects +are not touched during the scan+fix part of the trace. On reclaim, +only nailed objects need to be preserved; others (namely forwarding +pointers and unreachable objects) are replaced by an NMR pad. (Note +that a BEF or LSP pad appears to be an unreachable object, and is +therefore overwritten by an NMR pad). + +The less common NMR scenario is after emergency tracing. Boarded +segments still occur; they may have nailed objects from ambiguous +references, forwarding objects from pre-emergency exact fixes, nailed +objects from mid-emergency exact fixes, and unpreserved objects; +reclaim is as in the non-emergency case. Stuck segments may have +forwarding objects from pre-emergency exact fixes, objects from +mid-emergency fixes, and unreachable objects -- but the latter two are +not distinguishable because there is no nailboard. On reclaim, all +objects except forwarding pointers are preserved; each forwarding +object is replaced by an NMR pad. + +If :c:func:`amcReclaimNailed()` finds no objects to be preserved then it +calls :c:func:`SegFree()` (new with job001809_). + + +Placement pads are okay +----------------------- + +Placement pads are the BEF and LSP pads created in "to-space" when +placing objects into segments. This wasted space is an expected +space-cost of AMC's naive (but time-efficient) approach to placement +of objects into segments. This is normally not a severe problem. (The +worst case is a client that always requests ``ArenaAlign() + 1`` byte +objects: this has a nearly 100% overhead). + + +Retained pads could be a problem +-------------------------------- + +Retained pads are the NMR pads stuck in "from-space": non-mobile +segments that were condemned but have preserved-in-place objects +cannot be freed by :c:func:`amcReclaimNailed()`. The space around the +preserved objects is filled with NMR pads. + +In the worst case, retained pads could waste an enormous amount of +space! A small (one-byte) object could retain a multi-page segment for +as long as the ambiguous reference persists; that is: indefinitely. +Imagine a 256-page (1 MiB) segment containing a very large object +followed by a handful of small objects. An ambiguous reference to one +of the small objects will unfortunately cause the entire 256-page +segment to be retained, mostly as an NMR pad; this is a massive +overhead of wasted space. + +AMC mitigates this worst-case behaviour, by treating large segments +specially. + + +Small, medium, and large segments +--------------------------------- + +AMC categorises segments as **small** (one page), **medium** +(several pages), or **large** (``AMCLargeSegPAGES`` or more):: + + pages = SegSize(seg) / ArenaAlign(arena); + if(pages == 1) { + /* small */ + } else if(pages < AMCLargeSegPAGES) { + /* medium */ + } else { + /* large */ + } + +``AMCLargeSegPAGES`` is currently 8 -- see `The LSP payoff +calculation`_ below. + +AMC might treat "Large" segments specially, in two ways: + +- :mps:tag:`large.single-reserve` A large segment is only used for a single + (large) buffer reserve request; the remainder of the segment (if + any) is immediately padded with an LSP pad. + +- :mps:tag:`large.lsp-no-retain` Nails to such an LSP pad do not cause + AMCReclaimNailed() to retain the segment. + +:mps:ref:`.large.single-reserve` is implemented. See job001811_. + +:mps:ref:`.large.lsp-no-retain` is **not** currently implemented. + +The point of :mps:ref:`.large.lsp-no-retain` would be to avoid retention of +the (large) segment when there is a spurious ambiguous reference to +the LSP pad at the end of the segment. Such an ambiguous reference +might happen naturally and repeatably if the preceding large object is +an array, the array is accessed by an ambiguous element pointer (for +example, on the stack), and the element pointer ends up pointing just +off the end of the large object (as is normal for sequential element +access in C) and remains with that value for a while. (Such an +ambiguous reference could also occur by chance, for example, by +coincidence with an ``int`` or ``float``, or when the stack grows to +include old unerased values). + +Implementing :mps:ref:`.large.lsp-no-retain` is a little tricky. A pad is +indistinguishable from a client object, so AMC has no direct way to +detect, and safely ignore, the final LSP object in the seg. If AMC +could *guarantee* that the single buffer reserve +(:mps:ref:`.large.single-reserve`) is only used for a single *object*, then +:c:func:`AMCReclaimNailed()` could honour a nail at the start of a large seg +and ignore all others; this would be extremely simple to implement. +But AMC cannot guarantee this, because in the MPS Allocation Point +Protocol the client is permitted to make a large buffer reserve and +then fill it with many small objects. In such a case, AMC must honour +all nails (if the buffer reserve request was an exact multiple of +:c:func:`ArenaAlign()`), or all nails except to the last object (if there +was a remainder filled with an LSP pad). Because an LSP pad cannot be +distinguished from a client object, and the requested allocation size +is not recorded, AMC cannot distinguish these two conditions at +reclaim time. Therefore AMC must record whether or not the last object +in the seg is a pad, in order to ignore nails to it. This could be +done by adding a flag to :c:type:`AMCSegStruct`. (This can be done without +increasing the structure size, by making the ``Bool new`` field +smaller than its current 32 bits.) + + +The LSP payoff calculation +-------------------------- + +The LSP fix for job001811_ treats large segments differently. Without +it, after allocating a very large object (in a new very large +multi-page segment), MPS would happily place subsequent small objects +in any remaining space at the end of the segment. This would risk +pathological fragmentation: if these small objects were systematically +preserved by ambiguous refs, enormous NMR pads would be retained along +with them. + +The payoff calculation is a bit like deciding whether or not to +purchase insurance. For single-page and medium-sized segments, we go +ahead and use the remaining space for subsequent small objects. This +is equivalent to choosing **not** to purchase insurance. If the small +objects were to be preserved by ambiguous refs, the retained NMR pads +would be big, but not massive. We expect such ambiguous refs to be +uncommon, so we choose to live with this slight risk of bad +fragmentation. The benefit is that the remaining space is used. + +For large segments, we decide that the risk of using the remainder is +just too great, and the benefit too small, so we throw it away as an +LSP pad. This is equivalent to purchasing insurance: we choose to pay +a known small cost every time, to avoid risking an occasional +disaster. + +To decide what size of segment counts as "large", we must decide how +much uninsured risk we can tolerate, versus how much insurance cost we +can tolerate. The likelihood of ambiguous references retaining objects +is entirely dependent on client behaviour. However, as a sufficient +"one size fits all" policy, I (RHSK 2009-09-14) have judged that +segments smaller than eight pages long do not need to be treated as +large: the insurance cost to "play safe" would be considerable +(wasting up to one page of remainder per seven pages of allocation), +and the fragmentation overhead risk is not that great (at most eight +times worse than the unavoidable minimum). So ``AMCLargeSegPAGES`` is +defined as 8 in config.h. As long as the assumption that most segments +are not ambiguously referenced remains correct, I expect this policy +will be satisfactory. + +To verify that this threshold is acceptable for a given client, +poolamc.c calculates metrics; see `Feedback about retained pages`_ +below. If this one-size-fits-all approach is not satisfactory, +``AMCLargeSegPAGES`` could be made a client-tunable parameter. + + +Retained pages +-------------- + +The reasons why a segment and its pages might be retained are: + +1. ambiguous reference to first-obj: unavoidable page retention (only + the mutator can reduce this, if they so wish, by nulling out ambig + referencess); +2. ambiguous reference to rest-obj: tuning MPS LSP policy could + mitigate this, reducing the likelihood of rest-objs being + co-located with large first-objs; +3. ambiguous reference to final pad: implementing + :mps:ref:`.large.lsp-no-retain` could mitigate this; +4. ambiguous reference to other (NMR) pad: hard to mitigate, as pads + are indistinguishable from client objects; +5. emergency trace; +6. non-object-aligned ambiguous ref: fixed by job001809_; +7. other reason (for example, buffered at flip): not expected to be a + problem. + +This list puts the reasons that are more "obvious" to the client +programmer first, and the more obscure reasons last. + + +Feedback about retained pages +----------------------------- + +(New with job001811_). AMC now accumulates counts of pages condemned +and retained during a trace, in categories according to size and +reason for retention, and emits diagnostic at trace-end via the +``pool->class->traceEnd`` method. See comments on the +:c:type:`PageRetStruct` in poolamc.c. These page-based metrics are not as +precise as actually counting the size of objects, but they require +much less intrusive code to implement, and should be sufficient to +assess whether AMC's page retention policies and behaviour are +acceptable. + + +Initial design +~~~~~~~~~~~~~~ + + +Introduction +------------ + +:mps:tag:`intro` This is the design of the AMC Pool Class. AMC stands for +Automatic Mostly-Copying. This design is highly fragmentory and some +may even be sufficiently old to be misleading. + +:mps:tag:`readership` The intended readership is any MPS developer. + + +Overview +-------- + +:mps:tag:`overview` This class is intended to be the main pool class used by +Harlequin Dylan. It provides garbage collection of objects (hence +"automatic"). It uses generational copying algorithms, but with some +facility for handling small numbers of ambiguous references. Ambiguous +references prevent the pool from copying objects (hence "mostly +copying"). It provides incremental collection. + +.. note:: + + A lot of this design is awesomely old. David Jones, 1998-02-04. + + +Definitions +----------- + +:mps:tag:`def.grain` Grain. An quantity of memory which is both aligned to +the pool's alignment and equal to the pool's alignment in size. That +is, the smallest amount of memory worth talking about. + + +Segments +-------- + +:mps:tag:`seg.class` AMC allocates segments of class :c:type:`AMCSegClass`, which +is a subclass of :c:type:`GCSegClass`. Instances contain a ``segTypeP`` +field, which is of type ``int*``. + +:mps:tag:`seg.gen` AMC organizes the segments it manages into generations. + +:mps:tag:`seg.gen.map` Every segment is in exactly one generation. + +:mps:tag:`seg.gen.ind` The segment's ``segTypeP`` field indicates which +generation (that the segment is in) (an :c:type:`AMCGenStruct` see blah +below). + +:mps:tag:`seg.typep` The ``segTypeP`` field actually points to either the +type field of a generation or to the type field of a nail board. + +:mps:tag:`seg.typep.distinguish` The ``type`` field (which can be accessed +in either case) determines whether the ``segTypeP`` field is pointing +to a generation or to a nail board. + +:mps:tag:`seg.gen.get` The map from segment to generation is implemented by +:c:func:`AMCSegGen()` which deals with all this. + + +Fixing and nailing +------------------ + +.. note:: + + This section contains placeholders for design rather than design + really. David Jones, 1998-02-04. + +:mps:tag:`nailboard` AMC uses a nail board structure for recording ambiguous +references to segments. A nail board is a bit table with one bit per +grain in the segment. + +:mps:tag:`nailboard.create` Nail boards are allocated dynamically whenever a +segment becomes newly ambiguously referenced. + +:mps:tag:`nailboard.destroy` They are deallocated during reclaim. Ambiguous +fixes simply set the appropriate bit in this table. This table is used +by subsequent scans and reclaims in order to work out what objects +were marked. + +:mps:tag:`nailboard.emergency` During emergency tracing two things relating +to nail boards happen that don't normally: + +1. :mps:tag:`nailboard.emergency.nonew` Nail boards aren't allocated when we + have new ambiguous references to segments. + + :mps:tag:`nailboard.emergency.nonew.justify` We could try and allocate a + nail board, but we're in emergency mode so short of memory so it's + unlikely to succeed, and there would be additional code for yet + another error path which complicates things. + +2. :mps:tag:`nailboard.emergency.exact` nail boards are used to record exact + references in order to avoid copying the objects. + + :mps:tag:`nailboard.hyper-conservative` Not creating new nail boards + (:mps:ref:`.nailboard.emergency.nonew` above) means that when we have a new + reference to a segment during emergency tracing then we nail the + entire segment and preserve everything in place. + +:mps:tag:`fix.nail.states` Partition the segment states into four sets: + +1. white segment and not nailed (and has no nail board); +2. white segment and nailed and has no nail board; +3. white segment and nailed and has nail board; +4. the rest. + +:mps:tag:`fix.nail.why` A segment is recorded as being nailed when either +there is an ambiguous reference to it, or there is an exact reference +to it and the object couldn't be copied off the segment (because there +wasn't enough memory to allocate the copy). In either of these cases +reclaim cannot simply destroy the segment (usually the segment will +not be destroyed because it will have live objects on it, though see +:mps:ref:`.nailboard.limitations.middle` below). If the segment is nailed then +we might be using a nail board to mark objects on the segment. +However, we cannot guarantee that being nailed implies a nail board, +because we might not be able to allocate the nail board. Hence all +these states actually occur in practice. + +:mps:tag:`fix.nail.distinguish` The nailed bits in the segment descriptor +(:c:type:`SegStruct`) are used to record whether a segment is nailed or not. +The ``segTypeP`` field of the segment either points to (the "type" +field of) an ``AMCGen`` or to an ``AMCNailBoard``, the type field can +be used to determine which of these is the case. (see :mps:ref:`.seg.typep` +above). + +:mps:tag:`nailboard.limitations.single` Just having a single nail board per +segment prevents traces from improving on the findings of each other: +a later trace could find that a nailed object is no longer nailed or +even dead. Until the nail board is discarded, that is. + +:mps:tag:`nailboard.limitations.middle` An ambiguous reference into the +middle of an object will cause the segment to survive, even if there +are no surviving objects on it. + +:mps:tag:`nailboard.limitations.reclaim` :c:func:`AMCReclaimNailed()` could cover +each block of reclaimed objects between two nailed objects with a +single padding object, speeding up further scans. + + +Emergency tracing +----------------- + +:mps:tag:`emergency.fix` :c:func:`AMCFixEmergency()` is at the core of AMC's +emergency tracing policy (unsurprisingly). :c:func:`AMCFixEmergency()` +chooses exactly one of three options: + +1. use the existing nail board structure to record the fix; +2. preserve and nail the segment in its entirety; +3. snapout an exact (or high rank) pointer to a broken heart to the + broken heart's forwarding pointer. + +If the rank of the reference is ``RankAMBIG`` then it either does (1) +or (2) depending on wether there is an existing nail board or not. +Otherwise (the rank is exact or higher) if there is a broken heart it +is used to snapout the pointer. Otherwise it is as for an +``RankAMBIG`` reference: we either do (1) or (2). + +:mps:tag:`emergency.scan` This is basically as before, the only complication +is that when scanning a nailed segment we may need to do multiple +passes, as :c:func:`FixEmergency()` may introduce new marks into the nail +board. + + +Buffers +------- + +:mps:tag:`buffer.class` AMC uses buffer of class :c:type:`AMCBufClass` (a subclass +of SegBufClass). + +:mps:tag:`buffer.gen` Each buffer allocates into exactly one generation. + +:mps:tag:`buffer.field.gen` ``AMCBuf`` buffer contain a gen field which +points to the generation that the buffer allocates into. + +:mps:tag:`buffer.fill.gen` :c:func:`AMCBufferFill()` uses the generation (obtained +from the ``gen`` field) to initialise the segment's ``segTypeP`` field +which is how segments get allocated in that generation. + +:mps:tag:`buffer.condemn` We condemn buffered segments, but not the contents +of the buffers themselves, because we can't reclaim uncommitted +buffers (see design.mps.buffer for details). If the segment has a +forwarding buffer on it, we detach it. + +.. note:: + + Why? Forwarding buffers are detached because they used to cause + objects on the same segment to not get condemned, hence caused + retention of garbage. Now that we condemn the non-buffered portion + of buffered segments this is probably unnecessary. David Jones, + 1998-06-01. + + But it's probably more efficient than keeping the buffer on the + segment, because then the other stuff gets nailed -- Pekka P. + Pirinen, 1998-07-10. + +If the segment has a mutator buffer on it, we nail the buffer. If the +buffer cannot be nailed, we give up condemning, since nailing the +whole segment would make it survive anyway. The scan methods skip over +buffers and fix methods don't do anything to things that have already +been nailed, so the buffer is effectively black. + + +Types +----- + +:mps:tag:`struct` :c:type:`AMCStruct` is the pool class AMC instance structure. + +:mps:tag:`struct.pool` Like other pool class instances, it contains a +:c:type:`PoolStruct` containing the generic pool fields. + +:mps:tag:`struct.format` The ``format`` field points to a :c:type:`Format` +structure describing the object format of objects allocated in the +pool. The field is intialized by :c:func:`AMCInit()` from a parameter, and +thereafter it is not changed until the pool is destroyed. + +.. note:: + + Actually the format field is in the generic :c:type:`PoolStruct` these + days. David Jones, 1998-09-21. + +.. note:: + + There are lots more fields here. + + +Generations +----------- + +:mps:tag:`gen` Generations partition the segments that a pool manages (see +:mps:ref:`.seg.gen.map` above). + +:mps:tag:`gen.collect` Generations are more or less the units of +condemnation in AMC. And also the granularity for forwarding (when +copying objects during a collection): all the objects which are copied +out of a generation use the same forwarding buffer for allocating the +new copies, and a forwarding buffer results in allocation in exactly +one generation. + +:mps:tag:`gen.rep` Generations are represented using an :c:type:`AMCGenStruct` +structure. + +:mps:tag:`gen.create` All the generation are create when the pool is created +(during :c:func:`AMCInitComm()`). + +:mps:tag:`gen.manage.ring` An AMC's generations are kept on a ring attached +to the :c:type:`AMCStruct` (the ``genRing`` field). + +:mps:tag:`gen.manage.array` They are also kept in an array which is +allocated when the pool is created and attached to the :c:type:`AMCStruct` +(the gens field holds the number of generations, the ``gen`` field +points to an array of ``AMCGen``). + +.. note:: + + it seems to me that we could probably get rid of the ring. David + Jones, 1998-09-22. + +:mps:tag:`gen.number` There are ``AMCTopGen + 2`` generations in total. +"normal" generations numbered from 0 to ``AMCTopGen`` inclusive and an +extra "ramp" generation (see :mps:ref:`.gen.ramp` below). + +:mps:tag:`gen.forward` Each generation has an associated forwarding buffer +(stored in the ``forward`` field of ``AMCGen``). This is the buffer +that is used to forward objects out of this generation. When a +generation is created in :c:func:`AMCGenCreate()`, its forwarding buffer has +a null ``p`` field, indicating that the forwarding buffer has no +generation to allocate in. The collector will assert out (in +:c:func:`AMCBufferFill()` where it checks that ``buffer->p`` is an +``AMCGen``) if you try to forward an object out of such a generation. + +:mps:tag:`gen.forward.setup` All the generation's forwarding buffer's are +associated with generations when the pool is created (just after the +generations are created in :c:func:`AMCInitComm()`). + + +Ramps +----- + +:mps:tag:`ramp` Ramps usefully implement the begin/end +:c:func:`mps_alloc_pattern_ramp()` interface. + +:mps:tag:`gen.ramp` To implement ramping (request.dylan.170423), AMC uses a +special "ramping mode", where promotions are redirected. One +generation is designated the "ramp generation" (``amc->rampGen`` in +the code). + +:mps:tag:`gen.ramp.ordinary` Ordinarily, that is whilst not ramping, objects +are promoted into the ramp generation from younger generations and are +promoted out to older generations. The generation that the ramp +generation ordinarily promotes into is designated the "after-ramp +generation" (``amc->afterRampGen``). + +:mps:tag:`gen.ramp.particular` the ramp generation is the second oldest +generation and the after-ramp generation is the oldest generation. + +:mps:tag:`gen.ramp.possible` In alternative designs it might be possible to +make the ramp generation a special generation that is only promoted +into during ramping, however, this is not done. + +:mps:tag:`gen.ramp.ramping` The ramp generation is promoted into itself +during ramping mode; + +:mps:tag:`gen.ramp.after` after this mode ends, the ramp generation is +promoted into the after-ramp generation as usual. + +:mps:tag:`gen.ramp.after.once` Care is taken to +ensure that there is at least one collection where stuff is promoted +from the ramp generation to the after-ramp generation even if ramping +mode is immediately re-entered. + +:mps:tag:`ramp.mode` This behaviour is controlled in a slightly convoluted +manner by a state machine. The rampMode field of the pool forms an +important part of the state of the machine. + +There are five states: OUTSIDE, BEGIN, RAMPING, FINISH, and +COLLECTING. These appear in the code as ``RampOUTSIDE`` and so on. + +:mps:tag:`ramp.state.cycle.usual` The usual progression of states is a +cycle: OUTSIDE → BEGIN → RAMPING → FINISH → COLLECTING → OUTSIDE. + +:mps:tag:`ramp.count` The pool just counts the number of APs that have begun +ramp mode (and not ended). No state changes occur unless this count +goes from 0 to 1 (starting the first ramp) or from 1 to 0 (leaving the +last ramp). In other words, all nested ramps are ignored (see code in +:c:func:`AMCRampBegin()` and :c:func:`AMCRampEnd()`). + +:mps:tag:`ramp.state.invariant.count` In the OUTSIDE state the count must be +zero. In the BEGIN and RAMPING states the count must be greater than +zero. In the FINISH and COLLECTING states the count is not +constrained. + +:mps:tag:`ramp.state.invariant.forward` When in OUTSIDE, BEGIN, or +COLLECTING, the ramp generation forwards to the after-ramp generation. +When in RAMPING or FINISH, the ramp generation forwards to itself. + +:mps:tag:`ramp.outside` The pool is initially in the OUTSIDE state. The only +transition away from the OUTSIDE state is to the BEGIN state, when a +ramp is entered. + +:mps:tag:`ramp.begin` When the count goes up from zero, the state moves from +COLLECTING or OUTSIDE to BEGIN. + +:mps:tag:`ramp.begin.leave` We can leave the BEGIN state to either the +OUTSIDE or the RAMPING state. + +:mps:tag:`ramp.begin.leave.outside` We go to OUTSIDE if the count drops to 0 +before a collection starts. This shortcuts the usual cycle of states +for small enough ramps. + +:mps:tag:`ramp.begin.leave.ramping` We enter the RAMPING state if a +collection starts that condemns the ramp generation (pedantically when +a new GC begins, and a segment in the ramp generation is condemned, we +leave the BEGIN state, see AMCWhiten). At this point we switch the +ramp generation to forward to itself (:mps:ref:`.gen.ramp.ramping`). + +:mps:tag:`ramp.ramping.leave` We leave the RAMPING state and go to the +FINISH state when the ramp count goes back to zero. Thus, the FINISH +state indicates that we have started collecting the ramp generation +while inside a ramp which we have subsequently finished. + +:mps:tag:`ramp.finish.remain` We remain in the FINISH state until we next +start to collect the ramp generation (condemn it), regardless of +entering or leaving any ramps. This ensures that the ramp generation +will be collected to the after-ramp generation at least once. + +:mps:tag:`ramp.finish.leave` When we next condemn the ramp genearation, we +move to the COLLECTING state. At this point the forwarding generations +are switched back so that the ramp generation promotes into the +after-ramp generation on this collection. + +:mps:tag:`ramp.collecting.leave` We leave the COLLECTING state when the GC +enters reclaim (specifically, when a segment in the ramp generation is +reclaimed), or when we begin another ramp. Ordinarily we enter the +OUTSIDE state, but if the client has started a ramp then we go +directly to the BEGIN state. + +_`.ramp.collect-all` There used to be two flavours of ramps: the +normal one and the collect-all flavour that triggered a full GC after +the ramp end. This was a hack for producing certain Dylan statistics, +and no longer has any effect (the flag is passed to +:c:func:`AMCRampBegin()`, but ignored there). + + +Headers +------- + +:mps:tag:`header` AMC supports a fixed-size header on objects, with the +client pointers pointing after the header, rather than the base of the +memory block. See format documentation for details of the interface. + +:mps:tag:`header.client` The code mostly deals in client pointers, only +computing the base and limit of a block when these are needed (such as +when an object is copied). In several places, the code gets a block of +some sort, a segment or a buffer, and creates a client pointer by +adding the header length (``pool->format->headerLength``). + +:mps:tag:`header.fix` There are two versions of the fix method, due to its +criticality, with (:c:func:`AMCHeaderFix()`) and without (:c:func:`AMCFix()`) +headers. The correct one is selected in :c:func:`AMCInitComm()`, and placed +in the pool's fix field. This is the main reason why fix methods +dispatch through the instance, rather than the class like all other +methods. + + +Old and aging notes below here +------------------------------ + +.. c:function:: void AMCFinish(Pool pool) + +:mps:tag:`finish.forward` If the pool is being destroyed it is OK to destroy +the forwarding buffers, as the condemned set is about to disappear. + + +.. c:function:: void AMCBufferEmpty(Pool pool, Buffer buffer, Addr init, Addr limit) + +:mps:tag:`flush` Removes the connexion between a buffer and a group, so that +the group is no longer buffered, and the buffer is reset and will +cause a refill when next used. + +:mps:tag:`flush.pad` The group is padded out with a dummy object so that it +appears full. + +:mps:tag:`flush.expose` The buffer needs exposing before writing the padding +object onto it. If the buffer is being used for forwarding it might +already be exposed, in this case the segment attached to it must be +covered when it leaves the buffer. See :mps:ref:`.fill.expose`. + +:mps:tag:`flush.cover` The buffer needs covering whether it was being used +for forwarding or not. See :mps:ref:`.flush.expose`. + + +.. c:function:: Res AMCBufferFill(Addr *baseReturn, Addr *limitReturn, Pool pool, Buffer buffer, Size size, Bool withReservoirPermit) + +:mps:tag:`fill` Reserve was called on an allocation buffer which was reset, +or there wasn't enough room left in the buffer. Allocate a group for +the new object and attach it to the buffer. + +:mps:tag:`fill.expose` If the buffer is being used for forwarding it may be +exposed, in which case the group attached to it should be exposed. See +:mps:ref:`.flush.cover`. + + +.. c:function:: Res AMCFix(Pool pool, ScanState ss, Seg seg, Ref *refIO) + +:mps:tag:`fix` Fix a reference to the pool. + +Ambiguous references lock down an entire segment by removing it +from old-space and also marking it grey for future scanning. + +Exact, final, and weak references are merged because the action for an +already forwarded object is the same in each case. After that +situation is checked for, the code diverges. + +Weak references are either snapped out or replaced with +``ss->weakSplat`` as appropriate. + +Exact and final references cause the referenced object to be copied to +new-space and the old copy to be forwarded (broken-heart installed) so +that future references are fixed up to point at the new copy. + +:mps:tag:`fix.exact.expose` In order to allocate the new copy the forwarding +buffer must be exposed. This might be done more efficiently outside +the entire scan, since it's likely to happen a lot. + +:mps:tag:`fix.exact.grey` The new copy must be at least as grey as the old +as it may have been grey for some other collection. + + +.. c:function:: Res AMCScan(Bool *totalReturn, ScanState ss, Pool pool, Seg seg) + +:mps:tag:`scan` Searches for a group which is grey for the trace and scans +it. If there aren't any, it sets the finished flag to true. + + +.. c:function:: void AMCReclaim(Pool pool, Trace trace, Seg seg) + +:mps:tag:`reclaim` After a trace, destroy any groups which are still +condemned for the trace, because they must be dead. + +:mps:tag:`reclaim.grey` Note that this might delete things which are grey +for other collections. This is OK, because we have conclusively proved +that they are dead -- the other collection must have assumed they were +alive. There might be a problem with the accounting of grey groups, +however. + +:mps:tag:`reclaim.buf` If a condemned group still has a buffer attached, we +can't destroy it, even though we know that there are no live objects +there. Even the object the mutator is allocating is dead, because the +buffer is tripped. + + diff --git a/mps/manual/html/_sources/design/poolams.txt b/mps/manual/html/_sources/design/poolams.txt new file mode 100644 index 00000000000..7bd64320d64 --- /dev/null +++ b/mps/manual/html/_sources/design/poolams.txt @@ -0,0 +1,465 @@ +.. _design-poolams: + + +.. index:: + pair: AMS pool class; design + single: pool class; AMS design + + +AMS pool class +============== + +.. mps:prefix:: design.mps.poolams + pair: AMS pool class; design + single: pool class; AMS design + + +Introduction +------------ + +:mps:tag:`intro` This is the design of the AMS pool class. + +:mps:tag:`readership` MM developers. + +:mps:tag:`source` design.mps.buffer, design.mps.trace, design.mps.scan, +design.mps.action and design.mps.class-interface [none of these were +actually used -- pekka 1998-04-21]. No requirements doc [we need a +req.mps that captures the commonalities between the products -- pekka +1998-01-27]. + + +Overview +-------- + +:mps:tag:`overview` This document describes the design of the AMS (Automatic +Mark-and-Sweep) pool class. The AMS pool is a proof-of-concept design +for a mark-sweep pool in the MPS. It's not meant to be efficient, but +it could serve as a model for an implementation of a more advanced +pool (such as EPVM). + + +Requirements +------------ + +:mps:tag:`req.mark-sweep` The pool must use a mark-and-sweep GC algorithm. + +:mps:tag:`req.colour` The colour representation should be as efficient as +possible. + +:mps:tag:`req.incremental` The pool must support incremental GC. + +:mps:tag:`req.ambiguous` The pool must support ambiguous references to +objects in it (but ambiguous references into the middle of an object +do not preserve the object). + +:mps:tag:`req.format` The pool must be formatted, for generality. + +:mps:tag:`req.correct` The design and the implementation should be simple +enough to be seen to be correct. + +:mps:tag:`req.simple` Features not related to mark-and-sweep GC should +initially be implemented as simply as possible, in order to save +development effort. + +:mps:tag:`not-req.grey` We haven't figured out how buffers ought to work +with a grey mutator, so we use :mps:ref:`.req.correct` to allow us to design a +pool that doesn't work in that phase. This is acceptable as long as we +haven't actually implemented grey mutator collection. + + +Architecture +------------ + +Subclassing +........... + +:mps:tag:`subclass` Since we expect to have many mark-and-sweep pools, we +build in some protocol for subclasses to modify various aspects of the +behaviour. Notably there's a subclassable segment class, and a +protocol for performing iteration. + + +Allocation +.......... + +:mps:tag:`align` We divide the segments in grains, each the size of the +format alignment. :mps:tag:`alloc-bit-table` We keep track of allocated +grains using a bit table. This allows a simple implementation of +allocation and freeing using the bit table operators, satisfying +:mps:ref:`.req.simple`, and can simplify the GC routines. Eventually, this +should use some sophisticated allocation technique suitable for +non-moving automatic pools. + +:mps:tag:`buffer` We use buffered allocation, satisfying +:mps:ref:`.req.incremental`. The AMC buffer technique is reused, although it +is not suitable for non-moving pools, but req.simple allows us to do +that for now. + +:mps:tag:`extend` If there's no space in any existing segment, a new segment +is allocated. The actual class is allowed to decide the size of the +new segment. + +:mps:tag:`no-alloc` Do not support :c:func:`PoolAlloc()`, because we can't support +one-phase allocation for a scannable pool (unless we disallow +incremental collection). For exact details, see design.mps.buffer. + +:mps:tag:`no-free` Do not support :c:func:`PoolFree()`, because automatic pools +don't need explicit free and having it encourages clients to use it +(and therefore to have dangling pointers, double frees, and other +memory management errors.) + + +Colours +....... + +:mps:tag:`colour` Objects in a segment which is *not* condemned (for some +trace) take their colour (for this trace) from the segment. + +:mps:tag:`colour.object` Since we need to implement a non-copying GC, we +keep track of the colour of each object in a condemned segment +separately. For this, we use bit tables with a bit for each grain. +This format is fast to access, has better locality than mark bits in +the objects themselves, and allows cheap interoperation with the +allocation bit table. + +:mps:tag:`colour.encoding` As to the details, we follow +analysis.non-moving-colour(3), implementing both the alloc-white +sharing option described in +analysis.non-moving-colour.constraint.reclaim.white-free-bit and the +vanilla three-table option, because the former cannot work with +interior pointers. However, the colour encoding in both is the same. + +:mps:tag:`ambiguous.middle` We will allow ambiguous references into the +middle of an object (as required by :mps:ref:`.req.ambiguous`), using the +trick in analysis.non-moving-colour.interior.ambiguous-only to speed +up scanning. + +:mps:tag:`interior-pointer` Note that non-ambiguous interior pointers are +outlawed. + +:mps:tag:`colour.alloc` Objects are allocated black. This is the most +efficient alternative for traces in the black mutator phase, and +.not-req.grey means that's sufficient. + +.. note:: + + Some day, we need to think about allocating grey or white during + the grey mutator phase. + + +Scanning +........ + +:mps:tag:`scan.segment` The tracer protocol requires (for segment barrier +hits) that there is a method for scanning a segment and turning all +grey objects on it black. This cannot be achieved with a single +sequential sweep over the segment, since objects that the sweep has +already passed may become grey as later objects are scanned. + +:mps:tag:`scan.graph` For a non-moving GC, it is more efficient to trace +along the reference graph than segment by segment. It also allows +passing type information from fix to scan. Currently, the tracer +doesn't offer this option when it's polling for work. + +:mps:tag:`scan.stack` Tracing along the reference graph cannot be done by +recursive descent, because we can't guarantee that the stack won't +overflow. We can, however, maintain an explicit stack of things to +trace, and fall back on iterative methods (:mps:ref:`.scan.iter`) when it +overflows and can't be extended. + +:mps:tag:`scan.iter` As discussed in :mps:ref:`.scan.segment`, when scanning a +segment, we need to ensure that there are no grey objects in the +segment when the scan method returns. We can do this by iterating a +sequential scan over the segment until nothing is grey (see +:mps:ref:`.marked.scan` for details). + +:mps:tag:`scan.iter.only` Some iterative method is needed as a fallback for +the more advanced methods, and as this is the simplest way of +implementing the current tracer protocol, we will start by +implementing it as the only scanning method. + +:mps:tag:`scan.buffer` We do not scan between ScanLimit and Limit of a +buffer (see :mps:ref:`.iteration.buffer`), as usual. + +.. note:: + + design.mps.buffer should explain why this works, but doesn't. + Pekka P. Pirinen, 1998-02-11. + +:mps:tag:`fix.to-black` When fixing a reference to a white object, if the +segment does not refer to the white set, the object cannot refer to +the white set, and can therefore be marked as black immediately +(rather than grey). + + +Implementation +-------------- + +Colour +...... + +:mps:tag:`colour.determine` Following the plan in :mps:ref:`.colour`, if +``SegWhite(seg)`` includes the trace, the colour of an object is given +by the bit tables. Otherwise if ``SegGrey(seg)`` includes the trace, +all the objects are grey. Otherwise all the objects are black. + +:mps:tag:`colour.bits` As we only have searches for runs of zero bits, we use +two bit tables, the non-grey and non-white tables, but this is hidden +beneath a layer of macros talking about grey and white in positive +terms. + +:mps:tag:`colour.single` We have only implemented a single set of mark and +scan tables, so we can only condemn a segment for one trace at a time. +This is checked for in condemnation. If we want to do overlapping +white sets, each trace needs its own set of tables. + +:mps:tag:`colour.check` The grey-and-non-white state is illegal, and free +objects must be white as explained in +analysis.non-moving-colour.contraint.reclaim. + + +Iteration +......... + +:mps:tag:`iteration` Scan, reclaim and other operations need to iterate over +all objects in a segment. We abstract this into a single iteration +function, even though we no longer use it for reclaiming and rarely +for scanning. + +:mps:tag:`iteration.buffer` Iteration skips directly from ScanLimit to Limit +of a buffer. This is because this area may contain +partially-initialized and uninitialized data, which cannot be +processed. Since the iteration skips the buffer, callers need to take +the appropriate action, if any, on it. + +.. note:: + + ScanLimit is used for reasons which are not documented in + design.mps.buffer. + + +Scanning Algorithm +.................. + +:mps:tag:`marked` Each segment has a ``marksChanged`` flag, indicating +whether anything in it has been made grey since the last scan +iteration (:mps:ref:`.scan.iter`) started. This flag only concerns the colour +of objects with respect to the trace for which the segment is +condemned, as this is the only trace for which objects in the segment +are being made grey by fixing. Note that this flag doesn't imply that +there are grey objects in the segment, because the grey objects might +have been subsequently scanned and blackened. + +:mps:tag:`marked.fix` The ``marksChanged`` flag is set :c:macro:`TRUE` by +:c:func:`AMSFix()` when an object is made grey. + +:mps:tag:`marked.scan` :c:func:`AMSScan()` must blacken all grey objects on the +segment, so it must iterate over the segment until all grey objects +have been seen. Scanning an object in the segment might grey another +one (:mps:ref:`.marked.fix`), so the scanner iterates until this flag is +:c:macro:`FALSE`, setting it to :c:macro:`FALSE` before each scan. It is safe to +scan the segment even if it contains nothing grey. + +:mps:tag:`marked.scan.fail` If the format scanner returns failure (see +protocol.mps.scanning), we abort the scan in the middle of a segment. +So in this case the marksChanged flag is set back to TRUE, because we +may not have blackened all grey objects. + +.. note:: + + Is that the best reference for the format scanner? + +:mps:tag:`marked.unused` The ``marksChanged`` flag is meaningless unless the +segment is condemned. We make it :c:macro:`FALSE` in these circumstances. + +:mps:tag:`marked.condemn` Condemnation makes all objects in a segment either +black or white, leaving nothing grey, so it doesn't need to set the +``marksChanged`` flag which must already be :c:macro:`FALSE`. + +:mps:tag:`marked.reclaim` When a segment is reclaimed, it can contain +nothing marked as grey, so the ``marksChanged`` flag must already be +:c:macro:`FALSE`. + +:mps:tag:`marked.blacken` When the tracer decides not to scan, but to call +:c:func:`PoolBlacken()`, we know that any greyness can be removed. +:c:func:`AMSBlacken()` does this and resets the ``marksChanged`` flag, if it +finds that the segment has been condemned. + +:mps:tag:`marked.clever` AMS could be clever about not setting the +``marksChanged`` flag, if the fixed object is ahead of the current +scan pointer. It could also keep low- and high-water marks of grey +objects, but we don't need to implement these improvements at first. + + +Allocation +.......... + +:mps:tag:`buffer-init` We take one init arg to set the Rank on the buffer, +just to see how it's done. + +:mps:tag:`no-bit` As an optimization, we won't use the alloc bit table until +the first reclaim on the segment. Before that, we just keep a +high-water mark. + +:mps:tag:`fill` :c:func:`AMSBufferFill()` takes the simplest approach: it iterates +over the segments in the pool, looking for one which can be used to +refill the buffer. + +:mps:tag:`fill.colour` The objects allocated from the new buffer must be +black for all traces (:mps:ref:`.colour.alloc`), so putting it on a black +segment (meaning one where neither ``SegWhite(seg)`` nor +``SegGrey(seg)`` include the trace, see :mps:ref:`.colour.determine`) is +obviously OK. White segments (where ``SegWhite(seg)`` includes the +trace) are also fine, as we can use the colour tables to make it +black. At first glance, it seems we can't put it on a segment that is +grey but not white for some trace (one where ``SegWhite(seg)`` doesn't +include the trace, but ``SegGrey(seg)`` does), because the new objects +would become grey as the buffer's ScanLimit advanced. However, in many +configurations, the mutator would hit a barrier as soon as it started +initializing the object, which would flip the buffer. In fact, the +current (2002-01) implementation of buffers assumes buffers are black, +so they'd better. + +:mps:tag:`fill.colour.reclaim` In fact, putting a buffer on a condemned +segment will screw up the accounting in :c:func:`AMCReclaim()`, so it's +disallowed. + +:mps:tag:`fill.slow` :c:func:`AMSBufferFill()` gets progressively slower as more +segments fill up, as it laboriously checks whether the buffer can be +refilled from each segment, by inspecting the allocation bit map. This +is helped a bit by keeping count of free grains in each segment, but +it still spends a lot of time iterating over all the full segments +checking the free size. Obviously, this can be much improved (we could +keep track of the largest free block in the segment and in the pool, +or we could keep the segments in some more efficient structure, or we +could have a real free list structure). + +:mps:tag:`fill.extend` If there's no space in any existing segment, the +``segSize`` method is called to decide the size of the new segment to +allocate. If that fails, the code tries to allocate a segment that's +just large enough to satisfy the request. + +:mps:tag:`empty` :c:func:`AMSBufferEmpty()` makes the unused space free, since +there's no reason not to. We have to adjust the colour tables as well, +since these grains were black and now they need to be white (or at +least encoded -G and W). + +:mps:tag:`reclaim.empty.buffer` Segments which after reclaim only contain a +buffer could be destroyed by trapping the buffer, but there's no point +to this. + + +Initialization +.............. + +:mps:tag:`init` The initialization method :c:func:`AMSInit()` takes three +additional arguments: the format of objects allocated in the pool, the +chain that controls GC timing, and a flag for supporting ambiguous +references. + +:mps:tag:`init.share` If support for ambiguity is required, the +``shareAllocTable`` flag is reset to indicate the pool uses three +separate bit tables, otherwise it is set and the pool shares a table +for non-white and alloc (see :mps:ref:`.colour.encoding`). + +:mps:tag:`init.align` The pool alignment is set equal to the format +alignment (see design.mps.align). + +:mps:tag:`init.internal` Subclasses call :c:func:`AMSInitInternal()` to avoid the +problems of sharing ``va_list`` and emitting a superfluous +``PoolInitAMS`` event. + + +Condemnation +............ + +:mps:tag:`condemn.buffer` Buffers are not condemned, instead they are +coloured black, to make sure that the objects allocated will be black, +following :mps:ref:`.colour.alloc` (or, if you wish, because buffers are +ignored like free space, so need the same encoding). + + +Reclaim +....... + +:mps:tag:`reclaim` Reclaim uses either of analysis.non-moving-colour +.constraint.reclaim.white-free-bit (just reuse the non-white table as +the alloc table) or +analysis.non-moving-colour.constraint.reclaim.free-bit (copy it), +depending on the shareAllocTable flag (as set by :mps:ref:`.init.share`). +However, bit table still has to be iterated over to count the free +grains. Also, in a debug pool, each white block has to be splatted. + + +Segment merging and splitting +............................. + +:mps:tag:`split-merge` We provide methods for splitting and merging AMS +segments. The pool implementation doesn't cause segments to be split +or merged -- but a subclass might want to do this (see +:mps:ref:`.stress.split-merge`). The methods serve as an example of how to +implement this facility. + +:mps:tag:`split-merge.constrain` There are some additional constraints on +what segments may be split or merged: + +- :mps:tag:`split-merge.constrain.align` Segments may only be split or + merged at an address which is aligned to the pool alignment as well + as to the arena alignment. + + :mps:tag:`split-merge.constrain.align.justify` This constraint is implied + by the design of allocation and colour tables, which cannot + represent segments starting at unaligned addresses. The constraint + only arises if the pool alignment is larger than the arena + alignment. There's no requirement to split segments at unaligned + addresses. + +- :mps:tag:`split-merge.constrain.empty` The higher segment must be empty. + That is, the higher segment passed to :c:func:`SegMerge()` must be empty, + and the higher segment returned by :c:func:`SegSplit()` must be empty. + + :mps:tag:`split-merge.constrain.empty.justify` This constraint makes the + code significantly simpler. There's no requirement for a more + complex solution at the moment (as the purpose is primarily + pedagogic). + +:mps:tag:`split-merge.fail` The split and merge methods are not proper +anti-methods for each other (see +design.mps.seg.split-merge.fail.anti.no). Methods will not reverse the +side-effects of their counterparts if the allocation of the colour and +allocation bit tables should fail. Client methods which over-ride +split and merge should not be written in such a way that they might +detect failure after calling the next method, unless they have reason +to know that the bit table allocations will not fail. + + +Testing +------- + +:mps:tag:`stress` There's a stress test, MMsrc!amsss.c, that does 800 kB of +allocation, enough for about three GCs. It uses a modified Dylan +format, and checks for corruption by the GC. Both ambiguous and exact +roots are tested. + +:mps:tag:`stress.split-merge` There's also a stress test for segment +splitting and merging, MMsrc!segsmss.c. This is similar to amsss.c -- +but it defines a subclass of AMS, and causes segments to be split and +merged. Both buffered and non-buffered segments are split / merged. + + +Notes +----- + +:mps:tag:`addr-index.slow` Translating from an address to and from a grain +index in a segment uses macros such as :c:macro:`AMS_INDEX` and +:c:macro:`AMS_INDEX_ADDR`. These are slow because they call :c:func:`SegBase()` on +every translation -- we could cache that. + +:mps:tag:`grey-mutator` To enforce the restriction set in :mps:ref:`.not-req.grey` +we check that all the traces are flipped in :c:func:`AMSScan()`. It would be +good to check in :c:func:`AMSFix()` as well, but we can't do that, because +it's called during the flip, and we can't tell the difference between +the flip and the grey mutator phases with the current tracer +interface. + + diff --git a/mps/manual/html/_sources/design/poolawl.txt b/mps/manual/html/_sources/design/poolawl.txt new file mode 100644 index 00000000000..fa75673dc27 --- /dev/null +++ b/mps/manual/html/_sources/design/poolawl.txt @@ -0,0 +1,539 @@ +.. _design-poolawl: + + +.. index:: + pair: AWL pool class; design + single: pool class; AWL design + + +AWL pool class +============== + +.. mps:prefix:: design.mps.poolawl + pair: AWL pool class; design + single: pool class; AWL design + + +Introduction +------------ + +:mps:tag:`readership` Any MPS developer. + +:mps:tag:`intro` The AWL (Automatic Weak Linked) pool is used to manage +Dylan Weak Tables (see req.dylan.fun.weak). Currently the design is +specialised for Dylan Weak Tables, but it could be generalised in the +future. + + +Requirements +------------ + +See req.dylan.fun.weak. + +See meeting.dylan.1997-02-27(0) where many of the requirements for +this pool were first sorted out. + +Must satisfy request.dylan.170123. + +:mps:tag:`req.obj-format` Only objects of a certain format need be +supported. This format is a subset of the Dylan Object Format. The +pool uses the first slot in the fixed part of an object to store an +association. See mail.drj.1997-03-11.12-05 + + +Definitions +----------- + +:mps:tag:`def.grain` alignment grain, grain. A grain is a range of addresses +where both the base and the limit of the range are aligned and the +size of range is equal to the (same) alignment. In this context the +alignment is the pool's alignment (``pool->alignment``). The grain is +the unit of allocation, marking, scanning, etc. + + +Overview +-------- + +:mps:tag:`overview` + +:mps:tag:`overview.ms` The pool is mark and sweep. :mps:tag:`overview.ms.justify` +Mark-sweep pools are slightly easier to write (than moving pools), and +there are no requirements (yet) that this pool be high performance or +moving or anything like that. + +:mps:tag:`overview.alloc` It is possible to allocate weak or exact objects +using the normal reserve/commit AP protocol. +:mps:tag:`overview.alloc.justify` Allocation of both weak and exact objects +is required to implement Dylan Weak Tables. Objects are formatted; the +pool uses format A. + +:mps:tag:`overview.scan` The pool handles the scanning of weak objects +specially so that when a weak reference is deleted the corresponding +reference in an associated object is deleted. The associated object is +determined by using information stored in the object itself (see +:mps:ref:`.req.obj-format`). + + +Interface +--------- + +:mps:tag:`if.init` The init method takes one extra parameter in the vararg +list. This parameter should have type :c:type:`Format` and be a format +object that describes the format of the objects to be allocated in +this pool. The format should support scan and skip methods. There is +an additional restriction on the layout of objects, see +:mps:ref:`.req.obj-format`. + +:mps:tag:`if.buffer` The :c:func:`BufferInit()` method takes one extra parameter +in the vararg list. This parameter should be either ``RankEXACT`` or +``RankWEAK``. It determines the rank of the objects allocated using +that buffer. + + +Data structures +--------------- + +:mps:tag:`sig` This signature for this pool will be 0x519bla3l (SIGPooLAWL). + +:mps:tag:`poolstruct` The class specific pool structure is:: + + struct AWLStruct { + PoolStruct poolStruct; + Format format; + Shift alignShift; + ActionStruct actionStruct; + double lastCollected; + Serial gen; + Sig sig; + } + +:mps:tag:`poolstruct.format` The format field is used to refer to the object +format. The object format is passed to the pool during pool creation. + +:mps:tag:`poolstruct.alignshift` The ``alignShift`` field is the +``SizeLog2`` of the pool's alignment. It is computed and initialised +when a pool is created. It is used to compute the number of alignment +grains in a segment which is the number of bits need in the segment's +mark and alloc bit table (see :mps:ref:`.awlseg.bt`, :mps:ref:`.awlseg.mark`, and +:mps:ref:`.awlseg.alloc` below). + +.. note:: + + Clarify this. + +:mps:tag:`poolstruct.actionStruct` Contains an Action which is used to +participate in the collection benefit protocol. See :c:func:`AWLBenefit()` +below for a description of the algorithm used for determining when to +collect. + +:mps:tag:`poolstruct.lastCollected` Records the time (using the mutator +total allocation clock, ie that returned by +:c:func:`ArenaMutatorAllocSize()`) of the most recent call to either +:c:func:`AWLInit()` or :c:func:`AWLTraceBegin()` for this pool. So this is the +time of the beginning of the last collection of this pool. Actually +this isn't true because the pool can be collected without +:c:func:`AWLTraceBegin()` being called (I think) as it will get collected by +being in the same zone as another pool/generation that is being +collected (which it does arrange to be, see the use of the gen field +in :mps:ref:`.poolstruct.gen` below and :mps:ref:`.fun.awlsegcreate.where` below). + +:mps:tag:`poolstruct.gen` This part of the mechanism by which the pool +arranges to be in a particular zone and arranges to be collected +simultaneously with other cohorts in the system. ``gen`` is the +generation that is used in expressing a generation preference when +allocating a segment. The intention is that this pool will get +collected simultaneously with any other segments that are also +allocated using this generation preference (when using the VM arena, +generation preferences get mapped more or less to zones, each +generation to a unique set of zones in the ideal case). Whilst AWL is +not generational it is expected that this mechanism will arrange for +it to be collected simultaneously with some particular generation of +AMC. + +:mps:tag:`poolstruct.gen.1` At the moment the ``gen`` field is set for all +AWL pools to be 1. + +:mps:tag:`awlseg` The pool defines a segment class :c:type:`AWLSegClass`, which is +a subclass of :c:type:`GCSegClass` (see +design.mps.seg.over.hierarchy.gcseg). All segments allocated by the +pool are instances of this class, and are of type ``AWLSeg``, for +which the structure is:: + + struct AWLSegStruct { + GCSegStruct gcSegStruct; + BT mark; + BT scanned; + BT alloc; + Count grains; + Count free; + Count singleAccesses; + AWLStatSegStruct stats; + Sig sig; + } + +:mps:tag:`awlseg.bt` The mark, alloc, and scanned fields are bit-tables (see +design.mps.bt). Each bit in the table corresponds to a a single +alignment grain in the pool. + +:mps:tag:`awlseg.mark` The mark bit table is used to record mark bits during +a trace. :c:func:`AWLCondemn()` (see :mps:ref:`.fun.condemn` below) sets all the +bits of this table to zero. Fix will read and set bits in this table. +Currently there is only one mark bit table. This means that the pool +can only be condemned for one trace. + +:mps:tag:`awlseg.mark.justify` This is simple, and can be improved later +when we want to run more than one trace. + +:mps:tag:`awlseg.scanned` The scanned bit-table is used to note which +objects have been scanned. Scanning (see :mps:ref:`.fun.scan` below) a segment +will find objects that are marked but not scanned, scan each object +found and set the corresponding bits in the scanned table. + +:mps:tag:`awlseg.alloc` The alloc bit table is used to record which portions +of a segment have been allocated. Ranges of bits in this table are set +when a buffer is attached to the segment. When a buffer is flushed (ie +:c:func:`AWLBufferEmpty()` is called) from the segment, the bits +corresponding to the unused portion at the end of the buffer are +reset. + +:mps:tag:`awlseg.alloc.invariant` A bit is set in the alloc table if and +only if the corresponding address is currently being buffered, or the +corresponding address lies within the range of an allocated object. + +:mps:tag:`awlseg.grains` The grains field is the number of grains that fit +in the segment. Strictly speaking this is not necessary as it can be +computed from ``SegSize`` and AWL's alignment, however, precalculating +it and storing it in the segment makes the code simpler by avoiding +lots of repeated calculations. + +:mps:tag:`awlseg.free` A conservative estimate of the number of free grains +in the segment. It is always guaranteed to be greater than or equal to +the number of free grains in the segment, hence can be used during +allocation to quickly pass over a segment. + +.. note:: + + Maintained by blah and blah. Unfinished obviously. + + +Functions +--------- + +.. note:: + + How will pool collect? It needs an action structure. + +External +........ + +.. c:function:: Res AWLInit(Pool pool, va_list arg) + +:mps:tag:`fun.init` :c:type:`AWLStruct` has four fields, each one needs initializing. + +:mps:tag:`fun.init.poolstruct` The ``poolStruct`` field has already been +initialized by generic code (impl.c.pool). + +:mps:tag:`fun.init.format` The format will be copied from the argument list, +checked, and written into this field. + +:mps:tag:`fun.init.alignshift` The ``alignShift`` will be computed from the +pool alignment and written into this field. + +:mps:tag:`fun.init.sig` The ``sig`` field will be initialized with the +signature for this pool. + +.. c:function:: Res AWLFinish(Pool pool) + +:mps:tag:`fun.finish` Iterates over all segments in the pool and destroys +each segment (by calling :c:func:`SegFree()`). Overwrites the sig field in +the :c:type:`AWLStruct`. Finishing the generic pool structure is done by the +generic pool code (impl.c.pool). + +:mps:tag:`fun.alloc` :c:func:`PoolNoAlloc()` will be used, as this class does not +implement alloc. + +:mps:tag:`fun.free` :c:func:`PoolNoFree()` will be used, as this class does not +implement free. + +.. c:function:: Res AWLBufferFill(Seg *segReturn, Addr *baseReturn, Pool pool, Buffer buffer, Size size) + +:mps:tag:`fun.fill` This zips round all the the segments applying +:c:func:`AWLSegAlloc()` to each segment that has the same rank as the +buffer. :c:func:`AWLSegAlloc()` attempts to find a free range, if it finds a +range then it may be bigger than the actual request, in which case the +remainder can be used to "fill" the rest of the buffer. If no free +range can be found in an existing segment then a new segment will be +created (which is at least large enough). The range of buffered +addresses is marked as allocated in the segment's alloc table. + +.. c:function:: void AWLBufferEmpty(Pool pool, Buffer buffer) + +:mps:tag:`fun.empty` Locates the free portion of the buffer, that is the +memory between the init and the limit of the buffer and records these +locations as being free in the relevant alloc table. The segment that +the buffer is pointing at (which contains the alloc table that needs +to be dinked with) is available via :c:func:`BufferSeg()`. + +:mps:tag:`fun.benefit` The benefit returned is the total amount of mutator +allocation minus the ``lastRembemberedSize`` minus 10 MiB, so the pool +becomes an increasingly good candidate for collection at a constant +(mutator allocation) rate, crossing the 0 line when there has been +10 MiB of allocation since the (beginning of the) last collection. So +it gets collected approximately every 10 MiB of allocation. Note that +it will also get collected by virtue of being in the same zone as some +AMC generation (assuming there are instantiated AMC pools), see +:mps:ref:`.poolstruct.gen` above. + +.. c:function:: Res AWLCondemn(Pool pool, Trace trace, Seg seg) + +:mps:tag:`fun.condemn` The current design only permits each segment to be +condemned for one trace (see :mps:ref:`.awlseg.mark`). This function checks +that the segment is not condemned for any trace (``seg->white == +TraceSetEMPTY``). The segment's mark bit-table is reset, and the +whiteness of the seg (``seg->white``) has the current trace added to +it. + +.. c:function:: void AWLGrey(Pool pool, Trace trace, Seg seg) + +:mps:tag:`fun.grey` If the segment is not condemned for this trace the +segment's mark table is set to all 1s and the segment is recorded as +being grey. + +.. c:function:: Res AWLScan(ScanState ss, Pool pool, Seg seg) + +:mps:tag:`fun.scan` + +:mps:tag:`fun.scan.overview` The scanner performs a number of passes over +the segment, scanning each marked and unscanned (grey) object that is +finds. + +:mps:tag:`fun.scan.overview.finish` It keeps perform a pass over the segment +until it is finished. + +:mps:tag:`fun.scan.overview.finish.condition` A condition for finishing is +that no new marks got placed on objects in this segment during the +pass. + +:mps:tag:`fun.scan.overview.finish.approximation` We use an even stronger +condition for finishing that assumes that scanning any object may +introduce marks onto this segment. It is finished when a pass results +in scanning no objects (that is, all objects were either unmarked or +both marked and scanned). + +:mps:tag:`fun.scan.overview.finished-flag` There is a flag called +``finished`` which keeps track of whether we should finish or not. We +only ever finish at the end of a pass. At the beginning of a pass the +flag is set. During a pass if any objects are scanned then the +``finished`` flag is reset. At the end of a pass if the ``finished`` +flag is still set then we are finished. No more passes take place and +the function returns. + +:mps:tag:`fun.scan.pass` A pass consists of a setup phase and a repeated +phase. + +:mps:tag:`fun.scan.pass.buffer` The following assumes that in the general +case the segment is buffered; if the segment is not buffered then the +actions that mention buffers are not taken (they are unimportant if +the segment is not buffered). + +:mps:tag:`fun.scan.pass.p` The pass uses a cursor called ``p`` to progress +over the segment. During a pass ``p`` will increase from the base +address of the segment to the limit address of the segment. When ``p`` +reaches the limit address of the segment, the pass in complete. + +:mps:tag:`fun.scan.pass.setup` ``p`` initially points to the base address of +the segment. + +:mps:tag:`fun.scan.pass.repeat` The following comprises the repeated phase. +The repeated phase is repeated until the pass completion condition is +true (that is, ``p`` has reached the limit of the segment, see +:mps:ref:`.fun.scan.pass.p` above and :mps:ref:`.fun.scan.pass.repeat.complete` +below). + +:mps:tag:`fun.scan.pass.repeat.complete` If ``p`` is equal to the segment's +limit then we are done. We proceed to check whether any further passes +need to be performed (see :mps:ref:`.fun.scan.pass.more` below). + +:mps:tag:`fun.scan.pass.repeat.free` If ``!alloc(p)`` (the grain is free) +then increment ``p`` and return to the beginning of the loop. + +:mps:tag:`fun.scan.pass.repeat.buffer` If ``p`` is equal to the buffer's +ScanLimit, as returned by :c:func:`BufferScanLimit()`, then set ``p`` equal +to the buffer's Limit, as returned by :c:func:`BufferLimit()` and return to +the beginning of the loop. + +:mps:tag:`fun.scan.pass.repeat.object-end` The end of the object is located +using the ``format->skip`` method. + +:mps:tag:`fun.scan.pass.repeat.object` if ``mark(p) && !scanned(p)`` then +the object pointed at is marked but not scanned, which means we must +scan it, otherwise we must skip it. + +:mps:tag:`fun.scan.pass.repeat.object.dependent` To scan the object the +object we first have to determine if the object has a dependent object (see +:mps:ref:`.req.obj-format`). + +:mps:tag:`fun.scan.pass.repeat.object.dependent.expose` If it has a +dependent object then we must expose the segment that the dependent +object is on (only if the dependent object actually points to MPS +managed memory) prior to scanning and cover the segment subsequent to +scanning. + +:mps:tag:`fun.scan.pass.repeat.object.dependent.summary` The summary of the +dependent segment must be set to ``RefSetUNIV`` to reflect the fact +that we are allowing it to be written to (and we don't know what gets +written to the segment). + +:mps:tag:`fun.scan.pass.repeat.object.scan` The object is then scanned by +calling the format's scan method with base and limit set to the +beginning and end of the object (:mps:tag:`fun.scan.scan.improve.single` A +scan1 format method would make it slightly simpler here). Then the +finished flag is cleared and the bit in the segment's scanned table is +set. + +:mps:tag:`fun.scan.pass.repeat.advance` ``p`` is advanced past the object +and we return to the beginning of the loop. + +:mps:tag:`fun.scan.pass.more` At the end of a pass the finished flag is +examined. + +:mps:tag:`fun.scan.pass.more.not` If the finished flag is set then we are +done (see :mps:ref:`.fun.scan.overview.finished-flag` above), :c:func:`AWLScan()` +returns. + +:mps:tag:`fun.scan.pass.more.so` Otherwise (the finished flag is reset) we +perform another pass (see :mps:ref:`.fun.scan.pass` above). + +.. c:function:: Res AWLFix(Pool pool, ScanState ss, Seg seg, Ref *refIO) + +:mps:tag:`fun.fix` ``ss->wasMarked`` is set to :c:macro:`TRUE` (clear compliance +with design.mps.fix.protocol.was-marked.conservative). + +If the rank (``ss->rank``) is ``RankAMBIG`` then fix returns +immediately unless the reference is aligned to the pool alignment. + +If the rank (``ss->rank``) is ``RankAMBIG`` then fix returns +immediately unless the referenced grain is allocated. + +The bit in the marked table corresponding to the referenced grain will +be read. If it is already marked then fix returns. Otherwise (the +grain is unmarked), ``ss->wasMarked`` is set to :c:macro:`FALSE`, the +remaining actions depend on whether the rank (``ss->rank``) is +``RankWEAK`` or not. If the rank is weak then the reference is +adjusted to 0 (see design.mps.weakness) and fix returns. If the rank +is something else then the mark bit corresponding to the referenced +grain is set, and the segment is greyed using :c:func:`TraceSegGreyen()`. + +Fix returns. + + +.. c:function:: void AWLReclaim(Pool pool, Trace trace, Seg seg) + +:mps:tag:`fun.reclaim` This iterates over all allocated objects in the +segment and frees objects that are not marked. When this iteration is +complete the marked array is completely reset. + +``p`` points to base of segment. Then:: + + while(p < SegLimit(seg) { + if(!alloc(p)) { ++p;continue; } + q = skip(p) /* q points to just past the object pointed at by p */ + if !marked(p) free(p, q); /* reset the bits in the alloc table from p to q-1 inclusive. */ + p = q + } + +Finally, reset the entire marked array using :c:func:`BTResRange()`. + +:mps:tag:`fun.reclaim.improve.pad` Consider filling free ranges with padding +objects. Now reclaim doesn't need to check that the objects are +allocated before skipping them. There may be a corresponding change +for scan as well. + +.. c:function:: Res AWLDescribe(Pool pool, mps_lib_FILE *stream) + +:mps:tag:`fun.describe` + + +Internal +........ + +.. c:function:: Res AWLSegCreate(AWLSeg *awlsegReturn, Size size) + +:mps:tag:`fun.awlsegcreate` Creates a segment of class :c:type:`AWLSegClass` of size at least ``size``. + +:mps:tag:`fun.awlsegcreate.size.round` ``size`` is rounded up to an +``ArenaAlign`` before requesting the segment. +:mps:tag:`fun.awlsegcreate.size.round.justify` The arena requires that all +segment sizes are aligned to the ``ArenaAlign``. + +:mps:tag:`fun.awlsegcreate.where` The segment is allocated using a +generation preference, using the generation number stored in the +:c:type:`AWLStruct` (the ``gen`` field), see :mps:ref:`.poolstruct.gen` above. + +.. c:function:: Res awlSegInit(Seg seg, Pool pool, Addr base, Size size, Bool reservoirPermit, va_list args) + +:mps:tag:`fun.awlseginit` Init method for :c:type:`AWLSegClass`, called for +:c:func:`SegAlloc()` whenever an ``AWLSeg`` is created (see +:mps:ref:`.fun.awlsegcreate` above). + +:mps:tag:`fun.awlseginit.tables` The segment's mark scanned and alloc tables +(see :mps:ref:`.awlseg.bt` above) are allocated and initialised. The segment's +grains field is computed and stored. + +.. c:function:: void awlSegFinish(Seg seg) + +:mps:tag:`fun.awlsegfinish` Finish method for :c:type:`AWLSegClass`, called from +:c:func:`SegFree()`. Will free the segment's tables (see :mps:ref:`.awlseg.bt`). + +.. c:function:: Bool AWLSegAlloc(Addr *baseReturn, Addr *limitReturn, AWLSeg awlseg, AWL awl, Size size) + +:mps:tag:`fun.awlsegalloc` Will search for a free block in the segment that +is at least size bytes long. The base address of the block is returned +in ``*baseReturn``, the limit of the entire free block (which must be +at least as large size and may be bigger) is returned in +``*limitReturn``. The requested size is converted to a number of +grains, :c:func:`BTFindResRange()` is called to find a run of this length in +the alloc bit-table (:mps:ref:`.awlseg.alloc`). The return results (if it is +successful) from :c:func:`BTFindResRange()` are in terms of grains, they are +converted back to addresses before returning the relevant values from +this function. + +.. c:function:: Bool AWLDependentObject(Addr *objReturn, Addr parent) + +:mps:tag:`fun.dependent-object` This function abstracts the association +between an object and its linked dependent (see :mps:ref:`.req.obj-format`). +It currently assumes that objects are Dylan Object formatted according +to design.dylan.container (see analysis.mps.poolawl.dependent.abstract +for suggested improvements). An object has a dependent object iff the +second word of the object, that is, ``((Word *)parent)[1]``, is +non-:c:macro:`NULL`. The dependent object is the object referenced by the +second word and must be a valid object. + +This function assumes objects are in Dylan Object Format (see +design.dylan.container). It will check that the first word looks like +a Dylan wrapper pointer. It will check that the wrapper indicates that +the wrapper has a reasonable format (namely at least one fixed field). +If the second word is :c:macro:`NULL` it will return :c:macro:`FALSE`. If the second +word is non-:c:macro:`NULL` then the contents of it will be assigned to +``*objReturn``, and it will return :c:macro:`TRUE`. + + +Test +---- + +- must create Dylan objects. +- must create Dylan vectors with at least one fixed field. +- must allocate weak thingies. +- must allocate exact tables. +- must link tables together. +- must populate tables with junk. +- some junk must die. + +Use an LO pool and an AWL pool. Three buffers. One buffer for the LO +pool, one exact buffer for the AWL pool, one weak buffer for the AWL +pool. + +Initial test will allocate one object from each buffer and then +destroy all buffers and pools and exit + + diff --git a/mps/manual/html/_sources/design/poollo.txt b/mps/manual/html/_sources/design/poollo.txt new file mode 100644 index 00000000000..8a51b2ebb2f --- /dev/null +++ b/mps/manual/html/_sources/design/poollo.txt @@ -0,0 +1,249 @@ +.. _design-poollo: + + +.. index:: + pair: LO pool class; design + single: pool class; LO design + + +LO pool class +============= + +.. mps:prefix:: design.mps.poollo + pair: LO pool class; design + single: pool class; LO design + + +Introduction +------------ + +:mps:tag:`readership` Any MPS developer. + +:mps:tag:`intro` The LO (Leaf Object) pool class is a pool class developed +for DylanWorks. It is designed to manage objects that have no +references (leaf objects) such as strings, bit tables, etc. It is a +garbage collected pool (in that objects allocated in the pool are +automatically reclaimed when they are discovered to be unreachable. + +.. note:: + + Need to sort out issue of alignment. Currently lo grabs alignment + from format, almost certainly "ought" to use the greater of the + format alignment and the :c:macro:`MPS_ALIGN` value. David Jones, + 1997-07-02. + + +Definitions +----------- + +:mps:tag:`def.leaf` A "leaf" object is an object that contains no +references, or an object all of whose references refer to roots. That +is, any references that the object has must refer to a priori alive +objects that are guaranteed not to move, hence the references do not +need fixing. + +:mps:tag:`def.grain` A grain (of some alignment) is a contiguous aligned +area of memory of the smallest size possible (which is the same size +as the alignment). + + +Requirements +------------ + +:mps:tag:`req.source` See req.dylan.fun.obj.alloc and +req.dylan.prot.ffi.access. + +:mps:tag:`req.leaf` The pool must manage formatted leaf objects (see +:mps:ref:`.def.leaf` above for a definition). This is intended to encompass +Dylan and C leaf objects. Dylan leaf objects have a reference to their +wrapper, but are still leaf objects (in the sense of :mps:ref:`.def.leaf`) +because the wrapper will be a root. + +:mps:tag:`req.nofault` The memory containing objects managed by the pool +must not be protected. The client must be allowed to access these +objects without using the MPS trampoline (the exception mechanism, +q.v.). + + +Overview +-------- + +:mps:tag:`overview` + +:mps:tag:`overview.ms` The LO Pool is a non-moving mark-and-sweep collector. + +:mps:tag:`overview.ms.justify` Mark-and-sweep pools are simpler than moving +pools. + +:mps:tag:`overview.alloc` Objects are allocated in the pool using the +reserve/commit protocol on allocation points. + +:mps:tag:`overview.format` The pool is formatted. The format of the objects +in the pool is specified at instantiation time, using an format object +derived from a variant A format (using variant A is overkill, see +:mps:ref:`.if.init` below) (see design.mps.format for excuse about calling the +variant 'A'). + + +Interface +--------- + +:mps:tag:`if.init` + +:mps:tag:`if.init.args` The init method for this class takes one extra +parameter in the vararg parameter list. + +:mps:tag:`if.init.format` The extra parameter should be an object of type +Format and should describe the format of the objects that are to be +allocated in the pool. + +:mps:tag:`if.init.format.use` The pool uses the skip and alignment slots of +the format. The skip method is used to determine the length of objects +(during reclaim). The alignment field is used to determine the +granularity at which memory should be managed. + +:mps:tag:`if.init.format.a` Currently only format variant A is supported +though clearly that is overkill as only skip and alignment are used. + + +Data structures +--------------- + +:mps:tag:`sig` The signature for the LO Pool Class is 0x51970b07 +(SIGLOPOoL). + +:mps:tag:`poolstruct` The class specific pool structure is:: + + typedef struct LOStruct { + PoolStruct poolStruct; /* generic pool structure */ + Format format; /* format for allocated objects */ + Shift alignShift; + Sig sig; /* impl.h.misc.sig */ + } LOStruct; + +:mps:tag:`poolstruct.format` This is the format of the objects that are +allocated in the pool. + +:mps:tag:`poolstruct.alignShift` This is shift used in alignment +computations. It is ``SizeLog2(pool->alignment).`` It can be used on +the right of a shift operator (``<<`` or ``>>``) to convert between a +number of bytes and a number of grains. + +:mps:tag:`loseg` Every segment is an instance of segment class :c:type:`LOSegClass`, a +subclass of :c:type:`GCSegClass`, and is an object of type :c:type:`LOSegStruct`. + +:mps:tag:`loseg.purpose` The purpose of the ``LOSeg`` structure is to +associate the bit tables used for recording allocation and mark +information with the segment. + +:mps:tag:`loseg.decl` The declaration of the structure is as follows:: + + typedef struct LOSegStruct { + GCSegStruct gcSegStruct; /* superclass fields must come first */ + LO lo; /* owning LO */ + BT mark; /* mark bit table */ + BT alloc; /* alloc bit table */ + Count free; /* number of free grains */ + Sig sig; /* impl.h.misc.sig */ + } LOSegStruct; + +:mps:tag:`loseg.sig` The signature for a loseg is 0x519705E9 (SIGLOSEG). + +:mps:tag:`loseg.lo` The lo field points to the LO structure that owns this +segment. + +:mps:tag:`loseg.bit` Bit Tables (see design.mps.bt) are used to record +allocation and mark information. This is relatively straightforward, +but might be inefficient in terms of space in some circumstances. + +:mps:tag:`loseg.mark` This is a Bit Table that is used to mark objects +during a trace. Each grain in the segment is associated with 1 bit in +this table. When :c:func:`LOFix()` (see :mps:ref:`.fun.fix` below) is called the +address is converted to a grain within the segment and the +corresponding bit in this table is set. + +:mps:tag:`loseg.alloc` This is a Bit Table that is used to record which +addresses are allocated. Addresses that are allocated and are not +buffered have their corresponding bit in this table set. If a bit in +this table is reset then either the address is free or is being +buffered. + +:mps:tag:`loseg.diagram` The following diagram is now obsolete. It's also +not very interesting - but I've left the sources in case anyone ever +gets around to updating it. tony 1999-12-16 + +[missing diagram] + + +Functions +--------- + +External +........ + +:mps:tag:`fun.init` + +:mps:tag:`fun.destroy` + +:mps:tag:`fun.buffer-fill` + +.. note:: + + Explain way in which buffers interact with the alloc table and how + it could be improved. + +:mps:tag:`fun.buffer-empty` + +:mps:tag:`fun.condemn` + +.. c:function:: Res LOFix(Pool pool, ScanState ss, Seg seg, Ref *refIO) + +:mps:tag:`fun.fix` Fix treats references of most ranks much the same. There +is one mark table that records all marks. A reference of rank +``RankAMBIG`` is first checked to see if it is aligned to the pool +alignment and discarded if not. The reference is converted to a grain +number within the segment (by subtracting the segments' base from the +reference and then dividing by the grain size). The bit (the one +corresponding to the grain number) is set in the mark table. +Exception, for a weak reference (rank is ``RankWEAK``) the mark table +is checked and the reference is fixed to 0 if this address has not +been marked otherwise nothing happens. Note that there is no check +that the reference refers to a valid object boundary (which wouldn't +be a valid check in the case of ambiguous references anyway). + +.. c:function:: void LOReclaim(Pool pool, Trace trace, Seg seg) + +:mps:tag:`fun.reclaim` Derives the loseg from the seg, and calls +:c:func:`loSegReclaim()` (see :mps:ref:`.fun.segreclaim` below). + + +Internal +........ + +.. c:function:: void loSegReclaim(LOSeg loseg, Trace trace) + +:mps:tag:`fun.segreclaim` For all the contiguous allocated regions in the +segment it locates the boundaries of all the objects in that region by +repeatedly skipping (by calling ``format->skip``) from the beginning +of the region (the beginning of the region is guaranteed to coincide +with the beginning of an object). For each object it examines the bit +in the mark bit table that corresponds to the beginning of the object. +If that bit is set then the object has been marked as a result of a +previous call to :c:func:`LOFix()`, the object is preserved by doing +nothing. If that bit is not set then the object has not been marked +and should be reclaimed; the object is reclaimed by resetting the +appropriate range of bits in the segment's free bit table. + +.. note:: + + Special things happen for buffered segments. + + Explain how the marked variable is used to free segments. + + +Attachment +---------- + +[missing attachment "LOGROUP.CWK"] + + diff --git a/mps/manual/html/_sources/design/poolmfs.txt b/mps/manual/html/_sources/design/poolmfs.txt new file mode 100644 index 00000000000..c817b64fc91 --- /dev/null +++ b/mps/manual/html/_sources/design/poolmfs.txt @@ -0,0 +1,30 @@ +.. _design-poolmfs: + + +.. index:: + pair: MFS pool class; design + single: pool class; MFS design + + +MFS pool class +============== + +.. mps:prefix:: design.mps.poolmfs + pair: MFS pool class; design + single: pool class; MFS design + + +Overview +-------- + +MFS stands for "Manual Fixed Small". The MFS pool class manages +objects that are of a fixed size. It is intended to only manage small +objects efficiently. Storage is recycled manually by the client +programmer. + +A particular instance of an MFS Pool can manage objects only of a +single size, but different instances can manage objects of different +sizes. The size of object that an instance can manage is declared when +the instance is created. + + diff --git a/mps/manual/html/_sources/design/poolmrg.txt b/mps/manual/html/_sources/design/poolmrg.txt new file mode 100644 index 00000000000..853983cce87 --- /dev/null +++ b/mps/manual/html/_sources/design/poolmrg.txt @@ -0,0 +1,659 @@ +.. _design-poolmrg: + + +.. index:: + pair: MRG pool class; design + single: pool class; MRG design + + +MRG pool class +============== + +.. mps:prefix:: design.mps.poolmrg + pair: MRG pool class; design + single: pool class; MRG design + + +Introduction +------------ + +:mps:tag:`readership` Any MPS developer. + +:mps:tag:`intro` This is the design of the MRG (Manual Rank Guardian) pool +class. The MRG pool class is part of the MPS. The MRG pool class is +internal to the MPS (has no client interface) and is used to implement +finalization. + +:mps:tag:`source` Some of the techniques in paper.dbe93 ("Guardians in a +Generation-Based Garbage Collector") were used in this design. Some +analysis of this design (including various improvements and some more +in-depth justification) is in analysis.mps.poolmrg. That document +should be understood before changing this document. It is also helpful +to look at design.mps.finalize and design.mps.message. + + +Goals +----- + +:mps:tag:`goal.final` The MRG pool class should support all +requirements pertaining to finalization. + + +Requirements +------------ + +:mps:tag:`req` We have only one requirement pertaining to finalization: + +:mps:tag:`req.dylan.fun.finalization` Support the Dylan language-level +implementation of finalized objects: objects are registered, and are +finalized in random order when they would otherwise have died. Cycles +are broken at random places. There is no guarantee of promptness. + +:mps:tag:`req.general` However, finalization is a very common piece of +functionality that is provided by (sophisticated) memory managers, so +we can expect other clients to request this sort of functionality. + +:mps:tag:`anti-req` Is it required that the MRG pool class return +unused segments to the arena? MFS, for example, does not do this. MRG +will not do this in its initial implementation. + + +Terminology +----------- + +:mps:tag:`def.mrg` **MRG**: The MRG pool class's identifier will be MRG. +This stands for "Manual Rank Guardian". The pool is manually managed +and implements guardians for references of a particular rank +(currently just final). + +:mps:tag:`def.final.ref` **final reference**: A reference of rank final (see +design.mps.type.rank). + +:mps:tag:`def.final.object` **finalizable object**: An object is finalizable +with respect to a final reference if, since the creation of that +reference, there was a point in time when no references to the object +of lower (that is, stronger) rank were reachable from a root. + +:mps:tag:`def.final.object.note` Note that this means an object can be +finalizable even if it is now reachable from the root via exact +references. + +:mps:tag:`def.finalize` **finalize**: To finalize an object is to notify the +client that the object is finalizable. The client is presumed to be +interested in this information (typically it will apply some method to +the object). + +:mps:tag:`def.guardian` **guardian**: An object allocated in the MRG +Pool. A guardian contains exactly one final reference, and some fields +for the pool's internal use. Guardians are used to implement a +finalization mechanism. + + +Overview +-------- + +:mps:tag:`over` The MRG pool class is a pool class in the MPS. It is +intended to provide the functionality of "finalization". + +:mps:tag:`over.internal` The MRG pool class is internal to the MPM: it +is not intended to have a client interface. Clients are expected to +access the functionality provided by this pool (finalization) using a +separate MPS finalization interface (design.mps.finalize). + +:mps:tag:`over.one-size` The MRG pool class manages objects of a single +size, each object containing a single reference of rank final. + +:mps:tag:`over.one-size.justify` This is all that is necessary to meet our +requirements for finalization. Whenever an object is registered for +finalization, it is sufficient to create a single reference of rank +final to it. + +:mps:tag:`over.queue` A pool maintains a list of live guardian objects, +called (for historical reasons) the "entry" list. + +:mps:tag:`over.queue.free` The pool also maintains a list of free guardian +objects called the "free" list. + +:mps:tag:`over.queue.exit.not` There used to be an "exit" list, but this is +now historical and there shouldn't be any current references to it. + +:mps:tag:`over.alloc` When guardians are allocated, they are placed on the +entry list. Guardians on the entry list refer to objects that have not +yet been shown to be finalizable (either the object has references of +lower rank than final to it, or the MPS has not yet got round to +determining that the object is finalizable). + +:mps:tag:`over.message.create` When a guardian is discovered to refer to a +finalizable object it is removed from the entry list and becomes a +message on the arena's messages queue. + +:mps:tag:`over.message.deliver` When the MPS client receives the message the +message system arranges for the message to be destroyed and the pool +reclaims the storage associated with the guardian/message. + +:mps:tag:`over.scan` When the pool is scanned at rank final each reference +will be fixed. If the reference is to an unmarked object (before the +fix), then the object must now be finalizable. In this case the +containing guardian will be removed from the entry list and posted as +a message. + +:mps:tag:`over.scan.justify` The scanning process is a crucial step +necessary for implementing finalization. It is the means by which the +MPS detects that objects are finalizable. + +:mps:tag:`over.message` ``PoolClassMRG`` implements a :c:type:`MessageClass` (see +design.mps.message). All the messages are of one ``MessageType``. This +type is ``MessageTypeFinalization``. Messages are created when objects +are discovered to be finalizable and destroyed when the MPS client has +received the message. + +:mps:tag:`over.message.justify` Messages provide a means for the MPS to +communicate with its client. Notification of finalization is just such +a communication. Messages allow the MPS to inform the client of +finalization events when it is convenient for the MPS to do so (i.e. +not in PageFault context). + +:mps:tag:`over.manual` Objects in the MRG pool are manually managed. + +:mps:tag:`over.manual.alloc` They are allocated by :c:func:`ArenaFinalize()` when +objects are registered for finalization. + +:mps:tag:`over.manual.free` They are freed when the associated message is +destroyed. + +:mps:tag:`over.manual.justify` The lifetime of a guardian object is very +easy to determine so manual memory management is appropriate. + + +Protocols +--------- + +Object Registration +................... + +:mps:tag:`protocol.register` There is a protocol by which objects can be +registered for finalization. This protocol is handled by the arena +module on behalf of finalization. see +design.mps.finalize.int.finalize. + + +Finalizer execution +................... + +:mps:tag:`protocol.finalizer` If an object is proven to be finalizable then +a message to this effect will eventually be posted. A client can +receive the message, determine what to do about it, and do it. +Typically this would involve calling the finalization method for the +object, and deleting the message. Once the message is deleted, the +object may become recyclable. + + +Setup / destroy +............... + +:mps:tag:`protocol.life` An instance of PoolClassMRG is needed in order to +support finalization, it is called the "final" pool and is attached to +the arena (see design.mps.finalize.int.arena.struct). + +:mps:tag:`protocol.life.birth` The final pool is created lazily by +:c:func:`ArenaFinalize()`. + +:mps:tag:`protocol.life.death` The final pool is destroyed during +:c:func:`ArenaDestroy()`. + + +Data structures +--------------- + +:mps:tag:`guardian` The guardian + +:mps:tag:`guardian.over` A guardian is an object used to manage the +references and other data structures that are used by the pool in +order to keep track of which objects are registered for finalization, +which ones have been finalized, and so on. + +:mps:tag:`guardian.state` A guardian can be in one of four states: + +:mps:tag:`guardian.state.enum` The states are Free, Prefinal, Final, +PostFinal (referred to as MRGGuardianFree, etc. in the +implementation). + +1. :mps:tag:`guardian.state.free` The guardian is free, meaning that it is + on the free list for the pool and available for allocation. + +2. :mps:tag:`guardian.state.prefinal` The guardian is allocated, and refers + to an object that has not yet been discovered to be finalizable. It + is on the entry list for the pool. + +3. :mps:tag:`guardian.state.final` The guardian is allocated, and refers to + an object that has been shown to be finalizable; this state + corresponds to the existence of a message. + +4. :mps:tag:`guardian.state.postfinal` This state is only used briefly and + is entirely internal to the pool; the guardian enters this state + just after the associated message has been destroyed (which happens + when the client receives the message) and will be freed immediately + (whereupon it will enter the Free state). This state is used for + checking only (so that MRGFree can check that only guardians in + this state are being freed). + +:mps:tag:`guardian.life-cycle` Guardians go through the following state life-cycle: Free ⟶ Prefinal ⟶ Final ⟶ Postfinal ⟶ Free. + +:mps:tag:`guardian.two-part` A guardian is a structure consisting abstractly +of a link part and a reference part. Concretely, the link part is a +:c:type:`LinkPartStruct`, and the reference part is a :c:type:`RefPartStruct` +(which is just a :c:type:`Word`). The link part is used by the pool, the +reference part forms the object visible to clients of the pool. The +reference part is the reference of ``RankFINAL`` that refers to +objects registered for finalization and is how the MPS detects +finalizable objects. + +:mps:tag:`guardian.two-part.union` The :c:type:`LinkPartStruct` is a discriminated +union of a :c:type:`RingStruct` and a :c:type:`MessageStruct`. The :c:type:`RingStruct` +is used when the guardian is either Free or Prefinal. The +MessageStruct is used when the guardian is Final. Neither part of the +union is used when the guardian is in the Postfinal state. + +:mps:tag:`guardian.two-part.justify` This may seem a little profligate with +space, but this is okay as we are not required to make finalization +extremely space efficient. + +:mps:tag:`guardian.parts.separate` The two parts will be stored in separate +segments. + +:mps:tag:`guardian.parts.separate.justify` This is so that the data +structures the pool uses to manage the objects can be separated from +the objects themselves. This avoids the pool having to manipulate data +structures that are on shielded segments +(analysis.mps.poolmrg.hazard.shield). + +:mps:tag:`guardian.assoc` Ref part number *n* (from the beginning of the +segment) in one segment will correspond with link part number *n* in +another segment. The association between the two segments will be +managed by the additional fields in pool-specific segment subclasses +(see :mps:ref:`.mrgseg`). + +:mps:tag:`guardian.ref` Guardians that are either Prefinal or Final are live +and have valid references (possibly :c:macro:`NULL`) in their ref parts. +Guardians that are free are dead and always have :c:macro:`NULL` in their ref +parts (see :mps:ref:`.free.overwrite` and :mps:ref:`.scan.free`). + +:mps:tag:`guardian.ref.free` When freeing an object, it is a pointer to the +reference part that will be passed (internally in the pool). + +:mps:tag:`guardian.init` Guardians are initialized when the pool is grown +(:mps:ref:`.alloc.grow`). The initial state has the ref part :c:macro:`NULL` and the +link part is attached to the free ring. Freeing an object returns a +guardian to its initial state. + +:mps:tag:`poolstruct` The Pool structure, :c:type:`MRGStruct` will have: + +- :mps:tag:`poolstruct.entry` the head of the entry list. + +- :mps:tag:`poolstruct.free` the head of the free list. + +- :mps:tag:`poolstruct.rings` The entry list, the exit list, and the free + list will each be implemented as a :c:type:`Ring`. Each ring will be + maintained using the link part of the guardian. + + :mps:tag:`poolstruct.rings.justify` This is because rings are convenient to + use and are well tested. It is possible to implement all three lists + using a singly linked list, but the saving is certainly not worth + making at this stage. + +- :mps:tag:`poolstruct.refring` a ring of "ref" segments in use for links or + messages (see .mrgseg.ref.mrgring below). + +- :mps:tag:`poolstruct.extend` a precalculated ``extendBy`` field (see + :mps:ref:`.init.extend`). This value is used to determine how large a + segment should be requested from the arena for the reference part + segment when the pool needs to grow (see :mps:ref:`.alloc.grow.size`). + + :mps:tag:`poolstruct.extend.justify` Calculating a reasonable value for this + once and remembering it simplifies the allocation (:mps:ref:`.alloc.grow`). + +:mps:tag:`poolstruct.init` poolstructs are initialized once for each pool +instance by :c:func:`MRGInit()` (:mps:ref:`.init`). The initial state has all the +rings initialized to singleton rings, and the ``extendBy`` field +initialized to some value (see :mps:ref:`.init.extend`). + +:mps:tag:`mrgseg` The pool defines two segment subclasses: +:c:type:`MRGRefSegClass` and :c:type:`MRGLinkSegClass`. Segments of the former +class will be used to store the ref parts of guardians, segments of +the latter will be used to store the link parts of guardians (see +:mps:ref:`.guardian.two-part`). Segments are always allocated in pairs, with +one of each class, by the function :c:func:`MRGSegPairCreate()`. Each +segment contains a link to its pair. + +:mps:tag:`mrgseg.ref` :c:type:`MRGRefSegClass` is a subclass of :c:type:`GCSegClass`. +Instances are of type ``MRGRefSeg``, and contain: + +- :mps:tag:`mrgseg.ref.mrgring` a field for the ring of ref part segments in + the pool. + +- :mps:tag:`mrgseg.ref.linkseg` a pointer to the paired link segment. + +- :mps:tag:`mrgseg.ref.grey` a set describing the greyness of the segment for each trace. + +:mps:tag:`mrgseg.ref.init` A segment is created and initialized once every +time the pool is grown (:mps:ref:`.alloc.grow`). The initial state has the +segment ring node initialized and attached to the pool's segment ring, +the linkseg field points to the relevant link segment, the grey field +is initialized such that the segment is not grey for all traces. + +:mps:tag:`mrgseg.link` :c:type:`MRGLinkSegClass` is a subclass of :c:type:`SegClass`. +Instances are of type ``MRGLinkSeg``, and contain: + +- :mps:tag:`mrgseg.link.refseg` a pointer to the paired ref segment. This + may be :c:macro:`NULL` during initialization, while the pairing is being + established. + +- :mps:tag:`mrgseg.link.init` The initial state has the ``linkseg`` field + pointing to the relevant ref segment. + + +Functions +--------- + +.. c:function:: Bool MRGCheck(MRG mrg) + +:mps:tag:`check` Check the signatures, the class, and each field of the +:c:type:`MRGStruct`. Each field is checked as being appropriate for its +type. + +:mps:tag:`check.justify` There are no non-trivial invariants that can +be easily checked. + +.. c:function:: Res MRGRegister(Pool pool, Ref ref) + +:mps:tag:`alloc` Add a guardian for ``ref``. + +:mps:tag:`alloc.grow` If the free list is empty then two new segments are +allocated and the free list filled up from them (note that the +reference fields of the new guardians will need to be overwritten with +:c:macro:`NULL`, see :mps:ref:`.free.overwrite`) + +:mps:tag:`alloc.grow.size` The size of the reference part segment will be +the pool's ``extendBy`` (:mps:ref:`.poolstruct.extend`) value. The link part +segment will be whatever size is necessary to accommodate *N* link +parts, where *N* is the number of reference parts that fit in the +reference part segment. + +:mps:tag:`alloc.error` If any of the requests for more resource (there are +two; one for each of two segments) fail then the successful requests +will be retracted and the result code from the failing request will be +returned. + +:mps:tag:`alloc.pop` :c:func:`MRGRegister()` pops a ring node off the free list, +and add it to the entry list. + +.. c:function:: Res MRGDeregister(Pool pool, Ref obj) + +:mps:tag:`free` Remove the guardian from the message queue and add it to the +free list. + +:mps:tag:`free.push` The guardian will simply be added to the front of the +free list (that is, no keeping the free list in address order or +anything like that). + +:mps:tag:`free.inadequate` No attempt will be made to return unused free +segments to the arena (although see +analysis.mps.poolmrg.improve.free.* for suggestions). + +:mps:tag:`free.overwrite` :c:func:`MRGDeregister()` also writes over the reference +with :c:macro:`NULL`. :mps:tag:`free.overwrite.justify` This is so that when the +segment is subsequently scanned (:mps:ref:`.scan.free`), the reference that +used to be in the object is not accidentally fixed. + +.. c:function:: Res MRGInit(Pool pool, ArgList args) + +:mps:tag:`init` Initializes the entry list, the free ring, the ref ring, and +the ``extendBy`` field. + +:mps:tag:`init.extend` The ``extendBy`` field is initialized to one +:c:func:`ArenaAlign()` (usually a page). + +:mps:tag:`init.extend.justify` This is adequate as the pool is not expected +to grow very quickly. + +.. c:function:: void MRGFinish(Pool pool) + +:mps:tag:`finish` Iterate over all the segments, returning all the segments +to the arena. + +.. c:function:: Res MRGScan(Bool *totalReturn, ScanState ss, Pool pool, Seg seg) + +:mps:tag:`scan` :c:func:`MRGScan()` scans a segment. + +:mps:tag:`scan.trivial` Scan will do nothing (that is, return immediately) +if the tracing rank is anything other than final. + +.. note:: + + This optimization is missing. impl.c.trace.scan.conservative is + not a problem because there are no faults on these segs, because + there are no references into them. But that's why :c:func:`TraceScan()` + can't do it. Pekka P. Pirinen, 1997-09-19. + +:mps:tag:`scan.trivial.justify` If the rank is lower than final then +scanning is detrimental, it will only delay finalization. If the rank +is higher than final there is nothing to do, the pool only contains +final references. + +:mps:tag:`scan.guardians` :c:func:`MRGScan()` will iterate over all guardians in +the segment. Every guardian's reference will be fixed (:mps:tag:`scan.free` +note that guardians that are on the free list have :c:macro:`NULL` in their +reference part). + +:mps:tag:`scan.wasold` If the object referred to had not been fixed +previously (that is, was unmarked) then the object is not referenced +by a reference of a lower rank (than ``RankFINAL``) and hence is +finalizable. + +:mps:tag:`scan.finalize` The guardian will be finalized. This entails moving +the guardian from state Prefinal to Final; it is removed from the +entry list and initialized as a message and posted on the arena's +message queue. + +:mps:tag:`scan.finalize.idempotent` In fact this will only happen if the +guardian has not already been finalized (which is determined by +examining the state of the guardian). + +:mps:tag:`scan.unordered` Because scanning occurs a segment at a time, the +order in which objects are finalized is "random" (it cannot be +predicted by considering only the references between objects +registered for finalization). See +analysis.mps.poolmrg.improve.semantics for how this can be improved. + +:mps:tag:`scan.unordered.justify` Unordered finalization is all that is +required. + +See analysis.mps.poolmrg.improve.scan.nomove for a suggested +improvement that avoids redundant unlinking and relinking. + +.. c:function:: Res MRGDescribe(Pool pool, mps_lib_FILE *stream) + +:mps:tag:`describe` Describes an MRG pool. Iterates along each of the entry +and exit lists and prints the guardians in each. The location of the +guardian and the value of the reference in it will be printed out. + +:mps:tag:`functions.unused` All of these will be unused: :c:func:`BufferInit()`, +:c:func:`BufferFill()`, :c:func:`BufferEmpty()`, :c:func:`BufferFinish()`, +:c:func:`TraceBegin()`, :c:func:`TraceCondemn()`, :c:func:`PoolFix()`, :c:func:`PoolReclaim()`, :c:func:`TraceEnd()`. + +:mps:tag:`functions.trivial` The Grey method of the pool class will be +:c:func:`PoolTrivGrey()`, this pool has no further bookkeeping to perform +for grey segments. + + +Transgressions +-------------- + +:mps:tag:`trans.no-finish` The MRG pool does not trouble itself to tidy up +its internal rings properly when being destroyed. + +:mps:tag:`trans.free-seg` No attempt is made to release free segments to the +arena. A suggested strategy for this is as follows: + +- Add a count of free guardians to each segment, and maintain it in + appropriate places. + +- Add a free segment ring to the pool. + +- In :c:func:`MRGRefSegScan()`, if the segment is entirely free, don't scan + it, but instead detach its links from the free ring, and move the + segment to the free segment ring. + +- At some appropriate point, such as the end of :c:func:`MRGAlloc()`, + destroy free segments. + +- In :c:func:`MRGAlloc()`, if there are no free guardians, check the free + segment ring before creating a new pair of segments. Note that this + algorithm would give some slight measure of segment hysteresis. It + is not the place of the pool to support general segment hysteresis. + + +Future +------ + +:mps:tag:`future.array` In future, for speed or simplicity, this pool could +be rewritten to use an array. See mail.gavinm.1997-09-04.13-08(0). + + +Tests +----- + +.. note:: + + This section is utterly out of date. Pekka P. Pirinen, 1997-09-19. + +:mps:tag:`test` The test impl.c.finalcv is similar to the weakness test (see +design.mps.weakness, impl.c.weakcv). + + +Functionality +............. + +This is the functionality to be tested: + +- :mps:tag:`fun.alloc` Can allocate objects. +- :mps:tag:`fun.free` Can free objects that were allocated. +- :mps:tag:`prot.write` Can write a reference into an allocated object. +- :mps:tag:`prot.read` Can read the reference from an allocated object. +- :mps:tag:`promise.faithful` A reference stored in an allocated object will + continue to refer to the same object. +- :mps:tag:`promise.live` A reference stored in an allocated object will + preserve the object referred to. +- :mps:tag:`promise.unreachable` Any objects referred to in finalization + messages are not (at the time of reading the message) reachable via + a chain of ambiguous or exact references. (we will not be able to + test this at first as there is no messaging interface) +- :mps:tag:`promise.try` The pool will make a "good faith" effort to + finalize objects that are not reachable via a chain of ambiguous or + exact references. + +Attributes +.......... + +The following attributes will be tested: + +- :mps:tag:`attr.none` There are no attribute requirements. + +Implementation +.............. + +The test will simply allocate a number of objects in the AMC pool and +finalize each one, throwing away the reference to the objects. Churn. + +:mps:tag:`test.mpm` The test will use the MPM interface (impl.h.mpm). + +:mps:tag:`test.mpm.justify` This is because it is not intended to provide an +MPS interface to this pool directly, and the MPS interface to +finalization has not been written yet (impl.h.mps). + +:mps:tag:`test.mpm.change` Later on it may use the MPS interface, in which +case, where the following text refers to allocating objects in the MRG +pool it will need adjusting. + +:mps:tag:`test.two-pools` The test will use two pools, an AMC pool, and an +MRG pool. + +:mps:tag:`test.alloc` A number of objects will be allocated in the MRG pool. + +:mps:tag:`test.free` They will then be freed. This will test :mps:ref:`.fun.alloc` +and :mps:ref:`.fun.free`, although not very much. + +:mps:tag:`test.rw.a` An object, "A", will be allocated in the AMC pool, a +reference to it will be kept in a root. + +:mps:tag:`test.rw.alloc` A number of objects will be allocated in the MRG +pool. + +:mps:tag:`test.rw.write` A reference to "A" will be written into each +object. + +:mps:tag:`test.rw.read` The reference in each object will be read and +checked to see if it refers to "A". + +:mps:tag:`test.rw.free` All the objects will be freed. + +:mps:tag:`test.rw.drop` The reference to "A" will be dropped. This will test +:mps:ref:`.prot.write` and :mps:ref:`.prot.read`. + +:mps:tag:`test.promise.fl.alloc` A number of objects will be allocated in +the AMC pool. + +:mps:tag:`test.promise.fl.tag` Each object will be tagged uniquely. + +:mps:tag:`test.promise.fl.refer` a reference to it will be stored in an +object allocated in the MRG pool. + +:mps:tag:`test.promise.fl.churn` A large amount of garbage will be allocated +in the AMC pool. Regularly, whilst this garbage is being allocated, a +check will be performed that all the objects allocated in the MRG pool +refer to valid objects and that they still refer to the same objects. +All objects from the MRG pool will then be freed (thus dropping all +references to the AMC objects). This will test :mps:ref:`.promise.faithful` +and :mps:ref:`.promise.live`. + +:mps:tag:`test.promise.ut.not` The following part of the test has not +implemented. This is because the messaging system has not yet been +implemented. + +:mps:tag:`test.promise.ut.alloc` A number of objects will be allocated in +the AMC pool. + +:mps:tag:`test.promise.ut.refer` Each object will be referred to by a root +and also referred to by an object allocated in the MRG pool. + +:mps:tag:`test.promise.ut.drop` References to a random selection of the +objects from the AMC pool will be deleted from the root. + +:mps:tag:`test.promise.ut.churn` A large amount of garbage will be allocated +in the AMC pool. + +:mps:tag:`test.promise.ut.message` The message interface will be used to +receive finalization messages. + +:mps:tag:`test.promise.ut.final.check` For each finalization message +received it will check that the object referenced in the message is +not referred to in the root. + +:mps:tag:`test.promise.ut.nofinal.check` After some amount of garbage has +been allocated it will check to see if any objects are not in the root +and haven't been finalized. This will test :mps:ref:`.promise.unreachable` and +:mps:ref:`.promise.try`. + + +Notes +----- + +:mps:tag:`access.inadequate` :c:func:`PoolAccess()` will scan segments at +`RankEXACT``. Really it should be scanned at whatever the minimum rank +of all grey segments is (the trace rank phase), however there is no +way to find this out. As a consequence we will sometimes scan pages at +``RankEXACT`` when the pages could have been scanned at ``RankFINAL``. +This means that finalization of some objects may sometimes get +delayed. + + diff --git a/mps/manual/html/_sources/design/poolmv.txt b/mps/manual/html/_sources/design/poolmv.txt new file mode 100644 index 00000000000..dd15e4381af --- /dev/null +++ b/mps/manual/html/_sources/design/poolmv.txt @@ -0,0 +1,18 @@ +.. _design-poolmv: + + +MV pool class +============= + +.. mps:prefix:: design.mps.poolmv + + +Implementation +-------------- + +:mps:tag:`lost` It is possible for MV to "lose" memory when freeing an +objects. This happens when an extra block descriptor is needed (ie the +interior of a block is being freed) and the call to allocate the block +fails. + + diff --git a/mps/manual/html/_sources/design/poolmvff.txt b/mps/manual/html/_sources/design/poolmvff.txt index 7c7e50fe354..9494380820e 100644 --- a/mps/manual/html/_sources/design/poolmvff.txt +++ b/mps/manual/html/_sources/design/poolmvff.txt @@ -1,7 +1,141 @@ -.. index:: - pair: MVFF; design - single: pool; MVFF design - .. _design-poolmvff: -.. include:: ../../converted/poolmvff.rst + +.. index:: + pair: MVFF pool class; design + single: pool class; MVFF design + + +MVFF pool class +=============== + +.. mps:prefix:: design.mps.poolmvff + pair: MVFF pool class; design + single: pool class; MVFF design + + +Introduction +------------ + +:mps:tag:`intro` This is the design of the MVFF (Manual Variable First-Fit) +pool class. This pool implements a first (or last) fit policy for +variable-sized manually-managed objects, with control over first/last, +segment preference high/low, and slot fit low/high. + +The pool was created in a response to a belief that the ScriptWorks +EPDL/EPDR's first fit policy is beneficial for some classes of client +behaviour, but the performance of a linear free list was unacceptable. + + +Overview +-------- + +:mps:tag:`over` This pool implements certain variants of the address-ordered +first-fit policy. The implementation allows allocation across segment +boundaries. + +:mps:tag:`over.buffer` Buffered allocation is also supported, but in that +case, the buffer-filling policy is worst-fit. Buffered and unbuffered +allocation can be used at the same time, but in that case, the first +ap must be created before any allocations. + +:mps:tag:`over.buffer.class` The pool uses the simplest buffer class, +BufferClass. This is appropriate since these buffers don't attach to +segments, and hence don't constrain buffered regions to lie within +segment boundaries. + +:mps:tag:`over.segments` The pool uses the simplest segment class +(SegClass). There's no need for anything more complex. + + +Methods +------- + +:mps:tag:`method` The MVFF pool supports the following methods: + +.. c:function:: Res MVFFInit(Pool pool, Args arg) + +:mps:tag:`method.init` This takes six `keyword arguments`_: + +.. _`keyword arguments`: keyword-arguments + +================================== ============================================ +Keyword argument Description +================================== ============================================ +:c:macro:`MPS_KEY_EXTEND_BY` The segment size. +:c:macro:`MPS_KEY_MEAN_SIZE` The average object size. +:c:macro:`MPS_KEY_ALIGN` The alignment of allocations and frees. + Must be at least ``sizeof(void *)``. +:c:macro:`MPS_KEY_MVFF_SLOT_HIGH` Whether to allocate objects at the end of + free blocks found, as opposed to at + the start (for unbuffered + allocation). +:c:macro:`MPS_KEY_MVFF_ARENA_HIGH` Whether to express ``SegPrefHIGH`` + to the arena, as opposed to + ``SegPrefLOW``. +:c:macro:`MPS_KEY_MVFF_FIRST_FIT` whether to use the suitable block of lowest + address, as opposed to the highest + (for unbuffered allocation) +================================== ============================================ + +:mps:tag:`method.init.epdl` To simulate the EPDL pool, specify ``extendBy``, +``avgSize``, and ``maxSize`` as normal, and use ``slotHigh=FALSE``, +``arenaHigh=FALSE``, ``firstFit=TRUE``. + +:mps:tag:`method.init.epdr` To simulate the EPDR pool, specify ``extendBy``, +``avgSize``, and ``maxSize`` as normal, and use ``slotHigh=TRUE``, +``arenaHigh=TRUE``, ``firstFit=TRUE``. + +:mps:tag:`method.init.other` The performance characteristics of other +combinations are unknown. + +:mps:tag:`method.finish` The :c:func:`PoolFinish()` method, + +:mps:tag:`method.alloc` :c:func:`PoolAlloc()` and :c:func:`PoolFree()` methods are +supported, implementing the policy set by the pool params (see +:mps:ref:`.method.init`). + +:mps:tag:`method.describe` The usual describe method. + +:mps:tag:`method.buffer` The buffer methods implement a worst-fit fill +strategy. + + +External Functions +------------------ + +:mps:tag:`function` MVFF supports the following external functions: + +:mps:tag:`function.free-size` :c:func:`mps_mvff_free_size()` returns the total +size of free space in segments allocated to the MVFF pool instance. + +:mps:tag:`function.size` :c:func:`mps_mvff_size()` returns the total memory used +by pool segments, whether free or allocated. + +:mps:tag:`function.class` :c:func:`mps_class_mvff()` returns the class object for +the pool class, to be used in pool creation. + + +Implementation +-------------- + +:mps:tag:`impl.free-list` The pool stores its free list in a CBS (see +`design.mps.cbs `_). It uses the CBS's mayUseInline facility to +avoid running out of memory to store the free list. This is the reason +for the alignment restriction above. + + +Details +------- + +:mps:tag:`design.seg-size` When adding a segment, we use extendBy as the +segment size unless the object won't fit, in which case we use the +object size (in both cases we align up). + +:mps:tag:`design.seg-fail` If allocating a segment fails, we try again with +a segment size just large enough for the object we're allocating. This +is in response to `request.mps.170186`_. + +.. _`request.mps.170186`: https://info.ravenbrook.com/project/mps/import/2001-11-05/mmprevol/request/mps/170186/ + + diff --git a/mps/manual/html/_sources/design/prot.txt b/mps/manual/html/_sources/design/prot.txt index f2a8d3a2ede..a3b9ad04a02 100644 --- a/mps/manual/html/_sources/design/prot.txt +++ b/mps/manual/html/_sources/design/prot.txt @@ -1,6 +1,87 @@ +.. _design-prot: + + .. index:: pair: protection interface; design -.. _design-prot: -.. include:: ../../converted/prot.rst +The protection module +===================== + +.. mps:prefix:: design.mps.prot + + +Introduction +------------ + +:mps:tag:`intro` This is the generic design of the Protection Module. The +protection module provides protection services to other parts of the +MPS. It is expected that different operating systems will have +different implementations of this module. + +:mps:tag:`readership` Any MPS developer. + + +Interface +--------- + +.. c:function:: void ProtSetup(void) + +:mps:tag:`if.setup` :c:func:`ProtSetup()` will be called exactly once (per +process). It will be called as part of the initialization of the first +space that is created. It should arrange for the setup and +initialization of any datastructures or services that are necessary in +order to implement the protection module. (On UNIX it expected that it +will install a signal handler, on Windows it will do nothing) + +.. c:function:: void ProtSet(Addr base, Addr limit, AccessSet mode) + +:mps:tag:`if.set` :c:func:`ProtSet()` should set the protection of the memory +between base and limit, including base, but not including limit (ie +the half-open interval [base,limit)) to that specified by mode. The +mode parameter should have the ``AccessWRITE`` bit set if write +accesses to the page are to be forbidden, and should have the +``AccessREAD`` bit set if read accesses to the page are to be +forbidden. A request to forbid read accesses (that is, ``AccessREAD`` +is set) may also forbid write accesses, but read accesses will not be +forbidden unless ``AccessREAD`` is set. + +.. c:function:: void ProtTramp(void **resultReturn, void *(*f)(void *, size_t), void *p, size_t s) + +:mps:tag:`if.tramp` [undocumented] + +.. c:function:: void ProtSync(Space space) + +:mps:tag:`if.sync` :c:func:`ProtSync()` is called to ensure that the actual +protection of each segment (as determined by the OS) is in accordance +with the segments's ``pm`` field. + +.. c:type:: struct MutatorFaultContextStruct *MutatorFaultContext + +:mps:tag:`if.context-type` This abstract type is implemented by the +protection module (impl.c.prot*). It represents the continuation of +the mutator which is restored after a mutator fault has been handled. +The functions :c:func:`ProtCanStepInstruction()` (:mps:ref:`.if.canstep` below) and +:c:func:`ProtStepInstruction()` (:mps:ref:`.if.step` below) inspect and manipulate +the context. + +.. c:function:: Bool ProtCanStepInstruction(MutatorFaultContext context) + +:mps:tag:`if.canstep` Examines the context to determine whether the +protection module can single-step the instruction which is causing the +fault. Should return :c:macro:`TRUE` if and only if the instruction can be +single-stepped (that is, :c:func:`ProtStepInstruction()` can be called). + +.. c:function:: Bool Res ProtStepInstruction(MutatorFaultContext context) + +:mps:tag:`if.step` Single-steps the instruction which is causing the fault. +This function should only be called if :c:func:`ProtCanStepInstruction()` +applied to the context returned :c:macro:`TRUE`. It should return +``ResUNIMPL`` if the instruction cannot be single-stepped. It should +return ``ResOK`` if the instruction is single-stepped. + +The mutator context will be updated by the emulation/execution of the +instruction such that resuming the mutator will not cause the +instruction which was causing the fault to be executed. + + diff --git a/mps/manual/html/_sources/design/protan.txt b/mps/manual/html/_sources/design/protan.txt new file mode 100644 index 00000000000..9ceb972aad1 --- /dev/null +++ b/mps/manual/html/_sources/design/protan.txt @@ -0,0 +1,81 @@ +.. _design-protan: + + +.. index:: + pair: ANSI; protection interface design + pair: ANSI protection interface; design + + +ANSI implementation of protection module +======================================== + +.. mps:prefix:: design.mps.protan + pair: ANSI; protection interface design + pair: ANSI protection interface; design + + +Introduction +------------ + +:mps:tag:`readership` Any MPS developer. + +:mps:tag:`intro` This is the design for the ANSI implementation of the +protection module. + + +Requirements +------------ + +:mps:tag:`req.test` This module is required for testing. Particularly on +platforms where no real implementation of the protection module +exists. + +:mps:tag:`req.rapid-port` This module is required for rapid porting. It +should enable a developer to port a minimally useful configuration of +the MPS to new platforms very quickly. + + +Overview +-------- + +:mps:tag:`overview` Most of the functions in the module do nothing. The +exception is :c:func:`ProtSync()` which traverses over all segments in the +arena and simulates an access to each segment that has any protection +on it. This means that this module depends on certain fields in the +segment structure. + +:mps:tag:`overview.noos` No operating system specific (or even ANSI hosted +specific) code is in this module. It can therefore be used on any +platform, particularly where no real implementation of the module +exists. It satisfies :mps:ref:`.req.test` and :mps:ref:`.req.rapid-port` in this way. + + +Functions +--------- + +:mps:tag:`fun.protsetup` :c:func:`ProtSetup()` does nothing as there is nothing to +do (under UNIX we might expect the protection module to install one or +more signal handlers at this pointer, but that is not appropriate for +the ANSI implementation). Of course, we can't have an empty function +body, so there is a ``NOOP;`` here. + +:mps:tag:`fun.sync` :c:func:`ProtSync()` is called to ensure that the actual +protection of each segment (as determined by the OS) is in accordance +with the segments's pm field. In the ANSI implementation we have no +way of changing the protection of a segment, so instead we generate +faults on all protected segments in the assumption that that will +remove the protection on segments. + +:mps:tag:`fun.sync.how` Continually loops over all the segments until it +finds that all segments have no protection. + +:mps:tag:`fun.sync.seg` If it finds a segment that is protected then +:c:func:`PoolAccess()` is called on that segment's pool and with that +segment. The call to :c:func:`PoolAccess()` is wrapped with a +:c:func:`ShieldEnter()` and :c:func:`ShieldLeave()` thereby giving the pool the +illusion that the fault was generated outside the MM. This depends on +being able to determine the protection of a segment (using the ``pm`` +field), on being able to call :c:func:`ShieldEnter()` and :c:func:`ShieldLeave()`, +and on being able to call :c:func:`PoolAccess()`. + + diff --git a/mps/manual/html/_sources/design/protli.txt b/mps/manual/html/_sources/design/protli.txt new file mode 100644 index 00000000000..a10e4077e19 --- /dev/null +++ b/mps/manual/html/_sources/design/protli.txt @@ -0,0 +1,198 @@ +.. _design-protli: + + +.. index:: + pair: Linux; protection interface design + pair: Linux protection interface; design + + +Linux implementation of protection module +========================================= + +.. mps:prefix:: design.mps.protli + pair: Linux; protection interface design + pair: Linux protection interface; design + + +Introduction +------------ + +:mps:tag:`readership` Any MPS developer + +:mps:tag:`intro` This is the design of the Linux implementation of the +protection module. It makes use of various services provided by Linux. +It is intended to work with LinuxThreads. + + +Requirements +------------ + +:mps:tag:`req.general` Required to implement the general protection +interface defined in design.mps.prot.if. + + +Data structures +--------------- + +:mps:tag:`data.signext` This is static. Because that is the only +communications channel available to signal handlers. + +.. note:: + + Write a little more here. + + +Functions +--------- + +:mps:tag:`fun.setup` :c:func:`ProtSetup()` installs a signal handler for the signal +:c:macro:`SIGSEGV` to catch and handle protection faults (this handler is the +function :c:func:`sigHandle()`, see :mps:ref:`.fun.sighandle`). The previous handler +is recorded (in the variable ``sigNext``, see :mps:ref:`.data.signext`) so +that it can be reached from :c:func:`sigHandle()` if it fails to handle the +fault. + +:mps:tag:`fun.setup.problem` The problem with this approach is that we can't +honour the wishes of the ``sigvec(2)`` entry for the previous handler +(in terms of masks in particular). + +:mps:tag:`improve.sigvec` What if when we want to pass on the signal instead +of calling the handler we call :c:func:`sigvec()` with the old entry and use +:c:func:`kill()` to send the signal to ourselves and then restore our +handler using :c:func:`sigvec()` again? + +.. note:: + + Need more detail and analysis here. + +:mps:tag:`fun.set` :c:func:`ProtSet()` uses :c:func:`mprotect()` to adjust the +protection for pages. + +:mps:tag:`fun.set.convert` The requested protection (which is expressed in +the ``mode`` parameter, see design.mps.prot.if.set) is translated into +an operating system protection. If read accesses are to be forbidden +then all accesses are forbidden, this is done by setting the +protection of the page to :c:macro:`PROT_NONE`. If write accesses are to be +forbidden (and not read accesses) then write accesses are forbidden +and read accesses are allowed, this is done by setting the protection +of the page to ``PROT_READ|PROT_EXEC``. Otherwise (all access are +okay), the protection is set to ``PROT_READ|PROT_WRITE|PROT_EXEC``. + +:mps:tag:`fun.set.assume.mprotect` We assume that the call to :c:func:`mprotect()` +always succeeds. + +:mps:tag:`fun.set.assume.mprotect` This is because we should always call the +function with valid arguments (aligned, references to mapped pages, +and with an access that is compatible with the access of the +underlying object). + +:mps:tag:`fun.sync` :c:func:`ProtSync()` does nothing in this implementation as +:c:func:`ProtSet()` sets the protection without any delay. + +:mps:tag:`fun.tramp` The protection trampoline, :c:func:`ProtTramp()`, is trivial +under Linux, as there is nothing that needs to be done in the dynamic +context of the mutator in order to catch faults. (Contrast this with +Win32 Structured Exception Handling.) + + +Threads +------- + +:mps:tag:`threads` The design must operate in a multi-threaded environment +(with LinuxThreads) and cooperate with the Linux support for locks +(see design.mps.lock) and the thread suspension mechanism (see +design.mps.pthreadext ). + +:mps:tag:`threads.suspend` The :c:macro:`SIGSEGV` signal handler does not mask out +any signals, so a thread may be suspended while the handler is active, +as required by the design (see +design.mps.pthreadext.req.suspend.protection). The signal handlers +simply nest at top of stack. + +:mps:tag:`threads.async` POSIX (and hence Linux) imposes some restrictions +on signal handler functions (see +design.mps.pthreadext.anal.signal.safety). Basically the rules say the +behaviour of almost all POSIX functions inside a signal handler is +undefined, except for a handful of functions which are known to be +"async-signal safe". However, if it's known that the signal didn't +happen inside a POSIX function, then it is safe to call arbitrary +POSIX functions inside a handler. + +:mps:tag:`threads.async.protection` If the signal handler is invoked because +of an MPS access, then we know the access must have been caused by +client code, because the client is not allowed to permit access to +protectable memory to arbitrary foreign code. In these circumstances, +it's OK to call arbitrary POSIX functions inside the handler. + +.. note:: + + Need a reference for "the client is not allowed to permit access + to protectable memory to arbitrary foreign code". + +:mps:tag:`threads.async.other` If the signal handler is invoked for some +other reason (that is, one we are not prepared to handle) then there +is less we can say about what might have caused the SEGV. In general +it is not safe to call arbitrary POSIX functions inside the handler in +this case. + +:mps:tag:`threads.async.choice` The signal handler calls :c:func:`ArenaAccess()` +to determine whether the segmentation fault was the result of an MPS +access. ArenaAccess will claim various MPS locks (that is, the arena +ring lock and some arena locks). The code calls no other POSIX +functions in the case where the segmentation fault is not an MPS +access. The locks are implemented as mutexes and are claimed by +calling :c:func:`pthread_mutex_lock()`, which is not defined to be +async-signal safe. + +:mps:tag:`threads.async.choice.ok` However, despite the fact that PThreads +documentation doesn't define the behaviour of :c:func:`pthread_mutex_lock()` +in these circumstances, we expect the LinuxThreads implementation will +be well-behaved unless the segmentation fault occurs while while in +the process of locking or unlocking one of the MPS locks (see +:mps:ref:`.threads.async.linux-mutex`). But we can assume that a segmentation +fault will not happen then (because we use the locks correctly, and +generally must assume that they work). Hence we conclude that it is OK +to call :c:func:`ArenaAccess()` directly from the signal handler. + +:mps:tag:`threads.async.linux-mutex` A study of the LinuxThreads source code +reveals that mutex lock and unlock functions are implemented as a +spinlock (using a locked compare-and-exchange instruction) with a +backup suspension mechanism using :c:func:`sigsuspend()`. On locking, the +spinlock code performs a loop which examines the state of the lock, +and then atomically tests that the state is unchanged while attempting +to modify it. This part of the code is reentrant (and hence +async-signal safe). Eventually, when locking, the spinlock code may +need to block, in which case it calls :c:func:`sigsuspend()`, waiting for +the manager thread to unblock it. The unlocking code is similar, +except that this code may need to release another thread, in which +case it calls :c:func:`kill()`. The functions :c:func:`sigsuspend()` and +:c:func:`kill()` are both defined to be async-signal safe by POSIX. In +summary, the mutex locking functions use primitives which are entirely +async-signal safe. They perform side-effects which modify the fields +of the lock structure only. This code may be safely invoked inside a +signal handler unless the interrupted function is in the process of +manipulating the fields of that lock structure. + +:mps:tag:`threads.async.improve` In future it would be preferable to not +have to assume reentrant mutex locking and unlocking functions. By +making the assumption we also assume that the implementation of +mutexes in LinuxThreads will not be completely re-designed in future +(which is not wise for the long term). An alternative approach would +be necessary anyway when supporting another platform which doesn't +offer reentrant locks (if such a platform does exist). + +:mps:tag:`threads.async.improve.how` We could avoid the assumption if we had +a means of testing whether an address lies within an arena chunk +without the need to claim any locks. Such a test might actually be +possible. For example, arenas could update a global datastructure +describing the ranges of all chunks, using atomic updates rather than +locks; the handler code would be allowed to read this without locking. +However, this is somewhat tricky; a particular consideration is that +it's not clear when it's safe to deallocate stale portions of the +datastructure. + +:mps:tag:`threads.sig-stack` We do not handle signals on a separate signal +stack. Separate signal stacks apparently don't work properly with +Pthreads. + + diff --git a/mps/manual/html/_sources/design/protocol.txt b/mps/manual/html/_sources/design/protocol.txt index 45b574e4301..74020429335 100644 --- a/mps/manual/html/_sources/design/protocol.txt +++ b/mps/manual/html/_sources/design/protocol.txt @@ -1,6 +1,517 @@ +.. _design-protocol: + + .. index:: pair: protocol inheritance; design -.. _design-protocol: -.. include:: ../../converted/protocol.rst +Protocol inheritance +==================== + +.. mps:prefix:: design.mps.protocol + + +Introduction +------------ + +:mps:tag:`intro` This document explains the design of the support for class +inheritance in MPS. It is not yet complete. It describes support for +single inheritance of classes. Future extensions will describe +multiple inheritance and the relationship between instances and +classes. + +:mps:tag:`readership` This document is intended for any MPS developer. + + +Purpose +------- + +:mps:tag:`purpose.code-maintain` The purpose of the protocol inheritance +design is to ensure that the MPS code base can make use of the +benefits of object-oriented class inheritance to maximize code reuse, +minimize code maintenance and minimize the use of boilerplate code. + +:mps:tag:`purpose.related` For related discussion, see +mail.tony.1998-08-28.16-26(0), mail.tony.1998-09-01.11-38(0), +mail.tony.1998-10-06.11-03(0) and other messages in the same threads. + + +Requirements +------------ + +:mps:tag:`req.implicit` The object system should provide a means for classes +to inherit the methods of their direct superclasses implicitly for all +functions in the protocol without having to write any explicit code +for each inherited function. + +:mps:tag:`req.override` There must additionally be a way for classes to +override the methods of their superclasses. + +:mps:tag:`req.next-method` As a result of :mps:ref:`.req.implicit`, classes cannot +make static assumptions about methods used by direct superclasses. The +object system must provide a means for classes to extend (not just +replace) the behaviour of protocol functions, such as a mechanism for +invoking the "next-method". + +:mps:tag:`req.ideal.extend` The object system must provide a standard way +for classes to implement the protocol supported by they superclass and +additionally add new methods of their own which can be specialized by +subclasses. + +:mps:tag:`req.ideal.multiple-inheritance` The object system should support +multiple inheritance such that sub-protocols can be "mixed in" with +several classes which do not themselves support identical protocols. + + +Overview +-------- + +.. c:type:: struct ProtocolClassStruct *ProtocolClass + +:mps:tag:`overview.root` We start with the root of all conformant class +hierarchies, which is called :c:type:`ProtocolClass`. This is an "abstract" +class (that is, it has no direct instances, but it is intended to have +subclasses). To use Dylan terminology, instances of its subclasses are +"general" instances of ProtocolClass. They look like this:: + + Instance Object Class Object + + -------------------- -------------------- + | sig | |-------->| sig | + -------------------- | -------------------- + | class |----| | superclass | + -------------------- -------------------- + | ... | | coerceInst | + -------------------- -------------------- + | ... | | coerceClass | + -------------------- -------------------- + | | | ... | + +:mps:tag:`overview.inherit` Classes inherit the protocols supported by their +superclasses. By default they have the same methods as the class(es) +from which they inherit. + +:mps:tag:`overview.inherit.specialize` Classes may specialize the behaviour +of their superclass. They do this by by overriding methods or other +fields in the class object. + +:mps:tag:`overview.extend` Classes may extend the protocols supported by +their superclasses by adding new fields for methods or other data. + +:mps:tag:`overview.sig.inherit` Classes will contain (possibly several) +signatures. Classes must not specialize (override) the signatures they +inherit from their superclasses. + +:mps:tag:`overview.sig.extend` If a class definition extends a protocol, it +is normal policy for the class definition to include a new signature +as the last field in the class object. + +:mps:tag:`overview.coerce-class` Each class contains a ``coerceClass`` +field. This contains a method which can find the part of the class +object which implements the protocols of a supplied superclass +argument (if, indeed, the argument *is* a superclass). This function +may be used for testing subclass/superclass relationships, and it also +provides support for multiple inheritance. + +:mps:tag:`overview.coerce-inst` Each class contains a ``coerceInst`` field. +This contains a method which can find the part of an instance object +which contains the instance slots of a supplied superclass argument +(if, indeed, the argument *is* a superclass). This function may be +used for testing whether an object is an instance of a given class, +and it also provides support for multiple inheritance. + +:mps:tag:`overview.superclass` Each class contains a ``superclass`` field. +This enables classes to call "next-method", as well as enabling the +coercion functions. + +:mps:tag:`overview.next-method` A specialized method in a class can make use +of an overridden method from a superclass by accessing the method from +the appropriate field in the superclass object and calling it. The +superclass may be accessed indirectly from the class's "Ensure" +function when it is statically known (see :mps:ref:`.overview.access`). This +permits "next-method" calls, and is fully scalable in that it allows +arbitrary length method chains. The :c:func:`SUPERCLASS()` macro helps with +this (see :mps:ref:`.int.static-superclass`). + +:mps:tag:`overview.next-method.naive` In some cases it is necessary to write +a method which is designed to specialize an inherited method, needs to +call the next-method, and yet the implementation doesn't have static +knowledge of the superclass. This might happen because the specialized +method is designed to be reusable by many class definitions. The +specialized method can usually locate the class object from one of the +parameters passed to the method. It can then access the superclass +through the ``superclass`` field of the class, and hence call the next +method. This technique has some limitations and doesn't support longer +method chains. It is also dependent on none of the class definitions +which use the method having any subclasses. + +:mps:tag:`overview.access` Classes must be initialized by calls to +functions, since it is these function calls which copy properties from +superclasses. Each class must provide an "Ensure" function, which +returns the canonical copy of the class. The canonical copy may reside +in static storage, but no MPS code may refer to that static storage by +name. + +:mps:tag:`overview.naming` There are some strict naming conventions which +must be followed when defining and using classes. The use is +obligatory because it is assumed by the macros which support the +definition and inheritance mechanism. For every class :c:type:`SomeClass`, +we insist upon the following naming conventions:- + +* :c:type:`SomeClassStruct` + + names the type of the structure for the protocol class. This might + be a ``typedef`` which aliases the type to the type of the + superclass, but if the class has extended the protocols of the + superclass the it will be a type which contains the new class + fields. + +* :c:type:`SomeClass` + + names the type ``*SomeClassStruct``. This might be a ``typedef`` + which aliases the type to the type of the superclass, but if the + class has extended the protocols of the superclass then it will be + a type which contains the new class fields. + +* :c:func:`EnsureSomeClass()` + + names the function that returns the initialized class object. + + + +Interface +--------- + +Class definition +................ + +.. c:function:: DEFINE_CLASS(className, var) + +:mps:tag:`int.define-class` Class definition is performed by the macro +:c:func:`DEFINE_CLASS()`. A call to the macro must be followed by a body of +initialization code in braces ``{}``. The parameter ``className`` is +used to name the class being defined. The parameter ``var`` is used to +name a local variable of type ``className``, which is defined by the +macro; it refers to the canonical storage for the class being defined. +This variable may be used in the initialization code. (The macro +doesn't just pick a name implicitly because of the danger of a name +clash with other names used by the programmer). A call to +``DEFINE_CLASS(SomeClass, var)`` defines the :c:func:`EnsureSomeClass()` +function, defines some static storage for the canonical class object, +and defines some other things to ensure the class gets initialized +exactly once. + +.. c:function:: DEFINE_ALIAS_CLASS(className, typeName, var) + +:mps:tag:`int.define-alias-class` A convenience macro +:c:func:`DEFINE_ALIAS_CLASS()` is provided which both performs the class +definition and defines the types :c:type:`SomeClass` and ``SomeClass +struct`` as aliases for some other class types. This is particularly +useful for classes which simply inherit, and don't extend protocols. +The macro call ``DEFINE_ALIAS_CLASS(className, superName, var)`` is +exactly equivalent to the following:: + + typedef superName className; + typedef superNameStruct classNameStruct; + DEFINE_CLASS(className, var) + +:mps:tag:`int.define-special` If classes are particularly likely to be +subclassed without extension, the class implementor may choose to +provide a convenience macro which expands into :c:func:`DEFINE_ALIAS_CLASS()` +with an appropriate name for the superclass. For example, there might +be a macro for defining pool classes such that the macro call +``DEFINE_POOL_CLASS(className, var)`` is exactly equivalent to the +macro call ``DEFINE_ALIAS_CLASS(className, PoolClass, var)``. It may +also be convenient to define a static superclass accessor macro at the +same time (see :mps:ref:`.int.static-superclass.special`). + + +Single inheritance +.................. + +.. c:function:: INHERIT_CLASS(thisClassCoerced, parentName) + +:mps:tag:`int.inheritance` Class inheritance details must be provided in the +class initialization code (see :mps:ref:`.int.define-class`). Inheritance is +performed by the macro :c:func:`INHERIT_CLASS()`. A call to this macro will +make the class being defined a direct subclass of ``parentClassName`` +by ensuring that all the fields of the parent class are copied into +``thisClass``, and setting the superclass field of ``thisClass`` to be +the parent class object. The parameter ``thisClassCoerced`` must be of +type ``parentClassName``. If the class definition defines an alias +class (see :mps:ref:`.int.define-alias-class`), then the variable named as the +second parameter to :c:func:`DEFINE_CLASS()` will be appropriate to pass to +:c:func:`INHERIT_CLASS()`. + + +Specialization +.............. + +:mps:tag:`int.specialize` Class specialization details must be given +explicitly in the class initialization code (see +:mps:ref:`.int.define-class`). This must happen *after* the inheritance +details are given (see :mps:ref:`.int.inheritance`). + + +Extension +......... + +:mps:tag:`int.extend` To extend the protocol when defining a new class, a +new type must be defined for the class structure. This must embed the +structure for the primarily inherited class as the first field of the +structure. Class extension details must be given explicitly in the +class initialization code (see :mps:ref:`.int.define-class`). This must happen +*after* the inheritance details are given (see :mps:ref:`.int.inheritance`). + + +Introspection +............. + +:mps:tag:`introspect.c-lang` The design includes a number of introspection +functions for dynamically examining class relationships. These +functions are polymorphic and accept arbitrary subclasses of +:c:type:`ProtocolClass`. C doesn't support such polymorphism. So although +these have the semantics of functions (and could be implemented as +functions in another language with compatible calling conventions) +they are actually implemented as macros. The macros are named as +method-style macros despite the fact that this arguably contravenes +guide.impl.c.macro.method. The justification for this is that this +design is intended to promote the use of polymorphism, and it breaks +the abstraction for the users to need to be aware of what can and +can't be expressed directly in C function syntax. These functions all +have names ending in ``Poly`` to identify them as polymorphic +functions. + +.. c:function:: ProtocolClassSuperclassPoly(class) + +:mps:tag:`int.superclass` An introspection function which returns the direct +superclass of class object ``class``. + +.. c:function:: SUPERCLASS(className) + +:mps:tag:`int.static-superclass` An introspection macro which returns the +direct superclass given a class name, which must (obviously) be +statically known. The macro expands into a call to the ensure function +for the class name, so this must be in scope (which may require a +forward declaration). The macro is useful for next-method calls (see +:mps:ref:`.overview.next-method`). The superclass is returned with type +:c:type:`ProtocolClass` so it may be necessary to cast it to the type for +the appropriate subclass. + +:mps:tag:`int.static-superclass.special` Implementors of classes which are +designed to be subclassed without extension may choose to provide a +convenience macro which expands into a call to :c:macro:`SUPERCLASS` along +with a type cast. For example, there might be a macro for finding pool +superclasses such that the macro call ``POOL_SUPERCLASS(className)`` +is exactly equivalent to ``(PoolClass)SUPERCLASS(className)``. It's +convenient to define these macros alongside the convenience class +definition macro (see :mps:ref:`.int.define-special`). + +.. c:function:: ClassOfPoly(inst) + +:mps:tag:`int.class` An introspection function which returns the class of +which ``inst`` is a direct instance. + +.. c:function:: IsSubclassPoly(sub, super) + +:mps:tag:`int.subclass` An introspection function which returns a :c:type:`Bool` +indicating whether ``sub`` is a subclass of ``super``. That is, it is +a predicate for testing subclass relationships. + + +Multiple inheritance +.................... + +:mps:tag:`int.mult-inherit` Multiple inheritance involves an extension of +the protocol (see :mps:ref:`.int.extend`) and also multiple uses of the single +inheritance mechanism (see :mps:ref:`.int.inheritance`). It also requires +specialized methods for ``coerceClass`` and ``coerceInst`` to be +written (see :mps:ref:`.overview.coerce-class` and :mps:ref:`.overview.coerce-inst`). +Documentation on support for multiple inheritance is under +construction. This facility is not currently used. The basic idea is +described in mail.tony.1998-10-06.11-03(0). + + +Protocol guidelines +................... + +:mps:tag:`guide.fail` When designing an extensible function which might +fail, the design must permit the correct implementation of the +failure-case code. Typically, a failure might occur in any method in +the chain. Each method is responsible for correctly propagating +failure information supplied by superclass methods and for managing +it's own failures. + +:mps:tag:`guide.fail.before-next` Dealing with a failure which is detected +before any next-method call is made is similar to a fail case in any +non-extensible function. See :mps:ref:`.example.fail` below. + +:mps:tag:`guide.fail.during-next` Dealing with a failure returned from a +next-method call is also similar to a fail case in any non-extensible +function. See :mps:ref:`.example.fail` below. + +:mps:tag:`guide.fail.after-next` Dealing with a failure which is detected +after the next methods have been successfully invoked is more complex. +If this scenario is possible, the design must include an +"anti-function", and each class must ensure that it provides a method +for the anti-method which will clean up any resources which are +claimed after a successful invocation of the main method for that +class. Typically the anti-function would exist anyway for clients of +the protocol (for example, "finish" is an anti-function for "init"). +The effect of the next-method call can then be cleaned up by calling +the anti-method for the superclass. See :mps:ref:`.example.fail` below. + + +Example +....... + +:mps:tag:`example.inheritance` The following example class definition shows +both inheritance and specialization. It shows the definition of the +class :c:type:`EPDRPoolClass`, which inherits from :c:type:`EPDLPoolClass` and has +specialized values of the ``name``, ``init``, and ``alloc`` fields. +The type :c:type:`EPDLPoolClass` is an alias for :c:type:`PoolClass`. :: + + typedef EPDLPoolClass EPDRPoolClass; + typedef EPDLPoolClassStruct EPDRPoolClassStruct; + + DEFINE_CLASS(EPDRPoolClass, this) + { + INHERIT_CLASS(this, EPDLPoolClass); + this->name = "EPDR"; + this->init = EPDRInit; + this->alloc = EPDRAlloc; + } + +:mps:tag:`example.extension` The following (hypothetical) example class +definition shows inheritance, specialization and also extension. It +shows the definition of the class :c:type:`EPDLDebugPoolClass`, which +inherits from :c:type:`EPDLPoolClass`, but also implements a method for +checking properties of the pool. :: + + typedef struct EPDLDebugPoolClassStruct { + EPDLPoolClassStruct epdl; + DebugPoolCheckMethod check; + Sig sig; + } EPDLDebugPoolClassStruct; + + typedef EPDLDebugPoolClassStruct *EPDLDebugPoolClass; + + DEFINE_CLASS(EPDLDebugPoolClass, this) + { + EPDLPoolClass epdl = &this->epdl; + INHERIT_CLASS(epdl, EPDLPoolClass); + epdl->name = "EPDLDBG"; + this->check = EPDLDebugCheck; + this->sig = EPDLDebugSig; + } + +:mps:tag:`example.fail` The following example shows the implementation of +failure-case code for an "init" method, making use of the "finish" +anti-method:: + + static Res mySegInit(Seg seg, Pool pool, Addr base, Size size, + Bool reservoirPermit, va_list args) + { + SegClass super; + MYSeg myseg; + OBJ1 obj1; + Res res; + Arena arena; + + AVERT(Seg, seg); + myseg = SegMYSeg(seg); + AVERT(Pool, pool); + arena = PoolArena(pool); + + /* Ensure the pool is ready for the segment */ + res = myNoteSeg(pool, seg); + if(res != ResOK) + goto failNoteSeg; + + /* Initialize the superclass fields first via next-method call */ + super = (SegClass)SUPERCLASS(MYSegClass); + res = super->init(seg, pool, base, size, reservoirPermit, args); + if(res != ResOK) + goto failNextMethods; + + /* Create an object after the next-method call */ + res = ControlAlloc(&obj1, arena, sizeof(OBJ1Struct), reservoirPermit); + if(res != ResOK) + goto failObj1; + + myseg->obj1 = obj1 + return ResOK; + + failObj1: + /* call the anti-method for the superclass */ + super->finish(seg); + failNextMethods: + /* reverse the effect of myNoteSeg */ + myUnnoteSeg(pool, seg); + failNoteSeg: + return res; + } + + +Implementation +-------------- + +:mps:tag:`impl.derived-names` The :c:func:`DEFINE_CLASS()` macro derives some +additional names from the class name as part of it's implementation. +These should not appear in the source code - but it may be useful to +know about this for debugging purposes. For each class definition for +class :c:type:`SomeClass`, the macro defines the following: + +* ``extern SomeClass EnsureSomeClass(void);`` + + The class accessor function. See :mps:ref:`.overview.naming`. + +* ``static Bool protocolSomeClassGuardian;`` + + A Boolean which indicates whether the class has been initialized + yet. + +* ``static void protocolEnsureSomeClass(SomeClass);`` + + A function called by :c:func:`EnsureSomeClass()`. All the class + initialization code is actually in this function. + +* ``static SomeClassStruct protocolSomeClassStruct;`` + + Static storage for the canonical class object. + +:mps:tag:`impl.init-once` Class objects only behave according to their +definition after they have been initialized, and class protocols may +not be used before initialization has happened. The only code which is +allowed to see a class object in a partially initialized state is the +initialization code itself -- and this must take care not to pass the +object to any other code which might assume it is initialized. Once a +class has been initialized, the class might have a client. The class +must not be initialized again when this has happened, because the +state is not necessarily consistent in the middle of an initialization +function. The initialization state for each class is stored in a +Boolean "guardian" variable whose name is derived from the class name +(see :mps:ref:`.impl.derived-names`). This ensures the initialization happens +only once. The path through the :c:func:`EnsureSomeClass()` function should be +very fast for the common case when this variable is :c:macro:`TRUE`, and the +class has already been initialized, as the canonical static storage +can simply be returned in that case. However, when the value of the +guardian is :c:macro:`FALSE`, the class is not initialized. In this case, a +call to :c:func:`EnsureSomeClass()` must first execute the initialization code +and then set the guardian to :c:macro:`TRUE`. However, this must happen +atomically (see :mps:ref:`.impl.init-lock`). + +:mps:tag:`impl.init-lock` There would be the possibility of a race condition +if :c:func:`EnsureSomeClass()` were called concurrently on separate threads +before :c:type:`SomeClass` has been initialized. The class must not be +initialized more than once, so the sequence test-guard, init-class, +set-guard must be run as a critical region. It's not sufficient to use +the arena lock to protect the critical region, because the class +object might be shared between multiple arenas. The :c:func:`DEFINE_CLASS()` +macro uses a global recursive lock instead. The lock is only claimed +after an initial unlocked access of the guard variable shows that the +class is not initialized. This avoids any locking overhead for the +common case where the class is already initialized. This lock is +provided by the lock module -- see design.mps.lock(0). + + diff --git a/mps/manual/html/_sources/design/protsu.txt b/mps/manual/html/_sources/design/protsu.txt new file mode 100644 index 00000000000..530e446ae76 --- /dev/null +++ b/mps/manual/html/_sources/design/protsu.txt @@ -0,0 +1,118 @@ +.. _design-protsu: + + +.. index:: + pair: SunOS 4; protection interface design + pair: SunOS 4 protection interface; design + + +SunOS 4 protection module +========================= + +.. mps:prefix:: design.mps.protsu + pair: SunOS 4; protection interface design + pair: SunOS 4 protection interface; design + + +.. warning:: + + As of 2013-05-26, the MPS is no longer supported on SunOS, so + this document is only of historical interest. + + +Introduction +------------ + +:mps:tag:`readership` Any MPS developer. + +:mps:tag:`intro` This is the design of the SunOS 4 implementation of the +protection module. It is intended to be used only in SunOS 4 (os.su). +It makes use of various services provided by SunOS 4. + + +Requirements +------------ + +:mps:tag:`req.general` Required to implement the general protection +interface defined in design.mps.prot.if.*. + + +Overview +-------- + +Uses :c:func:`mprotect()`. + + +Misc +---- + +:mps:tag:`improve.sig-stack` Currently we do not handle signals on a +separate signal stack. If we handled signals on our own stack then we +could guarantee not to run out of stack while we were handling the +signal. This would be useful (it may even be required). We would have +to use ``sigvec(2)`` rather than ``signal(3)`` (set the :c:macro:`SV_ONSTACK` +flag and use ``sigstack(2)``). This has drawbacks as the signal stack +is not grown automatically, so we would have to to frig the stacks +back if we wanted to pass on the signal to some other handler as that +handler may require arbitrary amounts of stack. + +:mps:tag:`improve.sigvec` Note 1 of :c:func:`ProtSetup()` notes that we can't +honour the ``sigvec(2)`` entries of the next handler in the chain. +What if when we want to pass on the signal instead of calling the +handler we call :c:func:`sigvec()` with the old entry and use kill to send +the signal to ourselves and then restore our handler using sigvec +again. + + +Data structures +--------------- + +:mps:tag:`data.signext` This is static. Because that is the only +communications channel available to signal handlers. [write a little +more here] + + +Functions +--------- + +:mps:tag:`fun.setup` :c:func:`ProtSetup()`. The setup involves installing a signal +handler for the signal :c:macro:`SIGSEGV` to catch and handle protection +faults (this handler is the function :c:func:`sigHandle()`, see +:mps:ref:`.fun.sighandle`). The previous handler is recorded (in the variable +``sigNext``, see :mps:ref:`.data.signext`) so that it can be reached from +:c:func:`sigHandle()` if it fails to handle the fault. + +The problem with this approach is that we can't honor the wishes of the +``sigvec(2)`` entry for the previous handler (in terms of masks in particular). + +Obviously it would be okay to always chain the previous signal handler +onto ``sigNext``, however in the case where the previous handler is +the one we've just installed (that is, ``sigHandle``) then it is not +necessary to chain the handler, so we don't. + +:mps:tag:`fun.set` :c:func:`ProtSet()` + +:mps:tag:`fun.set.convert` The requested protection (which is expressed in +the mode parameter, see design.mps.prot.if.set) is translated into an +operating system protection. If read accesses are to be forbidden then +all accesses are forbidden, this is done by setting the protection of +the page to :c:macro:`PROT_NONE`. If write access are to be forbidden (and +not read accesses) then write accesses are forbidden and read accesses +are allowed, this is done by setting the protection of the page to +``PROT_READ | PROT_EXEC``. Otherwise (all access are okay), the +protection is set to ``PROT_READ | PROT_WRITE | PROT_EXEC``. + +:mps:tag:`fun.set.assume.mprotect` We assume that the call to :c:func:`mprotect()` +always succeeds. This is because we should always call the function +with valid arguments (aligned, references to mapped pages, and with an +access that is compatible with the access of the underlying object). + +:mps:tag:`fun.sync` :c:func:`ProtSync()`. This does nothing in this implementation +as ProtSet sets the protection without any delay. + +:mps:tag:`fun.tramp` :c:func:`ProtTramp()`. The protection trampoline is trivial +under SunOS, as there is nothing that needs to be done in the dynamic +context of the mutator in order to catch faults. (Contrast this with +Win32 Structured Exception Handling.) + + diff --git a/mps/manual/html/_sources/design/pthreadext.txt b/mps/manual/html/_sources/design/pthreadext.txt new file mode 100644 index 00000000000..90ed4a1a3b6 --- /dev/null +++ b/mps/manual/html/_sources/design/pthreadext.txt @@ -0,0 +1,344 @@ +.. _design-pthreadext: + + +.. index:: + pair: POSIX thread extensions; design + + +POSIX thread extensions +======================= + +.. mps:prefix:: design.mps.pthreadext + + +Introduction +------------ + +:mps:tag:`readership` Any MPS developer. + +:mps:tag:`intro` This is the design of the Pthreads extension module, which +provides some low-level threads support for use by MPS (notably +suspend and resume). + + +Definitions +----------- + +:mps:tag:`pthreads` The term "Pthreads" means an implementation of the POSIX +1003.1c-1995 thread standard. (Or the Single UNIX Specification, +Version 2, aka USV2 or UNIX98.) + +:mps:tag:`context` The "context" of a thread is a (platform-specific) +OS-defined structure which describes the current state of the +registers for that thread. + + +Requirements +------------ + +:mps:tag:`req.suspend` A means to suspend threads, so that they don't make +any progress. + +:mps:tag:`req.suspend.why` Needed by the thread manager so that other +threads registered with an arena can be suspended (see +design.mps.thread-manager). Not directly provided by Pthreads. + +:mps:tag:`req.resume` A means to resume suspended threads, so that they are +able to make progress again. :mps:tag:`req.resume.why` Needed by the thread +manager. Not directly provided by Pthreads. + +:mps:tag:`req.suspend.multiple` Allow a thread to be suspended on behalf of +one arena when it has already been suspended on behalf of one or more +other arenas. :mps:tag:`req.suspend.multiple.why` The thread manager +contains no design for cooperation between arenas to prevent this. + +:mps:tag:`req.resume.multiple` Allow requests to resume a thread on behalf +of each arena which had previously suspended the thread. The thread +must only be resumed when requests from all such arenas have been +received. :mps:tag:`req.resume.multiple.why` A thread manager for an arena +must not permit a thread to make progress before it explicitly resumes +the thread. + +:mps:tag:`req.suspend.context` Must be able to access the context for a +thread when it is suspended. + +:mps:tag:`req.suspend.protection` Must be able to suspend a thread which is +currently handling a protection fault (i.e., an arena access). Such a +thread might even own an arena lock. + +:mps:tag:`req.legal` Must use the Pthreads and other POSIX APIs in a legal +manner. + + + +Analysis +-------- + +:mps:tag:`anal.suspend` Thread suspension is inherently asynchronous. MPS +needs to be able to suspend another thread without prior knowledge of +the code that thread is running. (That is, we can't rely on +cooperation between threads.) The only asynchronous communication +available on POSIX is via signals -- so the suspend and resume +mechanism must ultimately be built from signals. + +:mps:tag:`anal.signal.safety` POSIX imposes some restrictions on what a +signal handler function might do when invoked asynchronously (see the +sigaction_ documentation, and search for the string "reentrant"). In +summary, a small number of POSIX functions are defined to be +"async-signal safe", which means they may be invoked without +restriction in signal handlers. All other POSIX functions are +considered to be unsafe. Behaviour is undefined if an unsafe function +is interrupted by a signal and the signal handler then proceeds to +call another unsafe function. See mail.tony.1999-08-24.15-40(0)and +followups for some further analysis. + +.. _sigaction: http://www.opengroup.org/onlinepubs/007908799/xsh/sigaction.html + +:mps:tag:`anal.signal.safety.implication` Since we can't assume that we +won't attempt to suspend a thread while it is running an unsafe +function, we must limit the use of POSIX functions in the suspend +signal handler to those which are designed to be "async-signal safe". +One of the few such functions related to synchronization is +:c:func:`sem_post()`. + +:mps:tag:`anal.signal.example` An example of how to suspend threads in POSIX +was posted to newsgroup comp.programming.threads in August 1999 +[Lau_1999-08-16]_. The code in the post was written by David Butenhof, who +contributed some comments on his implementation [Butenhof_1999-08-16]_ + +:mps:tag:`anal.signal.linux-hack` In the current implementation of Linux +Pthreads, it would be possible to implement suspend/resume using +:c:macro:`SIGSTOP` and :c:macro:`SIGCONT`. This is, however, nonportable and will +probably stop working on Linux at some point. + +:mps:tag:`anal.component` There is no known way to meet the requirements +above in a way which cooperates with another component in the system +which also provides its own mechanism to suspend and resume threads. +The best bet for achieving this is to provide the functionality in +shared low-level component which may be used by MPS and other clients. +This will require some discussion with other potential clients and/or +standards bodies. + +:mps:tag:`anal.component.dylan` Note that such cooperation is actually a +requirement for Dylan (req.dylan.dc.env.self), though this is not a +problem, since all the Dylan components share the MPS mechanism. + + +Interface +--------- + +.. c:type:: PThreadextStruct *PThreadext + +:mps:tag:`if.pthreadext.abstract` A thread is represented by the abstract +type :c:type:`PThreadext`. A :c:type:`PThreadext` object corresponds directly with +a PThread (of type ``pthread_t``). There may be more than one +:c:type:`PThreadext` object for the same PThread. + +:mps:tag:`if.pthreadext.structure` The structure definition of +:c:type:`PThreadext` (:c:type:`PThreadextStruct`) is exposed by the interface so +that it may be embedded in a client datastructure (for example, +:c:type:`ThreadStruct`). This means that all storage management can be left +to the client (which is important because there might be multiple +arenas involved). Clients may not access the fields of a +:c:type:`PThreadextStruct` directly. + +.. c:function:: void PThreadextInit(PThreadext pthreadext, pthread_t id) + +:mps:tag:`if.init` Initializes a :c:type:`PThreadext` object for a thread with the +given ``id``. + +.. c:function:: Bool PThreadextCheck(PThreadext pthreadext) + +:mps:tag:`if.check` Checks a :c:type:`PThreadext` object for consistency. Note +that this function takes the mutex, so it must not be called with the +mutex held (doing so will probably deadlock the thread). + +.. c:function:: Res PThreadextSuspend(PThreadext pthreadext, struct sigcontext **contextReturn) + +:mps:tag:`if.suspend` Suspends a :c:type:`PThreadext` object (puts it into a +suspended state). Meets :mps:ref:`.req.suspend`. The object must not already +be in a suspended state. If the function returns ``ResOK``, the +context of the thread is returned in contextReturn, and the +corresponding PThread will not make any progress until it is resumed: + +.. c:function:: Res PThreadextResume(PThreadext pthreadext) + +:mps:tag:`if.resume` Resumes a :c:type:`PThreadext` object. Meets +:mps:ref:`.req.resume`. The object must already be in a suspended state. +Puts the object into a non-suspended state. Permits the corresponding +PThread to make progress again, (although that might not happen +immediately if there is another suspended :c:type:`PThreadext` object +corresponding to the same thread): + +.. c:function:: void PThreadextFinish(PThreadext pthreadext) + +:mps:tag:`if.finish` Finishes a PThreadext object. + + + +Implementation +-------------- + +.. c:type:: struct PThreadextStruct PThreadextStruct + +:mps:tag:`impl.pthreadext` The structure definition for a :c:type:`PThreadext` +object is:: + + struct PThreadextStruct { + Sig sig; /* design.mps.sig */ + pthread_t id; /* Thread ID */ + struct sigcontext *suspendedScp; /* sigcontext if suspended */ + RingStruct threadRing; /* ring of suspended threads */ + RingStruct idRing; /* duplicate suspensions for id */ + }; + +:mps:tag:`impl.field.id` The ``id`` field shows which PThread the object +corresponds to. + +:mps:tag:`impl.field.scp` The ``suspendedScp`` field contains the context +when in a suspended state. Otherwise it is :c:macro:`NULL`. + +:mps:tag:`impl.field.threadring` The ``threadRing`` field is used to chain +the object onto the suspend ring when it is in the suspended state +(see :mps:ref:`.impl.suspend-ring`). When not in a suspended state, this ring +is single. + +:mps:tag:`impl.field.idring` The ``idRing`` field is used to group the +object with other objects corresponding to the same PThread (same +``id`` field) when they are in the suspended state. When not in a +suspended state, or when this is the only :c:type:`PThreadext` object with +this ``id`` in the suspended state, this ring is single. + +:mps:tag:`impl.global.suspend-ring` The module maintains a global +suspend-ring -- a ring of :c:type:`PThreadext` objects which are in a +suspended state. This is primarily so that it's possible to determine +whether a thread is curently suspended anyway because of another +:c:type:`PThreadext` object, when a suspend attempt is made. + +:mps:tag:`impl.global.victim` The module maintains a global variable which +is used to indicate which :c:type:`PThreadext` is the current victim during +suspend operations. This is used to communicate information between +the controlling thread and the thread being suspended (the victim). +The variable has value :c:macro:`NULL` at other times. + +:mps:tag:`impl.static.mutex` We use a lock (mutex) around the suspend and +resume operations. This protects the state data (the suspend-ring the +victim: see :mps:ref:`.impl.global.suspend-ring` and :mps:ref:`.impl.global.victim` +respectively). Since only one thread can be suspended at a time, +there's no possibility of two arenas suspending each other by +concurrently suspending each other's threads. + +:mps:tag:`impl.static.semaphore` We use a semaphore to synchronize between +the controlling and victim threads during the suspend operation. See +:mps:ref:`.impl.suspend` and :mps:ref:`.impl.suspend-handler`). + +:mps:tag:`impl.static.init` The static data and global variables of the +module are initialized on the first call to :c:func:`PThreadextSuspend()`, +using :c:func:`pthread_once()` to avoid concurrency problems. We also enable +the signal handlers at the same time (see :mps:ref:`.impl.suspend-handler` and +:mps:ref:`.impl.resume-handler`). + +:mps:tag:`impl.suspend` :c:func:`PThreadextSuspend()` first ensures the module is +initialized (see :mps:ref:`.impl.static.init`). After this, it claims the +mutex (see :mps:ref:`.impl.static.mutex`). It then checks to see whether +thread of the target :c:type:`PThreadext` object has already been suspended +on behalf of another :c:type:`PThreadext` object. It does this by iterating +over the suspend ring. + +:mps:tag:`impl.suspend.already-suspended` If another object with the same id +is found on the suspend ring, then the thread is already suspended. +The context of the target object is updated from the other object, and +the other object is linked into the ``idRing`` of the target. + +:mps:tag:`impl.suspend.not-suspended` If the thread is not already +suspended, then we forcibly suspend it using a technique similar to +Butenhof's (see :mps:ref:`.anal.signal.example`): First we set the victim +variable (see :mps:ref:`.impl.global.victim`) to indicate the target object. +Then we send the signal :c:macro:`PTHREADEXT_SIGSUSPEND` to the thread (see +:mps:ref:`.impl.signals`), and wait on the semaphore for it to indicate that +it has received the signal and updated the victim variable with the +context. If either of these operations fail (for example, because of +thread termination) we unlock the mutex and return ``ResFAIL``. + +:mps:tag:`impl.suspend.update` Once we have ensured that the thread is +definitely suspended, we add the target :c:type:`PThreadext` object to the +suspend ring, unlock the mutex, and return the context to the caller. + +:mps:tag:`impl.suspend-handler` The suspend signal handler is invoked in the +target thread during a suspend operation, when a +:c:macro:`PTHREADEXT_SIGSUSPEND` signal is sent by the controlling thread +(see :mps:ref:`.impl.suspend.not-suspended`). The handler determines the +context (received as a parameter, although this may be +platform-specific) and stores this in the victim object (see +:mps:ref:`.impl.global.victim`). The handler then masks out all signals except +the one that will be received on a resume operation +(:c:macro:`PTHREADEXT_SIGRESUME`) and synchronizes with the controlling +thread by posting the semaphore. Finally the handler suspends until +the resume signal is received, using :c:func:`sigsuspend()`. + +:mps:tag:`impl.resume` :c:func:`PThreadextResume()` first claims the mutex (see +:mps:ref:`.impl.static.mutex`). It then checks to see whether thread of the +target :c:type:`PThreadext` object has also been suspended on behalf of +another :c:type:`PThreadext` object (in which case the id ring of the target +object will not be single). + +:mps:tag:`impl.resume.also-suspended` If the thread is also suspended on +behalf of another :c:type:`PThreadext`, then the target object is removed from +the id ring. + +:mps:tag:`impl.resume.not-also` If the thread is not also suspended on +behalf of another :c:type:`PThreadext`, then the thread is resumed using the +technique proposed by Butenhof (see :mps:ref:`.anal.signal.example`). I.e. we +send it the signal :c:macro:`PTHREADEXT_SIGRESUME` (see :mps:ref:`.impl.signals`) and +expect it to wake up. If this operation fails (for example, because of +thread termination) we unlock the mutex and return ``ResFAIL``. + +:mps:tag:`impl.resume.update` Once the target thread is in the appropriate +state, we remove the target :c:type:`PThreadext` object from the suspend +ring, set its context to :c:macro:`NULL` and unlock the mutex. + +:mps:tag:`impl.resume-handler` The resume signal handler is invoked in the +target thread during a resume operation, when a +:c:macro:`PTHREADEXT_SIGRESUME` signal is sent by the controlling thread (see +:mps:ref:`.impl.resume.not-also`). The resume signal handler simply returns. +This is sufficient to unblock the suspend handler, which will have +been blocking the thread at the time of the signal. The Pthreads +implementation ensures that the signal mask is restored to the value +it had before the signal handler was invoked. + +:mps:tag:`impl.finish` :c:func:`PThreadextFinish()` supports the finishing of +objects in the suspended state, and removes them from the suspend ring +and id ring as necessary. It must claim the mutex for the removal +operation (to ensure atomicity of the operation). Finishing of +suspended objects is supported so that clients can dispose of +resources if a resume operation fails (which probably means that the +PThread has terminated). + +:mps:tag:`impl.signals` The choice of which signals to use for suspend and +restore operations may need to be platform-specific. Some signals are +likely to be generated and/or handled by other parts of the +application and so should not be used (for example, :c:macro:`SIGSEGV`). Some +implementations of PThreads use some signals for themselves, so they +may not be used; for example, LinuxThreads uses :c:macro:`SIGUSR1` and +:c:macro:`SIGUSR2` for its own purposes. The design abstractly names the +signals :c:macro:`PTHREADEXT_SIGSUSPEND` and :c:macro:`PTHREAD_SIGRESUME`, so that +they may be easily mapped to appropriate real signal values. Candidate +choices are :c:macro:`SIGXFSZ` and :c:macro:`SIGPWR`. + + +Attachments +----------- + +[missing attachment "posix.txt"] + +[missing attachment "susp.c"] + + +References +---------- + +.. [Butenhof_1999-08-16] Dave Butenhof. comp.programming.threads. 1999-08-16. "`Re: Problem with Suspend & Resume Thread Example `__". + +.. [Lau_1999-08-16] Raymond Lau. comp.programming.threads. 1999-08-16. "`Problem with Suspend & Resume Thread Example `__". + + diff --git a/mps/manual/html/_sources/design/reservoir.txt b/mps/manual/html/_sources/design/reservoir.txt index e954bdc62ab..0bc6dcce290 100644 --- a/mps/manual/html/_sources/design/reservoir.txt +++ b/mps/manual/html/_sources/design/reservoir.txt @@ -1,6 +1,115 @@ +.. _design-reservoir: + + .. index:: pair: reservoir; design -.. _design-reservoir: -.. include:: ../../converted/reservoir.rst +The low-memory reservoir +======================== + +.. mps:prefix:: design.mps.reservoir + + +Introduction +------------ + +:mps:tag:`intro` The low-memory reservoir provides client support for +implementing handlers for low-memory situations which allocate. The +reservoir is implemented inside the arena as a pool of unallocatable +segments. + + +Architecture +------------ + +.. c:type:: struct ReservoirStruct *Reservoir + +:mps:tag:`adt` The reservoir interface looks (almost) like an abstract data +type of type :c:type:`Reservoir`. It's not quite abstract because the arena +embeds the structure of the reservoir (of type :c:type:`ReservoirStruct`) +into its own structure, for simplicity of initialization. + +:mps:tag:`align` The reservoir is implemented as a pool of available tracts, +along with a size and limit which must always be aligned to the arena +alignment. The size corresponds to the amount of memory currently +maintained in the reservoir. The limit is the maximum amount that it +is desired to maintain. + +:mps:tag:`wastage` When the reservoir limit is set by the client, the actual +limit should be increased by an arena alignment amount for every +active mutator buffer. + +:mps:tag:`really-empty` When the reservoir limit is set to 0, assume that +the client really doesn't have a need for a reservoir at all. In this +case, the client won't even want an allowance to be made for wastage +in active buffers. + + +Implementation +-------------- + +:mps:tag:`interface` The following functions comprise the interface to the +reservoir module: + +.. c:function:: Bool ReservoirCheck(Reservoir reservoir) + +:mps:tag:`interface.check` :c:func:`ReservoirCheck()` checks the reservoir for +consistency. + +.. c:function:: Res ReservoirInit(Reservoir reservoir, Arena arena) + +:mps:tag:`interface.init` :c:func:`ReservoirInit()` initializes the reservoir and +its associated pool, setting the size and limit to 0. + +.. c:function:: void ReservoirFinish (Reservoir reservoir) + +:mps:tag:`interface.finish` :c:func:`ReservoirFinish()` de-initializes the reservoir +and its associated pool: + +.. c:function:: Size ReservoirLimit(Reservoir reservoir) + +:mps:tag:`interface.limit` :c:func:`ReservoirLimit()` returns the limit of the +reservoir: + +.. c:function:: void ReservoirSetLimit(Reservoir reservoir, Size size) + +:mps:tag:`interface.set-limit` :c:func:`ReservoirSetLimit()` sets the limit of the +reservoir, making an allowance for wastage in mutator buffers: + +.. c:function:: Size ReservoirAvailable(Reservoir reservoir) + +:mps:tag:`interface.available` :c:func:`ReservoirAvailable()` returns the available +size of the reservoir: + +.. c:function:: Res ReservoirEnsureFull(Reservoir reservoir) + +:mps:tag:`interface.ensure-full` :c:func:`ReservoirEnsureFull()` attempts to fill +the reservoir with memory from the arena, until it is full: + +.. c:function:: void ReservoirDeposit(Reservoir reservoir, Addr base, Size size) + +:mps:tag:`interface.deposit` :c:func:`ReservoirDeposit()` attempts to fill the +reservoir with memory in the supplied range, until it is full. This is +called by the arena from :c:func:`ArenaFree()` if the reservoir is not known +to be full. Any memory which is not added to the reservoir (because +the reservoir is full) is freed via the arena class's free method. + +.. c:function:: Res ReservoirWithdraw(Addr *baseReturn, Tract *baseTractReturn, Reservoir reservoir, Size size, Pool pool) + +:mps:tag:`interface.withdraw` :c:func:`ReservoirWithdraw()` attempts to allocate +memory of the specified size to the specified pool to the reservoir. +If no suitable memory can be found it returns ``ResMEMORY``. + +:mps:tag:`interface.withdraw.align` Currently, :c:func:`ReservoirWithdraw()` can +only withdraw memory in chunks of the size of the arena alignment. +This is because the reservoir doesn't attempt to coalesce adjacent +memory blocks. This deficiency should be fixed in the future. + +:mps:tag:`pool` The memory managed by the reservoir is owned by the +reservoir pool. This memory is never sub-allocated. Each tract +belonging to the pool is linked onto a list. The head of the list is +in the :c:type:`Reservoir` object. Links are stored in the ``TractP`` fields +of each tract object. + + diff --git a/mps/manual/html/_sources/design/ring.txt b/mps/manual/html/_sources/design/ring.txt index 09d1afbb04e..501e3d52c82 100644 --- a/mps/manual/html/_sources/design/ring.txt +++ b/mps/manual/html/_sources/design/ring.txt @@ -1,6 +1,193 @@ +.. _design-ring: + + .. index:: pair: ring structure; design -.. _design-ring: -.. include:: ../../converted/ring.rst +Ring data structure +=================== + +.. mps:prefix:: design.mps.ring + + +Introduction +------------ + +:mps:tag:`source` rings are derived from the earlier use of Deques. See +design.mps.deque. + + +Description +----------- + +.. c:type:: RingStruct *Ring + +:mps:tag:`def.ring` Rings are circular doubly-linked lists of ring "nodes". +The nodes are fields of structures which are the "elements" of the +ring. + +Ring node structures (:c:type:`RingStruct`) are inlined in the structures on +the ring, like this:: + + typedef struct FooStruct *Foo; /* the element type */ + typedef struct FooStruct { /* the element structure */ + int baz, bim; + RingStruct ring; /* the ring node */ + float bip, bop; + } FooStruct; + +This arrangement means that they do not need to be managed separately. +This is especially useful in avoiding re-entrancy and bootstrapping +problems in the memory manager. Rings also provide flexible insertion +and deletion because the entire ring can be found from any node. + +In the MPS, rings are used to connect a "parent" structure (such as a +:c:type:`Arena`) to a number of "child" structures (such as :c:type:`Pool`), as +shown in :mps:ref:`.fig.ring`. Note the slight abuse of naming convention, in +that ``barRing`` is not called ``barRingStruct``. + +:mps:tag:`fig.ring` A ring of ``Bar`` objects owned by a ``Foo`` object. + +[missing figure] + +:mps:tag:`fig.empty` An empty ring of ``Bar`` objects owned by a ``Foo`` +object. + +[missing figure] + +:mps:tag:`def.singleton` A "singleton" ring is a ring containing one node, +whose previous and next nodes are itself (see :mps:ref:`.fig.single`). + +:mps:tag:`fig.single` A singleton ``Bar`` object not on any ring. + +[missing figure] + +:mps:tag:`fig.elt` How :c:func:`RING_ELT()` gets a parent pointer from a node pointer. + +[missing figure] + + +Init / Finish +------------- + +.. c:function:: void RingInit(Ring ring) + +:mps:tag:`init` Rings are initialized with the :c:func:`RingInit()` function. They +are initialized to be a singleton ring (:mps:ref:`.def.singleton`). + +.. c:function:: void RingFinish(Ring ring) + +:mps:tag:`finish` Rings are finished with the :c:func:`RingFinish()` function. A +ring must be a singleton ring before it can be finished (it is an +error to attempt to finish a non-singleton ring). + + +Iteration +--------- + +.. c:function:: RING_FOR(Ring node, Ring ring, Ring next) + +:mps:tag:`for` A macro is used for iterating over the elements in a ring. +This macro is called :c:func:`RING_FOR()`. :c:func:`RING_FOR()` takes three arguments. +The first is an iteration variable: ``node``. The second is the +"parent" element in the ring: ``ring``. The third is a variable used +by the iterator for working state (it holds a pointer to the next +node): ``next``. All arguments must be of type :c:type:`Ring`. The ``node`` +and ``next`` variables must be declared and in scope already. All +elements except for the "parent" element are iterated over. The macro +expands to a ``for`` statement. During execution of the loop, the +``node`` variable (the first argument to the macro) will be the value +of successive elements in the Ring (at the beginning of the statement +in the body of the loop). + +:mps:tag:`for.error` It is an error (possibly unchecked) for the ``node`` +and ``next`` variables to be modified except implicitly by using this +iterator. + +:mps:tag:`for.safe` It is safe to delete the current node during the +iteration. + +:mps:tag:`for.ex` An example:: + + Ring node, nextNode; + RING_FOR(node, &foo->barRing, nextNode) { + Bar bar = RING_ELT(Bar, FooRing, node); + frob(bar); + } + +:mps:tag:`for.ex.elt` Notice the idiomatic use of :c:func:`RING_ELT()` which is +almost universal when using :c:func:`RING_FOR()`. + + +Subclass +-------- + +.. c:function:: RING_ELT(type, field, Ring node) + +:mps:tag:`elt` :c:func:`RING_ELT()` is a macro that converts a pointer to a ring +structure into a pointer to the enclosing parent structure. +:c:func:`RING_ELT()` has three arguments which are, in order: ``type``, the +type of a pointer to the enclosing structure, ``field``, the name of +the ring structure field within it, ``ring``, the ring node. The +result is a pointer to the enclosing structure. + +.. note:: :c:func:`RING_ELT()` does not work for arrays of rings. + + +Append / Remove +--------------- + +.. c:function:: void RingAppend(Ring ring, Ring new) + +:mps:tag:`append` :c:func:`RingAppend()` appends a singleton ring to a ring (such +that the newly added element will be last in the iteration sequence). + +.. c:function:: void (RingInsert)(Ring ring, Ring new) + +:mps:tag:`insert` :c:func:`RingInsert()` adds a singleton rung to a ring (such that +the newly added element will be first in the iteration sequence). + +.. c:function:: void (RingRemove)(Ring old) + +:mps:tag:`remove` :c:func:`RingRemove()` removes an element from a ring. The newly +removed element becomes a singleton ring. It is an error for the +element to already be a singleton. + +:mps:tag:`improve.join` It would be possible to add a :c:func:`RingJoin()` operation +that joined two rings. This is not done as it is not required. + + +Naming +------ + +:mps:tag:`naming` By convention, when one structure ``Foo`` contains one +ring of ``Bar`` structures, the field in ``Foo`` is usually known as +``barRing``, and the field in ``Bar`` is known as ``fooRing``. If the +``Foo`` structure contains more than one ring of ``Bar`` structures, +then they will have names such as ``spongRing`` and ``frobRing``. + + +Deques +------ + +This section documents where rings differ significantly from deques. + +:mps:tag:`head` Deques used a distinguished head structure for the head of +the ring. Rings still have a separate head structure, but it is not +distinguished by type. + + +Defects +------- + +This section documents known defects with the current design. + +:mps:tag:`app_for.misuse` It is easy to pass :c:func:`RingAppend()` and +:c:func:`RING_FOR()` the arguments in the wrong order as all the arguments +have the same type. see :mps:ref:`.head`. + +:mps:tag:`check.improve` There is no method for performing a full integrity +check. This could be added. + + diff --git a/mps/manual/html/_sources/design/root.txt b/mps/manual/html/_sources/design/root.txt index b42b179d6b0..26c74156c05 100644 --- a/mps/manual/html/_sources/design/root.txt +++ b/mps/manual/html/_sources/design/root.txt @@ -1,6 +1,82 @@ +.. _design-root: + + .. index:: pair: root manager; design -.. _design-root: -.. include:: ../../converted/root.rst +Root manager +============ + +.. mps:prefix:: design.mps.root + + +Basics +------ + +:mps:tag:`root.def` The root node of the object graph is the node which +defines whether objects are accessible, and the place from which the +mutator acts to change the graph. In the MPS, a root is an object +which describes part of the root node. The root node is the total of +all the roots attached to the space. + +.. note:: + + Note that this combines two definitions of root: the accessibility + is what defines a root for tracing (see analysis.tracer.root.* and + the mutator action for barriers (see analysis.async-gc.root). + Pekka P. Pirinen, 1998-03-20. + +:mps:tag:`root.repr` Functionally, roots are defined by their scanning +functions. Roots *could* be represented as function closures: that is, +a pointer to a C function and some auxiliary fields. The most general +variant of roots is just that. However, for reasons of efficiency, +some special variants are separated out. + + +Details +------- + +Creation +........ + +:mps:tag:`create` A root becomes "active" as soon as it is created. + +:mps:tag:`create.col` The root inherits its colour from the mutator, since +it can only contain references copied there by the mutator from +somewhere else. If the mutator is grey for a trace when a root is +created then that root will be used to determine accessibility for +that trace. More specifically, the root will be scanned when that +trace flips. + +Destruction +........... + +:mps:tag:`destroy` It's OK to destroy a root at any time, except perhaps +concurrently with scanning it, but that's prevented by the arena lock. +If a root is destroyed the references in it become invalid and +unusable. + +Invariants +.......... + +:mps:tag:`inv.white` Roots are never white for any trace, because they +cannot be condemned. + +:mps:tag:`inv.rank` Roots always have a single rank. A root without ranks +would be a root without references, which would be pointless. The +tracer doesn't support multiple ranks in a single colour. + +Scanning +........ + +:mps:tag:`method` Root scanning methods are provided by the client so that +the MPS can locate and scan the root set. See protocol.mps.root for +details. + +.. note:: + + There are some more notes about root methods in + meeting.qa.1996-10-16. + + diff --git a/mps/manual/html/_sources/design/scan.txt b/mps/manual/html/_sources/design/scan.txt index 68c52fa8e22..ef6b29ceb35 100644 --- a/mps/manual/html/_sources/design/scan.txt +++ b/mps/manual/html/_sources/design/scan.txt @@ -1,6 +1,104 @@ +.. _design-scan: + + .. index:: pair: generic scanner; design -.. _design-scan: -.. include:: ../../converted/scan.rst +The generic scanner +=================== + +.. mps:prefix:: design.mps.scan + + +Summaries +--------- + +Scanned summary +............... + +:mps:tag:`summary.subset` The summary of reference seens by scan +(ss.unfixedSummary) is a subset of the summary previously computed +(SegSummary). + +There are two reasons that it is not an equality relation: + +1. If the segment has had objects forwarded onto it then its summary + will get unioned with the summary of the segment that the object + was forwarded from. This may increase the summary. The forwarded + object of course may have a smaller summary (if such a thing were + to be computed) and so subsequent scanning of the segment may + reduce the summary. (The forwarding process may erroneously + introduce zones into the destination's summary). + +2. A write barrier hit will set the summary to ``RefSetUNIV``. + +The reason that ss.unfixedSummary is always a subset of the previous +summary is due to an "optimization" which has not been made in +``TraceFix``. See impl.c.trace.fix.fixed.all. + + +Partial scans +............. + +:mps:tag:`clever-summary` With enough cleverness, it's possible to have +partial scans of condemned segments contribute to the segment summary. + +.. note:: + + We had a system which nearly worked -- see MMsrc(MMdevel_poolams + at 1997/08/14 13:02:55 BST), but it did not handle the situation + in which a segment was not under the write barrier when it was + condemned. + +:mps:tag:`clever-summary.acc` Each time we partially scan a segment, we +accumulate the post-scan summary of the scanned objects into a field +in the group, called 'summarySoFar'. The post-scan summary is (summary +\ white) U fixed. + +:mps:tag:`clever-summary.acc.condemn` The cumulative summary is only +meaningful while the segment is condemned. Otherwise it is set to +``RefSetEMPTY`` (a value which we can check). + +:mps:tag:`clever-summary.acc.reclaim` Then when we reclaim the segment, we +set the segment summary to the cumulative summary, as it is a +post-scan summary of all the scanned objects. + +:mps:tag:`clever-summary.acc.other-trace` If the segment is scanned by +another trace while it is condemned, the cumulative summary must be +set to the post-scan summary of this scan (otherwise it becomes +out-of-date). + +:mps:tag:`clever-summary.scan` The scan summary is expected to be a summary +of all scanned references in the segment. We don't know this +accurately until we've scanned everything in the segment. So we add in +the segment summary each time. + +:mps:tag:`clever-summary.scan.fix` TraceScan also expects the scan state +fixed summary to include the post-scan summary of all references which +were white. Since we don't scan all white references, we need to add +in an approximation to the summary of all white references which we +didn't scan. This is the intersection of the segment summary and the +white summary. + +:mps:tag:`clever-summary.wb` If the cumulative summary is smaller than the +mutator's summary, a write-barrier is needed to prevent the mutator +from invalidating it. This means that sometimes we'd have to put the +segment under the write-barrier at condemn, which might not be very +efficient + +.. note:: + + This is not an operation currently available to pool class + implementations Pekka P. Pirinen, 1998-02-26. + +:mps:tag:`clever-summary.method.wb` We need a new pool class method, called +when the write barrier is hit (or possibly any barrier hit). The +generic method will do the usual TraceAccess work, the trivial method +will do nothing. + +:mps:tag:`clever-summary.acc.wb` When the write barrier is hit, we need to +correct the cumulative summary to the mutator summary. This is +approximated by setting the summary to ``RefSetUNIV``. + + diff --git a/mps/manual/html/_sources/design/seg.txt b/mps/manual/html/_sources/design/seg.txt index a3b4889fd91..7dae28c1715 100644 --- a/mps/manual/html/_sources/design/seg.txt +++ b/mps/manual/html/_sources/design/seg.txt @@ -1,6 +1,315 @@ +.. _design-seg: + + .. index:: pair: segments; design -.. _design-seg: -.. include:: ../../converted/seg.rst +Segment data structure +====================== + +.. mps:prefix:: design.mps.seg + + +Introduction +------------ + +:mps:tag:`intro` This document describes the MPS Segment data structure. + + +Overview +-------- + +:mps:tag:`over.segments` Segments are the basic units of tracing and +shielding. The MPM also uses them as units of scanning and colour, +although pool classes may subdivide segments and be able to maintain +colour on a finer grain (down to the object level, for example). + +:mps:tag:`over.objects` The mutator's objects are stored in segments. +Segments are contiguous blocks of memory managed by some pool. + +:mps:tag:`segments.pool` The arrangement of objects within a segment is +determined by the class of the pool which owns the segment. The pool +is associated with the segment indirectly via the first tract of the +segment. + +:mps:tag:`over.memory` The relationship between segments and areas of memory +is maintained by the segment module. Pools acquire tracts from the +arena, and release them back to the arena when they don't need them +any longer. The segment module can associate contiguous tracts owned +by the same pool with a segment. The segment module provides the +methods SegBase, SegLimit, and SegSize which map a segment onto the +addresses of the memory block it represents. + +:mps:tag:`over.hierarchy` The Segment datastructure is designed to be +subclassable (see design.mps.protocol). The basic segment class +(:c:type:`Seg`) supports colour and protection for use by the tracer, as +well as support for a pool ring, and all generic segment functions. +Clients may use :c:type:`Seg` directly, but will most probably want to use a +subclass with additional properties. + +:mps:tag:`over.hierarchy.gcseg` The segment module provides ``GCSeg`` - a +subclass of :c:type:`Seg` which has full support for GC including buffering +and the ability to be linked onto the grey ring. + + +Data Structure +-------------- + +.. c:type:: struct SegStruct *Seg +.. c:type:: struct GCSegStruct *GCSeg + +The implementations are as follows:: + + typedef struct SegStruct { /* segment structure */ + Sig sig; /* impl.h.misc.sig */ + SegClass class; /* segment class structure */ + Tract firstTract; /* first tract of segment */ + RingStruct poolRing; /* link in list of segs in pool */ + Addr limit; /* limit of segment */ + unsigned depth : SHIELD_DEPTH_WIDTH; /* see impl.c.shield.def.depth */ + AccessSet pm : AccessMAX; /* protection mode, impl.c.shield */ + AccessSet sm : AccessMAX; /* shield mode, impl.c.shield */ + TraceSet grey : TRACE_MAX; /* traces for which seg is grey */ + TraceSet white : TRACE_MAX; /* traces for which seg is white */ + TraceSet nailed : TRACE_MAX; /* traces for which seg has nailed objects */ + RankSet rankSet : RankMAX; /* ranks of references in this seg */ + } SegStruct; + + + typedef struct GCSegStruct { /* GC segment structure */ + SegStruct segStruct; /* superclass fields must come first */ + RingStruct greyRing; /* link in list of grey segs */ + RefSet summary; /* summary of references out of seg */ + Buffer buffer; /* non-NULL if seg is buffered */ + Sig sig; /* design.mps.sig */ + } GCSegStruct; + + +:mps:tag:`field.rankSet` The ``rankSet`` field represents the set of ranks +of the references in the segment. It is initialized to empty by +:c:func:`SegInit()`. + +:mps:tag:`field.rankSet.single` The Tracer only permits one rank per segment +[ref?] so this field is either empty or a singleton. + +:mps:tag:`field.rankSet.empty` An empty ``rankSet`` indicates that there are +no references. If there are no references in the segment then it +cannot contain black or grey references. + +:mps:tag:`field.rankSet.start` If references are stored in the segment then +it must be updated, along with the summary (:mps:ref:`.field.summary.start`). + +:mps:tag:`field.depth` The ``depth`` field is used by the Shield +(impl.c.shield) to manage protection of the segment. It is initialized +to zero by :c:func:`SegInit()`. + +:mps:tag:`field.sm` The ``sm`` field is used by the Shield (impl.c.shield) +to manage protection of the segment. It is initialized to +``AccessSetEMPTY`` by :c:func:`SegInit()`. + +:mps:tag:`field.pm` The ``pm`` field is used by the Shield (impl.c.shield) +to manage protection of the segment. It is initialized to +``AccessSetEMPTY`` by :c:func:`SegInit()`. The field is used by both the +shield and the ANSI fake protection (impl.c.protan). + +:mps:tag:`field.black` The ``black`` field is the set of traces for which +there may be black objects (that is, objects containing references, +but no references to white objects) in the segment. More precisely, if +there is a black object for a trace in the segment then that trace +will appear in the ``black`` field. It is initialized to +``TraceSetEMPTY`` by :c:func:`SegInit()`. + +:mps:tag:`field.grey` The ``grey`` field is the set of traces for which +there may be grey objects (i.e containing references to white objects) +in the segment. More precisely, if there is a reference to a white +object for a trace in the segment then that trace will appear in the +``grey`` field. It is initialized to ``TraceSetEMPTY`` by :c:func:`SegInit()`. + +:mps:tag:`field.white` The ``white`` field is the set of traces for which +there may be white objects in the segment. More precisely, if there is +a white object for a trace in the segment then that trace will appear +in the ``white`` field. It is initialized to ``TraceSetEMPTY`` by +:c:func:`SegInit()`. + +:mps:tag:`field.summary` The ``summary`` field is an approximation to the +set of all references in the segment. If there is a reference ``R`` in +the segment, then ``RefSetIsMember(summary, R)`` is :c:macro:`TRUE`. The +summary is initialized to ``RefSetEMPTY`` by :c:func:`SegInit()`. + +:mps:tag:`field.summary.start` If references are stored in the segment then +it must be updated, along with ``rankSet`` (:mps:ref:`.field.rankSet.start`). + +:mps:tag:`field.buffer` The ``buffer`` field is either :c:macro:`NULL`, or points +to the descriptor structure of the buffer which is currently +allocating in the segment. The field is initialized to :c:macro:`NULL` by +:c:func:`SegInit()`. + +:mps:tag:`field.buffer.owner` This buffer must belong to the same pool as +the segment, because only that pool has the right to attach it. + + +Interface +--------- + +Splitting and merging +..................... + +:mps:tag:`split-and-merge` There is support for splitting and merging +segments, to give pools the flexibility to rearrange their tracts +among segments as they see fit. + +.. c:function:: Res SegSplit(Seg *segLoReturn, Seg *segHiReturn, Seg seg, Addr at, Bool withReservoirPermit, ...) + +:mps:tag:`split` If successful, segment ``seg`` is split at address ``at``, +yielding two segments which are returned in segLoReturn and +segHiReturn for the low and high segments respectively. The base of +the low segment is the old base of ``seg``. The limit of the low +segment is ``at``. The base of the high segment is ``at``. This limit +of the high segment is the old limit of ``seg``. ``seg`` is +effectively destroyed during this operation (actually, it might be +reused as one of the returned segments). Segment subclasses may make +use of the optional arguments; the built-in classes do not. + +:mps:tag:`split.invariants` The client must ensure some invariants are met +before calling :c:func:`SegSplit()`: + +- :mps:tag:`split.inv.align` ``at`` must be appropriately aligned to the + arena alignment, and lie between the base and limit of ``seg``. + Justification: the split segments cannot be represented if this is + not so. + +- :mps:tag:`split.inv.buffer` If ``seg`` is attached to a buffer, the + buffered region must not include address ``at``. Justification: the + segment module is not in a position to know how (or whether) a pool + might wish to split a buffer. This permits the buffer to remain + attached to just one of the returned segments. + +:mps:tag:`split.state` Except as noted above, the segments returned have the +same properties as ``seg``. That is, their colour, summary, rankset, +nailedness etc. are set to the values of ``seg``. + +.. c:function:: Res SegMerge(Seg *mergedSegReturn, Seg segLo, Seg segHi, Bool withReservoirPermit, ...) + +:mps:tag:`merge` If successful, segments ``segLo`` and ``segHi`` are merged +together, yielding a segment which is returned in mergedSegReturn. +``segLo`` and ``segHi`` are effectively destroyed during this +operation (actually, one of them might be reused as the merged +segment). Segment subclasses may make use of the optional arguments; +the built-in classes do not. + +:mps:tag:`merge.invariants` The client must ensure some invariants are met +before calling :c:func:`SegMerge()`: + +- :mps:tag:`merge.inv.abut` The limit of ``segLo`` must be the same as the + base of ``segHi``. Justification: the merged segment cannot be + represented if this is not so. + +- :mps:tag:`merge.inv.buffer` One or other of ``segLo`` and ``segHi`` may + attached to a buffer, but not both. Justification: the segment + module does not support attachment of a single seg to 2 buffers. + +- :mps:tag:`merge.inv.similar` ``segLo`` and ``segHi`` must be sufficiently + similar. Two segments are sufficiently similar if they have + identical values for each of the following fields: ``class``, + ``sm``, ``grey``, ``white``, ``nailed``, ``rankSet``. Justification: + there is no single choice of behaviour for cases where these fields + are not identical. The pool class must make it's own choices about + this if it wishes to permit more flexible merging. If so, it should + be a simple matter for the pool to arrange for the segments to look + sufficiently similar before calling :c:func:`SegMerge()`. + +:mps:tag:`merge.state` The merged segment will share the same state as +``segLo`` and ``segHi`` for those fields which are identical (see +:mps:ref:`.merge.inv.similar`). The summary will be the union of the summaries +of ``segLo`` and ``segHi``. + + +Extensibility +------------- + +Splitting and merging +..................... + +.. c:type:: Res (*SegSplitMethod)(Seg seg, Seg segHi, Addr base, Addr mid, Addr limit, Bool withReservoirPermit) + +:mps:tag:`method.split` Segment subclasses may extend the support for +segment splitting by defining their own "split" method. On entry, +``seg`` is a segment with region ``[base,limit)``, ``segHi`` is +uninitialized, ``mid`` is the address at which the segment is to be +split. The method is responsible for destructively modifying ``seg`` +and initializing ``segHi`` so that on exit ``seg`` is a segment with +region ``[base,mid)`` and ``segHi`` is a segment with region +``[mid,limit)``. Usually a method would only directly modify the +fields defined for the segment subclass. This might involve +allocation, which may use the reservoir if ``withReservoirPermit`` is +:c:macro:`TRUE`. + +:mps:tag:`method.split.next` A split method should always call the next +method, either before or after any class-specific code (see +design.mps.protocol :mps:ref:`.overview.next-method`). + +.. c:type:: Res (*SegMergeMethod)(Seg seg, Seg segHi, Addr base, Addr mid, Addr limit, Bool withReservoirPermit) + +:mps:tag:`method.merge` Segment subclasses may extend the support for +segment merging by defining their own ``merge`` method. On entry, +``seg`` is a segment with region ``[base,mid)``, ``segHi`` is a +segment with region ``[mid,limit)``, The method is responsible for +destructively modifying ``seg`` and finishing ``segHi`` so that on +exit ``seg`` is a segment with region ``[base,limit)`` and ``segHi`` +is garbage. Usually a method would only modify the fields defined for +the segment subclass. This might involve allocation, which may use the +reservoir if ``withReservoirPermit`` is :c:macro:`TRUE`. + +:mps:tag:`method.merge.next` A merge method should always call the next +method, either before or after any class-specific code (see +design.mps.protocol.overview.next-method). + +:mps:tag:`split-merge.shield` Split and merge methods may assume that the +segments they are manipulating are not in the shield cache. + +:mps:tag:`split-merge.shield.flush` The shield cache is flushed before any +split or merge methods are invoked. + +:mps:tag:`split-merge.shield.re-flush` If a split or merge method performs +an operation on a segment which might cause the segment to be cached, +the method must flush the shield cache before returning or calling +another split or merge method. + +:mps:tag:`split-merge.fail` Split and merge methods might fail, in which +case segments ``seg`` and ``segHi`` must be equivalently valid and +configured at exit as they were according to the entry conditions. +It's simplest if the failure can be detected before calling the next +method (for example, by allocating any objects early in the method). + +:mps:tag:`split-merge.fail.anti` If it's not possible to detect failure +before calling the next method, the appropriate anti-method must be +used (see design.mps.protocol.guide.fail.after-next). Split methods +are anti-methods for merge methods, and vice-versa. + +:mps:tag:`split-merge.fail.anti.constrain` In general, care should be taken +when writing split and merge methods to ensure that they really are +anti-methods for each other. The anti-method must not fail if the +initial method succeeded. The anti-method should reverse any side +effects of the initial method, except where it's known to be safe to +avoid this (see :mps:ref:`.split-merge.fail.summary` for an example of a safe +case). + +:mps:tag:`split-merge.fail.anti.no` If this isn't possible (it might not be) +then the methods won't support after-next failure. This fact should be +documented, if the methods are intended to support further +specialization. Note that using va_arg with the ``args`` parameter is +sufficient to make it impossible to reverse all side effects. + +:mps:tag:`split-merge.fail.summary` The segment summary might not be +restored exactly after a failed merge operation. Each segment would be +left with a summary which is the union of the original summaries (see +:mps:ref:`.merge.state`). This increases the conservatism in the summaries, +but is otherwise safe. + +:mps:tag:`split-merge.unsupported` Segment classes need not support segment +merging at all. The function :c:func:`SegClassMixInNoSplitMerge()` is supplied +to set the split and merge methods to unsupporting methods that will +report an error in checking varieties. + + diff --git a/mps/manual/html/_sources/design/shield.txt b/mps/manual/html/_sources/design/shield.txt new file mode 100644 index 00000000000..653937a2449 --- /dev/null +++ b/mps/manual/html/_sources/design/shield.txt @@ -0,0 +1,167 @@ +.. _design-shield: + + +.. index:: + pair: shield; design + + +Shield +====== + +.. mps:prefix:: design.mps.shield + + +Introduction +------------ + +:mps:tag:`intro` This document contains a guide to the MPS Shield. There is +no historical initial design, but in its place there are some early +ideas and discussions: see :mps:ref:`.ideas`. + +:mps:tag:`readership` Any MPS developer. Not confidential. + + +Overview +-------- + +:mps:tag:`over` For incremental collection, we need *separate control* of +collector access and mutator (client) access to memory. The collector +must be able to incrementally scan objects, without the mutator being +able to see them yet. + +Unfortunately common OSs do not support different access levels +(protection maps) for different parts of the same process. + +The MPS Shield is an abstraction that does extra work to overcome this +limitation, and give the rest of the MPS the illusion that we can +control collector and mutator access separately. + + +Control of mutator access +------------------------- + +The MPS uses :c:func:`ShieldRaise()` and :c:func:`ShieldLower()` to forbid or +permit the mutator access to object memory (that is, memory allocated +by MPS). + +.. c:function:: void ShieldRaise(Arena arena, Seg seg, AccessSet mode) + + Prevent the mutator accessing the memory in the specified mode + (``AccessREAD``, ``AccessWRITE``, or both). + +.. c:function:: void ShieldLower(Arena arena, Seg seg, AccessSet mode) + + Allow the mutator to access the memory in the specified mode + (``AccessREAD``, ``AccessWRITE``, or both). + +If the mutator attempts an access that hits a shield, the MPS gets a +barrier hit (in the form of a fault, interrupt, exception), quickly +does some necessary work, and then makes the access succeed. + +Some objects (for example registers) cannot be hardware protected: the +only way to prevent mutator access to them is to halt all mutator +threads. The MPS uses :c:func:`ShieldSuspend()` and :c:func:`ShieldResume()` to do +this. + +.. c:function:: void ShieldSuspend(Arena arena) + + Stop all registered mutator threads. + +.. c:function:: void ShieldResume(Arena arena) + + Resume all registered mutator threads. + + +Control of collector access +--------------------------- + +When the collector wants to access object memory (that is, memory +allocated by MPS), it must first call :c:func:`ShieldEnter()`, then wrap any +accesses with a :c:func:`ShieldExpose()` and :c:func:`ShieldCover()` pair, and +finally call :c:func:`ShieldLeave()`. + +:c:func:`ShieldEnter()` and :c:func:`ShieldLeave()` are called by :c:func:`ArenaEnter()` +and :c:func:`ArenaLeave()` (approximately) -- so the shield is always +entered when we are within MPS code (approximately). + +:c:func:`ShieldExpose()` might for example be called around: + +- format-scan (when scanning); +- format-skip (when marking grains in a non-moving fix); +- format-isMoved and :c:func:`AddrCopy()` (during a copying fix); +- format-pad (during reclaim). + +Note that there is no need to call :c:func:`ShieldExpose()` when accessing +pool management memory such as bit tables. This is not object +memory, is never (legally) accessed by the mutator, and so is never +shielded. + +On common operating systems, the only way to allow collector access is +to allow access from the whole process, including the mutator. So if +the Shield is asked to allow collector access but deny mutator access, +it will halt all mutator threads to prevent any mutator access. The +Shield performs suspension and restart; normal collector code does not +need to worry about it. + +Collector code can make multiple sequential, overlapping, or nested +calls to :c:func:`ShieldExpose()` on the same segment, as long as each is +balanced by a corresponding :c:func:`ShieldCover()` before :c:func:`ShieldLeave()` +is called). A usage count is maintained on each segment in +``seg->depth``: a positive "depth" means a positive number of +outstanding *reasons* why the segment must be exposed to the collector. +When the usage count reaches zero, there is no longer any reason the +segment should be unprotected, and the Shield could re-instate +hardware protection. + +However, as a performance-improving hysteresis, the Shield defers +re-protection, maintaining a cache of the last ``ShieldCacheSIZE`` +times a segment no longer had a reason to be collector-accessible. +Presence in the cache counts as a reason: segments in the cache have +``seg->depth`` increased by one. As segments get pushed out of the +cache, or at :c:func:`ShieldLeave()`, this artificial reason is +decremented from ``seg->depth``, and (if ``seg->depth`` is now zero) +the deferred reinstatement of hardware protection happens. + +So whenever hardware protection is temporarily removed to allow +collector access, there is a *nurse* that will ensure this protection +is re-established: the nurse is either the balancing :c:func:`ShieldCover()` +call in collector code, or an entry in the shield cache. + +.. note:: + + 1. Why is there a fixed-size cache? This is not the simple + approach! All we need is a chain of segs that might need their + hardware protection to be sync'd with their shield mode. Head + in the shield, and one pointer in each seg struct. I guess we + try hard to avoid bloating :c:type:`SegStruct` (to maintain residency + in the processor cache). But is 16 the right size? A cache-miss + wastes two kernel calls. + + 2. I don't like the cache code. For example, why does + :c:func:`ShieldFlush()` break out early if ``arena->shDepth`` is 0? + This should never happen until the cache is completely flushed, + that is, we have reached ``shCacheLimit``. Why does + :c:func:`ShieldFlush()` not reset ``shCacheLimit``? Why does + :c:func:`flush()` silently accept :c:macro:`NULL` cache entries? + + 3. Why is ``seg->depth`` never checked for overflow? It is only a + 4-bit-wide bit field, currently. + + Richard Kistruck, 2006-12-19. + + +Initial ideas +------------- + +:mps:tag:`ideas` There never was an initial design document, but +[RB_1995-11-29]_ and [RB_1995-11-30]_ contain some initial ideas. + + +References +---------- + +.. [RB_1995-11-29] Richard Brooksby. Harlequin. 1995-11-29. "`Shield protocol for barriers `__". + +.. [RB_1995-11-30] Richard Brooksby. Harlequin. 1995-11-30. "`Exegesis of Incremental Tracing `__". + + diff --git a/mps/manual/html/_sources/design/sig.txt b/mps/manual/html/_sources/design/sig.txt index 674a47e2bfd..d450855903d 100644 --- a/mps/manual/html/_sources/design/sig.txt +++ b/mps/manual/html/_sources/design/sig.txt @@ -1,7 +1,159 @@ +.. _design-sig: + + .. index:: pair: structure signatures; design single: signatures -.. _design-sig: -.. include:: ../../converted/sig.rst +Signatures in the MPS +===================== + +.. mps:prefix:: design.mps.sig + pair: structure signatures; design + single: signatures + + +Introduction +------------ +Integrity of data structures is absolutely critical to the cost of +deploying the Memory Pool System. Memory corruption and memory +management bugs are incredibly hard to detect and debug, often +manifesting themselves hours or days after they occur. One of the key +ways the MPS detects corruption or the passing of illegal data is using +*signatures*. This simple technique has proved invaluable at catching +defects early. + + +Overview +-------- +Signatures are `magic numbers`_ which are written into structures when +they are created and invalidated (by overwriting with ``SigInvalid``) +when they are destroyed. They provide a limited form of run-time type +checking and dynamic scope checking. They are a simplified form of +"Structure Marking", a technique used in the Multics filesystem +[THVV_1995]_. + +.. _`magic numbers`: http://en.wikipedia.org/wiki/Magic_number_(programming) + + +Definitions +----------- +Nearly every structure should start with a field of type :c:type:`Sig` with the name +``sig``. For example:: + + typedef struct mps_message_s { + Sig sig; /* */ + Arena arena; /* owning arena */ + MessageClass class; /* Message Class Structure */ + Clock postedClock; /* mps_clock() at post time, or 0 */ + RingStruct queueRing; /* Message queue ring */ + } MessageStruct; + +There must also be a definition for the valid value for that signature:: + + #define MessageSig ((Sig)0x5193e559) /* SIG MESSaGe */ + +This is a 32-bit hex constant, spelled according to guide.hex.trans_:: + + ABCDEFGHIJKLMNOPQRSTUVWXYZ + ABCDEF9811C7340BC6520F3812 + +.. _guide.hex.trans: guide.hex.trans + +This allows the structure to be recognised when looking at memory in a hex +dump or memory window, or found using memory searches. + + +Init and Finish +--------------- +When the structure is initialised, the signature is initialised as the +*last* action, just before validating it. (Think of it as putting your +signature at the bottom of a document to say it's done.) This ensures +that the structure will appear invalid until it is completely initialized +and ready to use. For example:: + + void MessageInit(...) { + ... + message->arena = arena; + message->class = class; + RingInit(&message->queueRing); + message->postedClock = 0; + message->sig = MessageSig; + AVERT(Message, message); + } + +When the structure is finished, the signature is invalidated as the +*first* action, ensuring that the structure appears invalid while it is +being torn down. For example:: + + void MessageFinish(Message message) + { + AVERT(Message, message); + AVER(RingIsSingle(&message->queueRing)); + + message->sig = SigInvalid; + RingFinish(&message->queueRing); + } + +Do not do anything else with signatures. See :mps:ref:`.rule.purpose`. + + +Checking +-------- +The signature is checked in various ways. Every function that takes a +(pointer to) a signed structure should check its argument using the +:c:macro:`AVERT` macro. This macro has different definitions depending on how +the MPS is compiled (see design.mps.config.def.var_). It may simply check +the signature directly, or call the full checking function for the +structure. + +.. _design.mps.config.def.var: config#def-var + +The checking function for the structure should also validate the +signature as its first step using the :c:func:`CHECKS()` macro (see +check.h_). For example:: + + Bool MessageCheck(Message message) + { + CHECKS(Message, message); + CHECKU(Arena, message->arena); + CHECKD(MessageClass, message->class); + ... + +This combination makes it extremely difficult to get an object of the +wrong type, an uninitialized object, or a dead object, or a random +pointer into a function. + +.. _check.h: ../code/check.h + +Rules +----- +:mps:tag:`rule.purpose` **Do not** use signatures for any other purpose. For +example, don't use them to make any actual decisions within the code. +They must not be used to discriminate between structure variants (or +union members). They must not be used to try to detect *whether* a +structure has been initialised or finished. They are there to +double-check whether these facts are true. They lose their value as a +consistency check if the code uses them as well. + + +Tools +----- +:mps:tag:`test.uniq` The Unix command:: + + sed -n '/^#define [a-zA-Z]*Sig/s/[^(]*(/(/p' code/*.[ch] | sort | uniq -c + +will display all signatures defined in the MPS along with a count of how +many times they are defined. If any counts are greater than 1, then the +same signature value is being used for different signatures. This is +undesirable and the problem should be investigated. + + +References +---------- +.. [RB_1995-08-25] Richard Brooksby. Harlequin. 1995-08-25. "`design.mps.sig: The design of the Memory Pool System Signature System `__". + +.. [THVV_1995] Tom Van Vleck. 1995. "`Structure Marking `__". + + diff --git a/mps/manual/html/_sources/design/splay.txt b/mps/manual/html/_sources/design/splay.txt index 79400def8b5..2b1ab560fc2 100644 --- a/mps/manual/html/_sources/design/splay.txt +++ b/mps/manual/html/_sources/design/splay.txt @@ -1,6 +1,914 @@ +.. _design-splay: + + .. index:: pair: splay trees; design -.. _design-splay: -.. include:: ../../converted/splay.rst +Splay trees +=========== + +.. mps:prefix:: design.mps.splay + + +Introduction +------------ + +:mps:tag:`intro` This document explains the design of impl.c.splay, an +implementation of Splay Trees, including its interface and +implementation. + +:mps:tag:`readership` This document is intended for any MM developer. + +:mps:tag:`source` The primary sources for this design are paper.st85(0) and +paper.sleator96(0). 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. + +:mps:tag:`background` The following background documents influence the design: +guide.impl.c.adt(0). + + +Overview +-------- + +:mps:tag:`overview` Splay trees are a form of binary tree where each access +brings the accessed element (or the nearest element) to the root of +the tree. The restructuring of the tree caused by the access gives +excellent amortised performance, as the splay tree adapts its shape to +usage patterns. Unused nodes have essentially no time overhead. + + +Definitions +----------- + +:mps:tag:`def.splay-tree` A "Splay Tree" is a self-adjusting binary tree as +described in paper.st85(0), paper.sleator96(0). + +:mps:tag:`def.node` A "node" is used in the typical datastructure sense to +mean an element of a tree (see also :mps:ref:`.type.splay.node`). + +:mps:tag:`def.key` A "key" is a value associated with each node; the keys +are totally ordered by a client provided comparator. + +:mps:tag:`def.comparator` A "comparator" is a function that compares keys to +determine their ordering (see also :mps:ref:`.type.splay.compare.method`). + +:mps:tag:`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. + +:mps:tag:`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. + +:mps:tag:`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. + +:mps:tag:`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*. + +:mps:tag:`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. + +:mps:tag:`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. + +:mps:tag:`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 +client property values. See also :mps:ref:`.prop` below. + + +Requirements +------------ + +:mps:tag:`req` These requirements are drawn from those implied by +design.mps.poolmv2, design.mps.poolmvff(1), design.mps.cbs(2) and +general inferred MPS requirements. + +:mps:tag:`req.order` Must maintain a set of abstract keys which is totally +ordered for a comparator. + +:mps:tag:`req.tree` The keys must be associated with nodes arranged in a +Splay Tree. + +:mps:tag:`req.splay` Common operations must balance the tree by splaying it, +to achieve low amortized cost (see paper.st85(0)). + +:mps:tag:`req.add` Must be able to add new members. This is a common +operation. + +:mps:tag:`req.remove` Must be able to remove members. This is a common +operation. + +:mps:tag:`req.locate` Must be able to locate a member, given a key. This is +a common operation. + +:mps:tag:`req.neighbours` Must be able to locate the neighbouring members +(in order) of a non-member, given a key (see :mps:ref:`.def.neighbour`). This +is a common operation. + +:mps:tag:`req.iterate` Must be able to iterate over all members in order +with reasonable efficiency. + +:mps:tag:`req.protocol` Must support detection of protocol violations. + +:mps:tag:`req.debug` Must support debugging of clients. + +:mps:tag:`req.stack` Must do all non-debugging operations with stack usage +bounded by a constant size. + +:mps:tag:`req.adapt` Must adapt to regularities in usage pattern, for better +performance. + +:mps:tag:`req.property` Must permit a client to associate a client property +(such as a size) with each node in the tree. + +:mps:tag:`req.property.change` Must permit a client to dynamically reassign +client properties to nodes in the tree. This is a common operation. + +:mps:tag:`req.property.find` Must support rapid finding of the first and +last nodes which have a suitably large value for their client +property. This is a common operation. + +:mps:tag:`req.root` Must be able to find the root of a splay tree (if one +exists). + + +External types +-------------- + +.. c:type:: struct SplayTreeStruct SplayTreeStruct +.. c:type:: struct SplayTreeStruct *SplayTree + +:mps:tag:`type.splay.tree` :c:type:`SplayTree` is the type of the main object at +the root of the splay tree. It is intended that the +:c:type:`SplayTreeStruct` can be embedded in another structure (see +:mps:ref:`.usage.client-tree` for an example). No convenience functions are +provided for allocation or deallocation. + +.. c:type:: struct SplayNodeStruct SplayNodeStruct +.. c:type:: struct SplayNodeStruct *SplayNode + +:mps:tag:`type.splay.node` :c:type:`SplayNode` is the type of a node of the splay +tree. :c:type:`SplayNodeStruct` contains no fields to store the key +associated with the node, or the client property. Again, it is +intended that the :c:type:`SplayNodeStruct` can be embedded in another +structure, and that this is how the association will be made (see +:mps:ref:`.usage.client-node` for an example). No convenience functions are +provided for allocation or deallocation. + +.. c:type:: Compare (*SplayCompareMethod)(void *key, SplayNode node) + +:mps:tag:`type.splay.compare.method` A function of type +:c:type:`SplayCompareMethod` is required to compare ``key`` with the key the +client associates with that splay tree node ``node``, and return the +appropriate Compare value (see :mps:ref:`.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 +:mps:ref:`.type.splay.node`), and the splaying operations compare keys with +nodes (see :mps:ref:`.impl.splay`). + +.. c:type:: Res (*SplayNodeDescribeMethod)(SplayNode node, mps_lib_FILE *stream) + +:mps:tag:`type.splay.node.describe.method` A function of type +:c:type:`SplayNodeDescribeMethod` is required to write (via :c:func:`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. + +.. c:type:: Bool (*SplayTestNodeMethod)(SplayTree tree, SplayNode node, void *closureP, unsigned long closureS) + +:mps:tag:`type.splay.test.node.method` A function of type +:c:type:`SplayTestNodeMethod` required to determine whether the node itself +meets some client determined property (see :mps:ref:`.prop` and +:mps:ref:`.usage.test.node` for an example). Parameters ``closureP`` and +``closureS`` describe the environment for the function (see +:mps:ref:`.function.splay.find.first` and :mps:ref:`.function.splay.find.last`). + +.. c:type:: Bool (*SplayTestTreeMethod)(SplayTree tree, SplayNode node, void *closureP, unsigned long closureS) + +:mps:tag:`type.splay.test.tree.method` A function of type +:c:type:`SplayTestTreeMethod` is required to determine whether any of the +nodes in the sub-tree rooted at the given node meet some client +determined property (see :mps:ref:`.prop` and :mps:ref:`.usage.test.tree` for an +example). In particular, it must be a precise (not conservative) +indication of whether there are any nodes in the sub-tree for which +the ``testNode`` method (see :mps:ref:`.type.splay.test.node.method`) would +return :c:macro:`TRUE`. Parameters ``closureP`` and ``closureS`` describe the +environment for the function (see :mps:ref:`.function.splay.find.first` and +:mps:ref:`.function.splay.find.last`). + +.. c:type:: void (*SplayUpdateNodeMethod)(SplayTree tree, SplayNode node, SplayNode leftChild, SplayNode rightChild) + +:mps:tag:`type.splay.update.node.method` A function of type +:c:type:`SplayUpdateNodeMethod` is required to update any client +datastructures associated with a node to maintain some client +determined property (see :mps:ref:`.prop`) given that the children of the node +have changed. If the node does not have one or both children, then +:c:macro:`NULL` will be passed as the relevant parameter. (See +:mps:ref:`.usage.callback` for an example) + + +External functions +------------------ + +:mps:tag:`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 (:mps:ref:`.type.splay.compare.method`, +:mps:ref:`.type.splay.test.node.method`, :mps:ref:`.type.splay.test.tree.method`, +:mps:ref:`.type.splay.update.node.method`) do not call functions of the splay +module. + +.. c:function:: Bool SplayTreeCheck(SplayTree tree) + +:mps:tag:`function.splay.tree.check` This is a check function for the +SplayTree type (see guide.impl.c.adt.method.check & +design.mps.check(0)). + +.. c:function:: Bool SplayNodeCheck(SplayNode node) + +:mps:tag:`function.splay.node.check` This is a check function for the +:c:type:`SplayNode` type (see guide.impl.c.adt.method.check & +design.mps.check(0)). + +.. c:function:: void SplayTreeInit(SplayTree tree, SplayCompareMethod compare, SplayUpdateNodeMethod updateNode) + +:mps:tag:`function.splay.tree.init` This function initialises a +:c:type:`SplayTree` (see guide.impl.c.adt.method.init). It requires a +``compare`` method that defines a total ordering on nodes (see +:mps:ref:`.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 +``SplayTrivUpdateNode`` may be used for this method if there is no +need to maintain client properties. (See :mps:ref:`.usage.initialization` for +an example use). + +.. c:function:: void SplayTreeFinish(SplayTree tree) + +:mps:tag:`function.splay.tree.finish` This function clears the fields of a +:c:type:`SplayTree` (see guide.impl.c.adt.method.finish). Note that it does +not attempt to finish or deallocate any associated :c:type:`SplayNode` +objects; clients wishing to destroy a non-empty :c:type:`SplayTree` must +first explicitly descend the tree and call :c:func:`SplayNodeFinish()` on +each node from the bottom up. + +.. c:function:: void SplayNodeInit(SplayNode node) + +:mps:tag:`function.splay.node.init` This function initialises a +:c:type:`SplayNode` (see guide.impl.c.adt.method.init). + +.. c:function:: void SplayNodeFinish(SplayNode node) + +:mps:tag:`function.splay.node.finish` This function clears the fields of a +:c:type:`SplayNode` (see guide.impl.c.adt.method.finish). Note that it does +not attempt to finish or deallocate any referenced :c:type:`SplayNode` +objects (see.function.splay.tree.finish). + +.. c:function:: Bool SplayRoot(SplayNode *nodeReturn, SplayTree tree) + +:mps:tag:`function.splay.root` This function returns the root node of the +tree, if any (see :mps:ref:`.req.root`). If the tree is empty, :c:macro:`FALSE` is +returned and ``*nodeReturn`` is not changed. Otherwise, :c:macro:`TRUE` is +returned and ``*nodeReturn`` is set to the root. + +.. c:function:: Res SplayTreeInsert(SplayTree tree, SplayNode node, void *key) + +:mps:tag:`function.splay.tree.insert` This function is used to insert into a +splay tree a new node which is associated with the supplied key (see +:mps:ref:`.req.add`). It first splays the tree at the key. If an attempt is +made to insert a node that compares ``CompareEQUAL`` to an existing +node in the tree, then ``ResFAIL`` will be returned and the node will +not be inserted. (See :mps:ref:`.usage.insert` for an example use). + +.. c:function:: Res SplayTreeDelete(SplayTree tree, SplayNode node, void *key) + +:mps:tag:`function.splay.tree.delete` This function is used to delete from a +splay tree a node which is associated with the supplied key (see +:mps:ref:`.req.remove`). If the tree does not contain the given node, or the +given node does not compare ``CompareEQUAL`` with the given key, then +``ResFAIL`` will be returned, and the node will not be deleted. The +function first splays the tree at the given key. (See :mps:ref:`.usage.delete` +for an example use). + +.. c:function:: Res SplayTreeSearch(SplayNode *nodeReturn, SplayTree tree, void *key) + +:mps:tag:`function.splay.tree.search` This function searches the splay tree +for a node that compares ``CompareEQUAL`` to the given key (see +:mps:ref:`.req.locate`). It splays the tree at the key. It returns ``ResFAIL`` +if there is no such node in the tree, otherwise ``*nodeReturn`` will +be set to the node. + +.. c:function:: Res SplayTreeNeighbours(SplayNode *leftReturn, SplayNode *rightReturn, SplayTree tree, void *key) + +:mps:tag:`function.splay.tree.neighbours` This function searches a splay +tree for the two nodes that are the neighbours of the given key (see +:mps:ref:`.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 :c:macro:`NULL`. ``*rightReturn`` will +be the neighbour which compares greater than the key if such a +neighbour exists; otherwise it will be :c:macro:`NULL`. The function returns +``ResFAIL`` if any node in the tree compares ``CompareEQUAL`` with the +given key. (See :mps:ref:`.usage.insert` for an example use). + +.. c:function:: SplayNode SplayTreeFirst(SplayTree tree, void *zeroKey) + +:mps:tag:`function.splay.tree.first` This function splays the tree at the +first node, and returns that node (see :mps:ref:`.req.iterate`). The supplied +key should compare ``CompareLESS`` with all nodes in the tree. It will +return :c:macro:`NULL` if the tree has no nodes. + +.. c:function:: SplayNode SplayTreeNext(SplayTree tree, SplayNode oldNode, void *oldKey) + +:mps:tag:`function.splay.tree.next` This function receives a node and key +and returns the successor node to that node (see :mps:ref:`.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 +:mps:ref:`.future.parent`). + +.. c:function:: Res SplayTreeDescribe(SplayTree tree, mps_lib_FILE *stream, SplayNodeDescribeMethod nodeDescribe) + +:mps:tag:`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 :mps:ref:`.req.debug`). + +.. c:function:: Bool SplayFindFirst(SplayNode *nodeReturn, SplayTree tree, SplayTestNodeMethod testNode, SplayTestTreeMethod testTree, void *closureP, unsigned long closureS) + +:mps:tag:`function.splay.find.first` :c:func:`SplayFindFirst()` finds the first node +in the tree that satisfies some client property (as determined by the +``testNode`` and ``testTree`` methods) (see :mps:ref:`.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 :c:macro:`FALSE` +is returned, otherwise ``*nodeReturn`` is set to the node. (See +:mps:ref:`.usage.delete` for an example use). + +.. c:function:: Bool SplayFindFirst(SplayNode *nodeReturn, SplayTree tree, SplayTestNodeMethod testNode, SplayTestTreeMethod testTree, void *closureP, unsigned long closureS) + +:mps:tag:`function.splay.find.last` :c:func:`SplayFindLast()` finds the last node +in the tree that satisfies some client property (as determined by the +``testNode`` and ``testTree`` methods) (see :mps:ref:`.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 :c:macro:`FALSE` +is returned, otherwise ``*nodeReturn`` is set to the node. + +.. c:function:: void SplayNodeRefresh(SplayTree tree, SplayNode node, void *key) + +:mps:tag:`function.splay.node.refresh` :c:func:`SplayNodeRefresh()` must be called +whenever the client property (see :mps:ref:`.prop`) at a node changes (see +:mps:ref:`.req.property.change`). It will call the ``updateNode`` method on +the given node, and any other nodes that may require update. The +client key for the node must also be supplied; the function splays the +tree at this key. (See :mps:ref:`.usage.insert` for an example use). + + +Client-determined properties +---------------------------- + +:mps:tag:`prop` To support :mps:ref:`.req.property.find`, this splay tree +implementation provides additional features to permit clients to cache +maximum (or minimum) values of client properties for all the nodes in +a subtree. The splay tree implementation uses the cached values as +part of ``SplayFindFirst`` and ``SplayFindLast`` via the ``testNode`` +and ``testTree`` methods. The client is free to choose how to +represent the client property, and how to compute and store the cached +value. + +:mps:tag:`prop.update` The cached values depend upon the topology of the +tree, which may vary as a result of operations on the tree. The client +is given the opportunity to compute new cache values whenever +necessary, via the ``updateNode`` method (see +:mps:ref:`.function.splay.tree.init`). This happens whenever the tree is +restructured. The client may use the ``SplayNodeRefresh`` method to +indicate that the client attributes at a node have changed (see +:mps:ref:`.req.property.change`). A call to ``SplayNodeRefresh`` splays the +tree at the specified node, which may provoke calls to the +``updateNode`` method as a result of the tree restructuring. The +``updateNode`` method will also be called whenever a new splay node is +inserted into the tree. + +:mps:tag:`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 +cached value in each node the size of the largest block in the subtree +rooted at that node. This will permit a fast search for the first or +last block of at least a given size. See :mps:ref:`.usage.callback` for an +example ``updateNode`` method for such a client. + +:mps:tag:`prop.ops` The splay operations must cause client properties for +nodes to be updated in the following circumstances:- (see :mps:ref:`.impl` for +details): + +:mps:tag:`prop.ops.rotate` rotate left, rotate right -- We need to update +the value at the original root, and the new root, in that order. + +:mps:tag:`prop.ops.link` link left, link right -- We know that the line of +right descent from the root of the left tree and the line of left +descent from the root of the right tree will both need to be updated. +This is performed at the assembly stage. (We could update these chains +every time we do a link left or link right instead, but this would be +less efficient) + +:mps:tag:`prop.ops.assemble` assemble -- This operation also invalidates the +lines of right and left descent of the left and right trees +respectively which need to be updated (see below). It also invalidates +the root which must be updated last. + +:mps:tag:`prop.ops.assemble.reverse` To correct the chains of the left and +right trees without requiring stack or high complexity, we use a +judicious amount of pointer reversal. + +:mps:tag:`prop.ops.assemble.traverse` During the assembly, after the root's +children have been transplanted, we correct the chains of the left and +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 +:mps:ref:`.future.reverse` for an alternative approach). + + +Usage +----- + +:mps:tag:`usage` Here's a simple example of a client which uses a splay tree +to implement an address ordered tree of free blocks. The significant +client usages of the splay tree interface might look as follows:- + +:mps:tag:`usage.client-tree` Tree structure to embed a :c:type:`SplayTree` (see +:mps:ref:`.type.splay.tree`):: + + typedef struct FreeTreeStruct { + SplayTreeStruct splayTree; /* Embedded splay tree */ + /* no obvious client fields for this simple example */ + } FreeTreeStruct; + +:mps:tag:`usage.client-node` Node structure to embed a SplayNode (see :mps:ref:`.type.splay.node`):: + + typedef struct FreeBlockStruct { + SplayNodeStruct splayNode; /* 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; + +:mps:tag:`usage.callback` updateNode callback method (see +:mps:ref:`.type.splay.update.node.method`):: + + void FreeBlockUpdateNode(SplayTree tree, SplayNode node, + SplayNode leftChild, SplayNode rightChild) + { + /* Compute the maximum size of any block in this subtree. */ + /* The value to cache is the maximum of the size of this block, */ + /* the cached value for the left subtree (if any) and the cached */ + /* value of the right subtree (if any) */ + + FreeBlock freeNode = FreeBlockOfSplayNode(node); + + Size maxSize = freeNode.size; + + if(leftChild != NULL) { + FreeBlock leftNode = FreeBlockOfSplayNode(leftChild); + if(leftNode.maxSize > maxSize) + maxSize = leftNode->maxSize; + } + + if(rightChild != NULL) { + FreeBlock rightNode = FreeBlockOfSplayNode(rightChild); + if(rightNode.maxSize > maxSize) + maxSize = rightNode->maxSize; + } + + freeNode->maxSize = maxSize; + } + +:mps:tag:`usage.compare` Comparison function (see :mps:ref:`.type.splay.compare.method`):: + + Compare FreeBlockCompare(void *key, SplayNode node) { + Addr base1, base2, limit2; + FreeBlock freeNode = FreeBlockOfSplayNode(node); + + base1 = (Addr *)key; + base2 = freeNode->base; + limit2 = AddrAdd(base2, freeNode->size); + + if (base1 < base2) + return CompareLESS; + else if (base1 >= limit2) + return CompareGREATER; + else + return CompareEQUAL; + } + +:mps:tag:`usage.test.tree` Test tree function (see +:mps:ref:`.type.splay.test.tree.method`):: + + Bool FreeBlockTestTree(SplayTree tree, SplayNode node + void *closureP, unsigned long 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(node); + return freeNode->maxSize >= size; + } + +:mps:tag:`usage.test.node` Test node function (see +:mps:ref:`.type.splay.test.node.method`):: + + Bool FreeBlockTestNode(SplayTree tree, SplayNode node + void *closureP, unsigned long 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(node); + return freeNode->size >= size; + } + + :mps:tag:`usage.initialization` Client's initialization function (see + :mps:ref:`.function.splay.tree.init`): + void FreeTreeInit(FreeTree tree) { + /* Initialize the embedded splay tree. */ + SplayTreeInit(&tree->splayTree, FreeBlockCompare, FreeBlockUpdateNode); + } + +:mps:tag:`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; + SplayNode leftNeighbour, rightNeighbour; + void *key = (void *)base; /* use the base of the block as the key */ + Res res; + + /* Look for any neighbouring blocks. (.function.splay.tree.neighbours) */ + res = SplayTreeNeighbours(&leftNeighbour, &rightNeighbour, + splayTree, key); + AVER(res == ResOK); /* this client doesn't duplicate free blocks */ + + /* Look to see if the neighbours are contiguous. */ + + if (leftNeighbour != NULL && + FreeBlockLimitOfSplayNode(leftNeighbour) == base) { + /* Inserted block is contiguous with left neighbour, so merge it. */ + /* 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 :mps:ref:`.function.splay.node.refresh` */ + SplayNodeRefresh(tree, leftNeighbour, key); + + } else if (rightNeighbour != NULL && + FreeBlockBaseOfSplayNode(rightNeighbour) == limit) { + /* Inserted block is contiguous with right neighbour, so merge it. */ + /* 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 :mps:ref:`.function.splay.node.refresh` */ + SplayNodeRefresh(tree, rightNeighbour, key); + + } else { + /* Not contiguous - so insert a new node */ + FreeBlock newBlock = (FreeBlock)allocate(sizeof(FreeBlockStruct)); + splayNode = &newBlock->splayNode; + + newBlock->base = base; + newBlock->size = AddrOffset(base, limit); + SplayNodeInit(splayNode); /* :mps:ref:`.function.splay.node.init` */ + /* :mps:ref:`.function.splay.tree.insert` */ + res = SplayTreeInsert(splayTree, splayNode, key); + AVER(res == ResOK); /* this client doesn't duplicate free blocks */ + } + } + +:mps:tag:`usage.delete` Client function to allocate the first block of a +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; + SplayNode splayNode; + Bool found; + + /* look for the first node of at least the given size. */ + /* closureP parameter is not used. See `.function.splay.find.first.`_ */ + found = SplayFindFirst(&splayNode, splayTree, + FreeBlockTestNode, FreeBlockTestTree, + NULL, (unsigned long)size); + + if (found) { + FreeBlock freeNode = FreeBlockOfSplayNode(splayNode); + Void *key = (void *)freeNode->base; /* use base of block as the key */ + Res res; + + /* allocate the block */ + *baseReturn = freeNode->base; + *sizeReturn = freeNode->size; + + /* remove the node from the splay tree - :mps:ref:`.function.splay.tree.delete` */ + res = SplayTreeDelete(splayTree, splayNode, key); + AVER(res == ResOK); /* Must be possible to delete node */ + + /* Delete the block */ + deallocate(freeNode, (sizeof(FreeBlockStruct)); + + return TRUE; + + } else { + /* No suitable block */ + return FALSE; + } + } + + +Implementation +-------------- + +:mps:tag:`impl` For more details of how splay trees work, see paper.st85(0). +For more details of how to implement operations on splay trees, see +paper.sleator96(0). Here we describe the operations involved. + + +Top-down splaying +................. + +:mps:tag:`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. + +:mps:tag:`impl.splay` The key to the operation of the splay tree is the +internal function :c:func:`SplaySplay()`. It searches the tree for a node +with a given key and returns whether it suceeded. 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 :c:func:`SplaySplay()`. (See +paper.st85(0)) + +:mps:tag:`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 +store the left tree and right tree in the right and left children +respectively of a "sides" node to eliminate some boundary conditions. +The initial condition is that the middle tree is the entire splay +tree, and the left and right trees are empty. We also keep pointers to +the last node in the left tree, and the first node in the right tree. +Note that, at all times, the three trees are each validly ordered, and +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. + +:mps:tag:`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. + +:mps:tag:`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 :mps:ref:`.impl.link.right`). + +:mps:tag:`impl.splay.zag` The "zag" case is where ``key > root``, and either: + +- ``key == root->right``; +- ``key < root->right && root->right->left == NULL``; or +- ``key > root->right && root->right->right == NULL``. + +The operation for the zag case is: link left (see :mps:ref:`.impl.link.left`). + +:mps:tag:`impl.splay.zig.zig` The "zig-zig" case is where + +- ``key < root && key < root->left && root->left->left != NULL``. + +The operation for the zig-zig case is: rotate right (see +:mps:ref:`.impl.rotate.right`) followed by link right (see +:mps:ref:`.impl.link.right`). + +:mps:tag:`impl.splay.zig.zag` The "zig-zag" case is where + +- ``key < root && key > root->left && root->left->right != NULL``. + +The operation for the zig-zag case is: link right (see +:mps:ref:`.impl.link.right`) followed by link left (see :mps:ref:`.impl.link.left`). + +:mps:tag:`impl.splay.zag.zig` The "zag-zig" case is where + +- ``key > root && key < root->right && root->right->left != NULL``. + +The operation for the zag-zig case is: link left (see +:mps:ref:`.impl.link.left`) followed by link right (see :mps:ref:`.impl.link.right`). + +:mps:tag:`impl.splay.zag.zag` The "zag-zag" case is where + +- ``key > root && key > root->right && root->right->right != NULL``. + +The operation for the zag-zag case is: rotate left (see +:mps:ref:`.impl.rotate.left`) followed by link left (see :mps:ref:`.impl.link.left`). + +:mps:tag:`impl.splay.terminal.null` A special terminal case is when + +- ``root == NULL``. + +This can only happen at the beginning, and cannot arise from the +operations above. In this case, the splay operation must return +:c:macro:`NULL`, and "not found". + +:mps:tag:`impl.splay.terminal.found` One typical terminal case is when + +- ``key == root``. + +This case is tested for at the beginning, in which case "found" is +returned immediately. If this case happens as a result of other +operations, the splay operation is complete, the three trees are +assembled (see :mps:ref:`.impl.assemble`), and "found" is returned. + +:mps:tag:`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 :mps:ref:`.impl.assemble`), and "not found" is returned. + +:mps:tag:`impl.rotate.left` The "rotate left" operation (see paper.st85(0) +Fig. 1) rearranges the middle tree as follows (where any of sub-trees +A, B and C may be empty): + +[missing diagram] + +:mps:tag:`impl.rotate.right` The "rotate right" operation (see paper.st85(0) +Fig. 1) rearranges the middle tree as follows (where any of sub-trees +A, B and C may be empty): + +[missing diagram] + +:mps:tag:`impl.link.left` The "link left" operation (see paper.st85(0) Fig. +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] + +The last node of the left tree is now x. + +:mps:tag:`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): + +[missing diagram] + +The first node of the right tree is now x. + +:mps:tag:`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): + +[missing diagram] + + +Top-level operations +.................... + +:mps:tag:`impl.insert` :c:func:`SplayTreeInsert()`: (See paper.sleator96(0), 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, +return failure. Otherwise, add the inserted node as a new root, with +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. + +:mps:tag:`impl.delete` :c:func:`SplayTreeDelete()`: (See paper.sleator96(0), 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 +(now at the root) has fewer than two children, replace it (as root), +with the non-null child or null. Otherwise, set the root of the tree +to be the left child (arbitrarily) of the node to be deleted, and +splay around the same key. The new root will be the last node in the +sub-tree and will have a null right child; this is set to be the right +child of the node to be deleted. + +:mps:tag:`impl.search` :c:func:`SplayTreeSearch()`: Splay the node around the +supplied key. If the splay found a matching node, return it; otherwise +return failure. + +:mps:tag:`impl.neighbours` :c:func:`SplayTreeNeighbours()`: Splay the tree around +the supplied key. If the splay found a matching node, return failure. +Otherwise, determine whether the (non-matching) found node is the left +or right neighbour of the key (by comparison with the key). Set the +tree root to be the right or left child of that first neighbour +respectively, and again splay the tree around the supplied key. The +new root will be the second neighbour, and will have a null left or +right child respectively. Set this null child to be the first +neighbour. Return the two neighbours. + +:mps:tag:`impl.neighbours.note` Note that it would be possible to implement +:c:func:`SplayTreeNeighbours()` with only one splay, and then a normal +binary tree search for the left or right neighbour of the root. This +would be a cheaper operation, but would give poorer amortised cost if +the call to :c:func:`SplayTreeNeighbours()` typically precedes a call to +:c:func:`SplayTreeInsert()` (which is expected to be a common usage +pattern - see :mps:ref:`.usage.insert`). It's also possible to implement +:c:func:`SplayTreeNeighbours()` by simply keeping track of both neighbours +during a single splay. This has about the same cost as a single splay, +and hence about the same amortised cost if the call to +:c:func:`SplayTreeNeighbours()` typically precedes a call to +:c:func:`SplayTreeInsert()`. + +:mps:tag:`impl.next` :c:func:`SplayTreeNext()`: Splay the tree around the supplied +``oldKey``. During iteration the "old node" found is probably already +at the root, in which case this will be a null operation with little +cost. If this old node has no right child, return :c:macro:`NULL`. Otherwise, +split the tree into a right tree (which contains just the right child +of the old node) and a left tree (which contains the old node, its +left child and no right child). The next node is the first node in the +right tree. Find this by splaying the right tree around ``oldKey`` +(which is known to compare ``CompareLESS`` than any keys in the right +tree). Rejoin the full tree, using the right tree as the root and +setting the left child of root to be the left tree. Return the root of +this tree. + + +Testing +------- + +:mps:tag:`test` There is no plan to test splay trees directly. It is +believed that the testing described in design.mps.cbs.test will be +sufficient to test this implementation. + + +Error Handling +-------------- + +:mps:tag:`error` This module detects and reports most common classes of +protocol error. The cases it doesn't handle will result in undefined +behaviour and probably cause an :c:macro:`AVER` to fire. These are: + +:mps:tag:`error.bad-pointer` Passing an invalid pointer in place of a +:c:type:`SplayTree` or :c:type:`SplayNode`. + +:mps:tag:`error.bad-compare` Initialising a :c:type:`SplayTree` with a compare +function that is not a valid compare function, or which doesn't +implement a total ordering on splay nodes. + +:mps:tag:`error.bad-describe` Passing an invalid describe method to +:c:func:`SplayTreeDescribe()`. + +:mps:tag:`error.out-of-stack` Stack exhaustion under :c:func:`SplayTreeDescribe()`. + + +Future +------ + +:mps:tag:`future.tree` It would be possible to split the splay tree module +into two: one that implements binary trees; and one that implements +splay trees on top of a binary tree. + +:mps:tag:`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 :mps:ref:`.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 +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 +distinctions, or steal some bits from the pointers. + +:mps:tag:`future.reverse` The assembly phase could be made more efficient if +the link left and link right operations were modified to add to the +left and right trees with pointers reversed. This would remove the +need for the assembly phase to reverse them. + + diff --git a/mps/manual/html/_sources/design/sso1al.txt b/mps/manual/html/_sources/design/sso1al.txt new file mode 100644 index 00000000000..bad65430022 --- /dev/null +++ b/mps/manual/html/_sources/design/sso1al.txt @@ -0,0 +1,131 @@ +.. _design-sso1al: + + +.. index:: + pair: Digital Unix on Alpha stack scanner; design + pair: Digital Unix on Alpha; stack scanner design + + +Stack scanner for Digital Unix on Alpha +======================================= + +.. mps:prefix:: design.mps.sso1al + pair: Digital Unix on Alpha stack scanner; design + pair: Digital Unix on Alpha; stack scanner design + +.. warning:: + + As of 2013-05-26, the MPS is no longer supported on Digital Unix, + so this document is only of historical interest. + + +Introduction +------------ + +:mps:tag:`readership` Any MPS developer. + +:mps:tag:`intro` This is the design for Stack Scanner module that runs on +Digital UNIX / Alpha systems (See os.o1 and arch.al). The design +adheres to the general design and interface described (probably not +described actually) in design.mps.ss. + +:mps:tag:`source.alpha` book.digital96 (Alpha Architecture Handbook) +describes the Alpha Architecture independently of any particular +implementation. The instruction mnemonics and the semantics for each +instruction are specified in that document. + +[DEC_Assembler]_ describes the assembler syntax and assembler +directives. It also summarises the calling conventions used. Chapters +1 and 6 were especially useful, especially chapter 6. + +[DEC_Alpha_Calling_Standard]_ describes the calling conventions used +for Digital Alpha systems. Chapter 2 was useful. But the whole +document was not used as much as the previous 2 documents. + + +Definitions +----------- + +:mps:tag:`def.saved` Saved Register. A saved register is one whose value is defined to +be preserved across a procedure call according to the Calling Standard. They +are ``$9``--``$15``, ``$26``, and ``$30``. ``$30`` is the stack pointer. + +:mps:tag:`def.non-saved` Non-Saved Register. A non-save register is a +register that is assumed to be modified across a procedure call +according to the Calling Standard. + +:mps:tag:`def.tos` Top of Stack. The top of stack is the youngest portion of +the stack. + +:mps:tag:`def.bos` Bottom of Stack. The bottom of stack is the oldest +portion of the stack. + +:mps:tag:`def.base` Base. Of a range of addresses, the base is the lowest +address in the range. + +:mps:tag:`def.limit` Limit. Of a range of addresses, the limit is "one past" +the highest address in the range. + + +Overview +-------- + +:mps:tag:`overview` The registers and the stack need to be scanned. This is +achieved by storing the contents of the registers into a frame at the +top of the stack and then passing the base and limit of the stack +region, including the newly created frame, to the function +:c:func:`TraceScanAreaTagged()`. :c:func:`TraceScanAreaTagged()` performs the +actual scanning and fixing. + + +Detail Design +------------- + +Functions +......... + +:mps:tag:`fun.stackscan` :c:func:`StackScan()` + +:mps:tag:`fun.stackscan.asm` The function is written in assembler. +:mps:tag:`fun.stackscan.asm.justify` This is because the machine registers +need to be examined, and it is only possible to access the machine +registers using assembler. + +:mps:tag:`fun.stackscan.entry` On entry to this procedure all the non-saved +(temporary) registers that contain live pointers must have been saved +in some root (usually the stack) by the mutator (otherwise it would +lose the values). Therefore only the saved registers need to be stored +by this procedure. + +:mps:tag:`fun.stackscan.assume.saved` We assume that all the saved registers +are roots. This is conservative since some of the saved registers +might not be used. + +:mps:tag:`fun.stackscan.frame` A frame is be created on the top of the +stack. :mps:tag:`fun.stackscan.frame.justify` This frame is used to store +the saved registers into so that they can be scanned. + +:mps:tag:`fun.stackscan.save` All the saved registers, apart from $30 the +stack pointer, are to be stored in the frame. +:mps:tag:`fun.stackscan.save.justify` This is so that they can be scanned. +The stack pointer itself is not scanned as the stack is assumed to be +a root (and therefore a priori alive). + +:mps:tag:`fun.stackscan.call` :c:func:`TraceScanAreaTagged()` is called with the +current stack pointer as the base and the (passed in) ``StackBot`` as +the limit of the region to be scanned. :mps:tag:`fun.stackscan.call.justify` +This function does the actual scanning. The Stack on Alpha systems +grows down so the stack pointer (which points to the top of the stack) +is lower in memory than the bottom of the stack. + +:mps:tag:`fun.stackscan.return` The return value from +:c:func:`TraceScanAreaTagged()` is used as the return value for +:c:func:`StackScan()`. + + +References +---------- + +.. [DEC_Assembler] Digital Equipment Corporation. 1996; . .. [DEC_Alpha_Calling_Standard] "Calling Standard for Alpha Systems"; Digital Equipment Corporation. 1996. "`Assembly Language Programmer's Guide `__". + + diff --git a/mps/manual/html/_sources/design/telemetry.txt b/mps/manual/html/_sources/design/telemetry.txt index 58b119aff6b..e9e682896ac 100644 --- a/mps/manual/html/_sources/design/telemetry.txt +++ b/mps/manual/html/_sources/design/telemetry.txt @@ -1,6 +1,434 @@ +.. _design-telemetry: + + .. index:: pair: telemetry; design -.. _design-telemetry: -.. include:: ../../converted/telemetry.rst +Telemetry +========= + +.. mps:prefix:: design.mps.telemetry + + +Introduction +------------ + +:mps:tag:`intro` This documents the design of the telemetry mechanism within +the MPS. + +:mps:tag:`readership` This document is intended for any MPS developer. + +:mps:tag:`source` Various meetings and brainstorms, including +meeting.general.1997-03-04(0), mail.richard.1997-07-03.17-01(0), +mail.gavinm.1997-05-01.12-40(0). + + +Overview +-------- + +:mps:tag:`over` Telemetry permits the emission of events from the MPS. These +can be used to drive a graphical tool, or to debug, or whatever. The +system is flexible and robust, but doesn't require heavy support from +the client. + + +Requirements +------------ + +:mps:tag:`req.simple` It must be possible to generate code both for the MPS +and any tool without using complicated build tools. + +:mps:tag:`req.open` We must not constrain the nature of events before we are +certain of what we want them to be. + +:mps:tag:`req.multi` We must be able to send events to multiple streams. + +:mps:tag:`req.share` It must be possible to share event descriptions between +the MPS and any tool. + +:mps:tag:`req.version` It must be possible to version the set of events so +that any tool can detect whether it can understand the MPS. + +:mps:tag:`req.back` Tools should be able to understand older and newer +version of the MPS, so far as is appropriate. + +:mps:tag:`req.type` It must be possible to transmit a rich variety of types +to the tool, including doubles, and strings. + +:mps:tag:`req.port` It must be possible to transmit and receive events +between different platforms. + +:mps:tag:`req.control` It must be possible to control whether and what +events are transmitted at least at a coarse level. + +:mps:tag:`req.examine` There should be a cheap means to examine the contents +of logs. + +:mps:tag:`req.pm` The event mechanism should provide for post mortem to +detect what significant events led up to death. + +:mps:tag:`req.perf` Events should not have a significant effect on +performance when unwanted. + +:mps:tag:`req.small` Telemetry streams should be small. + +:mps:tag:`req.avail` Events should be available in all varieties, subject to +performance requirements. + +:mps:tag:`req.impl` The plinth support for telemetry should be easy to write +and flexible. + +:mps:tag:`req.robust` The telemetry protocol should be robust against some +forms of corruption, e.g. packet loss. + +:mps:tag:`req.intern` It should be possible to support string-interning. + + +Architecture +------------ + +:mps:tag:`arch` Event annotations are scattered throughout the code, but +there is a central registration of event types and properties. Events +are written to a buffer via a specialist structure, and are optionally +written to the plinth. Events can take any number of parameters of a +range of types, indicated as a format both in the annotation and the +the registry. + + +Analysis +-------- + +:mps:tag:`anal` The proposed order of development, with summary of +requirements impact is as follows (★ for positive impact, ⇓ for +negative impact): + +========================= == == == == == == == == == == == == == == == == == ======= +solution si op mu sh ve ty po co ex pm pe sm av im ro in ba status +========================= == == == == == == == == == == == == == == == == == ======= +:mps:ref:`.sol.format` · · · · · ★ · · · · · · · · · · · merged +:mps:ref:`.sol.struct` · · · · · ★ · · · · ★ ⇓ · · · · · merged +:mps:ref:`.sol.string` · · · · · ★ · · · · · · · · · ★ · merged +:mps:ref:`.sol.relation` ★ · · ★ · · · · ★ · · ★ · · · · · merged +:mps:ref:`.sol.dumper` · · · · · · · · ★ · · · · · · · · merged +:mps:ref:`.sol.kind` · ⇓ · · · · · ★ · ★ · · · · · · · merged +:mps:ref:`.sol.control` · · · · · · · ★ · · ★ · · · · · · merged +:mps:ref:`.sol.variety` · · · · · · · · · ★ ★ · ★ · · · · +========================= == == == == == == == == == == == == == == == == == ======= + +The following are not yet ordered: + +========================= == == == == == == == == == == == == == == == == == ======= +solution si op mu sh ve ty po co ex pm pe sm av im ro in ba status +========================= == == == == == == == == == == == == == == == == == ======= +:mps:ref:`.sol.buffer` · · · · · · · ★ · ★ ★ · · · · · . +:mps:ref:`.sol.traceback` · · · · · · · · · ★ · · · · · · . +:mps:ref:`.sol.client` · · · · · · · · · · · · · · · ★ . +:mps:ref:`.sol.head` · · · · · · ★ · · · · · · · · · . +:mps:ref:`.sol.version` · · · · ★ · · · · · · · · · · · ★ +:mps:ref:`.sol.exit` · · · · · · · · · ★ · · · · · · . +:mps:ref:`.sol.block` · · · · · · · · · · ★ ⇓ · · ★ · · +:mps:ref:`.sol.code` · · · · · · · · · · · ★ · · · · ★ +:mps:ref:`.sol.msg` · · ★ · · · ★ · · · · · · ★ ★ · . +========================= == == == == == == == == == == == == == == == == == ======= + +:mps:tag:`file-format` One of the objectives of this plan is to minimise the +impact of the changes to the log file format. This is to be achieved +firstly by completing all necessary support before changes are +initiated, and secondly by performing all changes at the same time. + + +Ideas +----- + +:mps:tag:`sol.format` Event annotations indicate the types of their +arguments, for example, :c:macro:`EVENT_WD` for a :c:type:`Word` and a ``double``. +(:mps:ref:`.req.type`) + +:mps:tag:`sol.struct` Copy event data into a structure of the appropriate +type, for example, :c:type:`EventWDStruct`. (:mps:ref:`.req.type`, :mps:ref:`.req.perf`, but +not :mps:ref:`.req.small` because of padding) + +:mps:tag:`sol.string` Permit at most one string per event, at the end, and +use the ``char[1]`` hack, and specialised code; deduce the string +length from the event length and also :c:macro:`NUL`-terminate (:mps:ref:`.req.type`, +:mps:ref:`.req.intern`) + +:mps:tag:`sol.buffer` Enter all events initially into internal buffers, and +conditionally send them to the message stream. (:mps:ref:`.req.pm`, +:mps:ref:`.req.control`, :mps:ref:`.req.perf`) + +:mps:tag:`sol.variety` In optimized varieties, have internal events (see +:mps:ref:`.sol.buffer`) for a subset of events and no external events; in +normal varieties have all internal events, and the potential for +external events. (:mps:ref:`.req.avail`, :mps:ref:`.req.pm`, :mps:ref:`.req.perf`) + +:mps:tag:`sol.kind` Divide events by some coarse type into around 6 groups, +probably related to frequency. (:mps:ref:`.req.control`, :mps:ref:`.req.pm`, but not +:mps:ref:`.req.open`) + +:mps:tag:`sol.control` Hold flags to determine which events are emitted +externally. (:mps:ref:`.req.control`, :mps:ref:`.req.perf`) + +:mps:tag:`sol.dumper` Write a simple tool to dump event logs as text. +(:mps:ref:`.req.examine`) + +:mps:tag:`sol.msg` Redesign the plinth interface to send and receive +messages, based on any underlying IPC mechanism, for example, append +to file, TCP/IP, messages, shared memory. (:mps:ref:`.req.robust`, +:mps:ref:`.req.impl`, :mps:ref:`.req.port`, :mps:ref:`.req.multi`) + +:mps:tag:`sol.block` Buffer the events and send them as fixed size blocks, +commencing with a timestamp, and ending with padding. (:mps:ref:`.req.robust`, +:mps:ref:`.req.perf`, but not :mps:ref:`.req.small`) + +:mps:tag:`sol.code` Commence each event with two bytes of event code, and +two bytes of length. (:mps:ref:`.req.small`, :mps:ref:`.req.back`) + +:mps:tag:`sol.head` Commence each event stream with a platform-independent +header block giving information about the session, version (see +:mps:ref:`.sol.version`), and file format; file format will be sufficient to +decode the (platform-dependent) rest of the file. (:mps:ref:`.req.port`) + +:mps:tag:`sol.exit` Provide a mechanism to flush events in the event of +graceful sudden death. (:mps:ref:`.req.pm`) + +:mps:tag:`sol.version` Maintain a three part version number for the file +comprising major (incremented when the format of the entire file +changes (other than platform differences)), median (incremented when +an existing event changes its form or semantics), and minor +(incremented when a new event type is added); tools should normally +fail when the median or major is unsupported. (:mps:ref:`.req.version`, +:mps:ref:`.req.back`) + +:mps:tag:`sol.relation` Event types will be defined in terms of a relation +specifying their name, code, optimised behaviour (see +:mps:ref:`.sol.variety`), kind (see :mps:ref:`.sol.kind`), and format (see +:mps:ref:`.sol.format`); both the MPS and tool can use this by suitable +``#define`` hacks. (:mps:ref:`.req.simple`, :mps:ref:`.req.share`, :mps:ref:`.req.examine`, +:mps:ref:`.req.small` (no format information in messages)) + +:mps:tag:`sol.traceback` Provide a mechanism to output recent events (see +:mps:ref:`.sol.buffer`) as a form of backtrace when :c:macro:`AVER` statements fire +or from a debugger, or whatever. (:mps:ref:`.req.pm`) + +:mps:tag:`sol.client` Provide a mechanism for user events. (:mps:ref:`.req.intern`) + + + +Implementation +-------------- + +Annotation +.......... + +:mps:tag:`annot` An event annotation is of the form:: + + EVENT3(FooCreate, pointer, address, word) + +:mps:tag:`annot.string` If there is a string in the format, it must be the +last parameter (and hence there can be only one). There is currrently +a maximum string length, defined by ``EventMaxStringLength`` in +impl.h.eventcom. + +:mps:tag:`annot.type` The event type should be given as the first parameter +to the event macro, as registered in impl.h.eventdef. + +:mps:tag:`annot.param` The parameters of the event should be given as the +remaining parameters of the event macro, in order as indicated in the +event parameters definition in impl.h.eventdef. + + +Registration +............ + +:mps:tag:`reg` All event types and parameters should be registered in +impl.h.eventdef, in the form of a higher-order list macros. + +:mps:tag:`reg.just` This use of a higher-order macros enables great +flexibility in the use of this file. + +:mps:tag:`reg.rel` The event type registration is of the form:: + + EVENT(X, FooCreate, 0x1234, TRUE, Arena) + +:mps:tag:`reg.type` The first parameter of the relation is the event type. +This needs no prefix, and should correspond to that used in the +annotation. + +:mps:tag:`reg.code` The second parameter is the event code, a 16-bit value +used to represent this event type. Codes should not be re-used for new +event types, to allow interpretation of event log files of all ages. + +:mps:tag:`reg.always` The third parameter is a boolean value indicating +whether this event type should be implemented in all varieties. See +:mps:ref:`.control.buffer`. Unless your event is on the critical path +(typically per reference or per object), you will want this to be +:c:macro:`TRUE`. + +:mps:tag:`reg.kind` The fourth parameter is a kind keyword indicating what +category this event falls into. See :mps:ref:`.control`. The possible values +are: + +- :c:type:`Arena` -- per space or arena or global +- :c:type:`Pool` -- pool-related +- :c:type:`Trace` -- per trace or scan +- :c:type:`Seg` -- per segment +- :c:type:`Ref` -- per reference or fix +- ``Object`` -- per object or allocation +- ``User`` -- invoked by the user through the MPS interface + +This list can be seen in impl.h.eventcom. + +:mps:tag:`reg.doc` Add a docstring column. [RB 2012-09-03] + +:mps:tag:`reg.params` The event parameters registration is of the form:: + + #define EVENT_FooCreate_PARAMS(PARAM, X) \ + PARAM(X, 0, P, firstParamPointer) \ + PARAM(X, 1, U, secondParamUnsigned) + +:mps:tag:`reg.param.index` The first column is the index, and must start at +zero and increase by one for each row. + +:mps:tag:`reg.param.sort` The second column is the parameter "sort", which, +when appended to ``EventF``, yields a type for the parameter. It is a +letter from the following list: + +- ``P`` -- ``void *`` +- ``A`` -- :c:type:`Addr` +- ``W`` -- :c:type:`Word` +- ``U`` -- ``unsigned int`` +- ``S`` -- ``char *`` +- ``D`` -- ``double`` +- ``B`` -- :c:type:`Bool` + +The corresponding event parameter must be assignment compatible with +the type. + +:mps:tag:`param.types` When an event has parameters whose type is not in the +above list, use the following guidelines: All ``C`` pointer types not +representing strings use ``P``; :c:type:`Size`, :c:type:`Count`, :c:type:`Index` use +``W``; others should be obvious. + +:mps:tag:`reg.param.name` The third column is the parameter name. It should +be a valid C identifier and is used for debugging display and human +readable output. + +:mps:tag:`reg.param.doc` Add a docstring column. [RB 2012-09-03] + +:mps:tag:`reg.dup` It is permissible for the one event type to be used for +more than one annotation. There are generally two reasons for this: + +- Variable control flow for successful function completion; +- Platform/Otherwise-dependent implementations of a function. + +Note that all annotations for one event type must have the same format +(as implied by :mps:ref:`.sol.format`). + + +Control +....... + +:mps:tag:`control` There are two types of event control, buffer and output. + +:mps:tag:`control.buffer` Buffer control affects whether particular events +implemented at all, and is controlled statically by variety using the +always value (see :mps:ref:`.reg.always`) for the event type. The hot variety +does compiles out annotations with ``always=FALSE``. The cool variety +does not, so always buffers a complete set of events. + +:mps:tag:`control.output` Output control affects whether events written to +the internal buffer are output via the plinth. This is set on a +per-kind basis (see :mps:ref:`.reg.kind`), using a control bit table stored in +EventKindControl. By default, all event kinds are off. You may switch +some kinds on using a debugger. + +For example, to enable :c:type:`Pool` events using gdb (see impl.h.eventcom for +numeric codes):: + + $ gdb ./xci3gc/cool/amcss + (gdb) break GlobalsInit + (gdb) run + ... + (gdb) print EventKindControl |= 2 + $2 = 2 + (gdb) continue + ... + (gdb) quit + $ mpseventcnv -v | sort | head + 0000178EA03ACF6D PoolInit 9C1E0 9C000 0005E040 + 0000178EA03C2825 PoolInitMFS 9C0D8 9C000 1000 C + 0000178EA03C2C27 PoolInitMFS 9C14C 9C000 1000 44 + 0000178EA03C332C PoolInitMV 9C080 9C000 1000 20 10000 + 0000178EA03F4DB4 BufferInit 2FE2C4 2FE1B0 0 + 0000178EA03F4EC8 BufferInitSeg 2FE2C4 2FE1B0 0 + 0000178EA03F57DA AMCGenCreate 2FE1B0 2FE288 + 0000178EA03F67B5 BufferInit 2FE374 2FE1B0 0 + 0000178EA03F6827 BufferInitSeg 2FE374 2FE1B0 0 + 0000178EA03F6B72 AMCGenCreate 2FE1B0 2FE338 + +:mps:tag:`control.env` The initial value of ``EventKindControl`` is read +from the C environment when the ANSI Plinth is used, and so event +output can be controlled like this:: + + MPS_TELEMETRY_CONTROL=127 amcss + +or like this:: + + MPS_TELEMETRY_CONTROL="Pool Arena" amcss + +where the variable is set to a space-separated list of names defined by ``EventKindENUM``. + +:mps:tag:`control.just` These controls are coarse, but very cheap. + +:mps:tag:`control.external` The MPS interface function +``mps_telemetry_control`` can be used to change ``EventKindControl``. + +:mps:tag:`control.tool` The tools will be able to control +``EventKindControl``. + + +Debugging +......... + +:mps:tag:`debug.buffer` Each event kind is logged in a separate buffer, +``EventBuffer[kind]``. + +:mps:tag:`debug.buffer.reverse` The events are logged in reverse order from +the top of the buffer, with the last logged event at +``EventLast[kind]``. This allows recovery of the list of recent events +using the ``event->any.size`` field. + +:mps:tag:`debug.dump` The contents of all buffers can be dumped with the +``EventDump`` function from a debugger, for example:: + + gdb> print EventDump(mps_lib_get_stdout()) + +:mps:tag:`debug.describe` Individual events can be described with the +EventDescribe function, for example:: + + gdb> print EventDescribe(EventLast[3], mps_lib_get_stdout()) + +:mps:tag:`debug.core` The event buffers are preserved in core dumps and can +be used to work out what the MPS was doing before a crash. Since the +kinds correspond to frequencies, ancient events may still be available +in some buffers, even if they have been flushed to the output stream. +Some digging may be required. + + +Dumper tool +........... + +:mps:tag:`dumper` A primitive dumper tool is available in impl.c.eventcnv. +For details, see guide.mps.telemetry. + + +Allocation replayer tool +........................ + +:mps:tag:`replayer` A tool for replaying an allocation sequence from a log +is available in impl.c.replay. For details, see +design.mps.telemetry.replayer. + + diff --git a/mps/manual/html/_sources/design/tests.txt b/mps/manual/html/_sources/design/tests.txt new file mode 100644 index 00000000000..2d6ab4addca --- /dev/null +++ b/mps/manual/html/_sources/design/tests.txt @@ -0,0 +1,53 @@ +.. _design-tests: + + +Tests +===== + +.. mps:prefix:: design.mps.tests + + +Introduction +------------ + +:mps:tag:`intro` This document contains a guide to the Memory Pool System +tests. + +:mps:tag:`readership` This document is intended for any MPS developer. + + +Smoke tests +----------- + +:mps:tag:`smoke` The "smoke tests" provide quick checks that the MPS is +working. They run quickly enough for it to be practical to run them +every time the MPS is built. + +:mps:tag:`randomize` Each time a test case is run, it randomly chooses some +of its parameters (for example, the sizes of objects, or how many +links to create in a graph of references). This allows a fast test +to cover many cases over time. + +:mps:tag:`randomize.repeatable` The random numbers are chosen +pseudo-randomly based on a seed initialized from environmental data +(the time and the processor cycle count). The seed is reported at test +startup. Each test can be run with a specified seed. This ensures +that the deterministic tests are repeatable. + + +Smoke test list +............... + +:mps:tag:`test.finalcv` Registers objects for finalization, makes them +unreachable, deregisters them, etc. Churns to provoke minor (nursery) +collection. + +:mps:tag:`test.finaltest` Creates a large binary tree, and registers every +node. Drops the top reference, requests collection, and counts the +finalization messages. + +:mps:tag:`test.zcoll` Collection scheduling, and collection feedback. + +:mps:tag:`test.zmess` Message lifecycle and finalization messages. + + diff --git a/mps/manual/html/_sources/design/thread-manager.txt b/mps/manual/html/_sources/design/thread-manager.txt new file mode 100644 index 00000000000..4392775d217 --- /dev/null +++ b/mps/manual/html/_sources/design/thread-manager.txt @@ -0,0 +1,155 @@ +.. _design-thread-manager: + + +.. index:: + pair: thread manager; design + + +Thread Manager +============== + +.. mps:prefix:: design.mps.thread-manager + + +Purpose +------- + +The Thread Manager handles various thread-related functions required +by the MPS. These are: + +- stack scanning; +- suspension and resumption of the mutator threads. + + +Context +------- + +The barrier requires suspension and resumption of threads in order to +ensure that the collector has exclusive access to part of memory. +[design.mps.barrier.@@@@] + +Stack scanning is provided as a service to the client. [Link?@@@@] + + +Overview +-------- + +.. c:type:: struct mps_thr_s *Thread + +Each thread is represented by an object of type :c:type:`Thread`. The +:c:type:`Thread` type is implemented as an ADT. A list of :c:type:`Thread` objects +is maintained in the arena (as the :c:type:`Ring` structure +``arena->threadRing``). The :c:type:`Thread` object contains +operating-system-dependent information about the thread -- information +necessary for manipulating the thread and for scanning the thread +context. Thread "registration" adds or removes the current thread to +the :c:type:`Thread` list in the arena. + + +Detailed Design +--------------- + +Stack scan +.......... + +This is a module providing a stack scanning function. The scanning is +architecture and operating system dependent. Typically the function +will push the subste of the save registers (those preserved across +function calls) which may contain pointers (that is, neither +floating-point or debugging registers) and call :c:func:`TraceScanStack()` +on the appropriate range. + + +Thread interface +................ + +.. c:function:: Res ThreadRegister(Thread *threadReturn, Arena arena) + +Register the current thread with the arena, allocating a new +``*threadReturn`` to point to it. + +.. c:function:: void ThreadDeregister(Thread thread, Arena arena) + +Remove ``thread`` from the list of threads managed by the arena and +free it. + +.. c:function:: void ThreadRingSuspend(Ring threadRing) + +Suspend all the threads on the list ``threadRing``, except for the +current thread. + +.. c:function:: void ThreadRingResume(Ring threadRing) + +Resume all the threads on the list ``threadRing``. + +.. c:function:: Res ThreadScan(ScanState ss, Thread thread, void *stackBot) + +Scan the stacks and root registers of ``thread``, treating each value +found as an ambiguous reference. The exact definition is operating +system and architecture dependent + + +Single-threaded generic implementation +...................................... + +In ``than.c``. + +- Single threaded (calling :c:func:`ThreadRegister()` on a second thread + causes an assertion failure). +- :c:func:`ThreadRingSuspend()` and :c:func:`ThreadRingResume()` do nothing + because there are no other threads. +- :c:func:`ThreadScan()` calls :c:func:`StackScan()`. + + +POSIX threads implementation +............................ + +In ``thix.c``. See design.mps.pthreadext. + + +Win32 implementation +.................... + +In ``thw3.c``. + +- Supports multiple threads. +- Structured exception style faults are expected. +- :c:func:`ThreadRingSuspend()` and :c:func:`ThreadRingResume()` loop over threads + and call Win32 API functions :c:func:`SuspendThread()` and + :c:func:`ResumeThread()`. +- :c:func:`ThreadRegister()` records information for the current thread: + + - A Win32 "handle" with access flags :c:macro:`THREAD_SUSPEND_RESUME` and + :c:macro:`THREAD_GET_CONTEXT`. This handle is needed as parameter to + :c:func:`SuspendThread()` and :c:func:`ResumeThread()`. + - The Win32 :c:func:`GetCurrentThreadId()` so that the current thread may + be identified. + +- Stack scanning is Win32 specific: + + - :c:func:`ThreadScan()` calls :c:func:`StackScan()` if the thread is current. + :c:func:`GetThreadContext()` doesn't work on the current thread (the + context would not necessarily have the values which were in the + saved registers on entry to the MM). + - Otherwise it calls :c:func:`GetThreadContext()` to get the root + registers and the stack pointer. + - The thread's registers are dumped into a :c:macro:`CONTEXT` structure and + fixed in memory. + - Scan the stack (getting the stack pointer from ``CONTEXT.Rsp``). + + +Issues +------ + +1. Scanning after exceptions. :c:func:`StackScan()` relies on the + non-preserved registers having been pushed on the stack. If we want + to scan after a fault we must make sure that these registers are + either already stored on the stack, or, have an extra function to + do this explicitly. + +2. Multiple registration. It is not clear whether a thread should be + allowed to be registered multiple times. We do not provide a + mechanism for knowing whether a thread is already registered with + an arena. + + diff --git a/mps/manual/html/_sources/design/thread-safety.txt b/mps/manual/html/_sources/design/thread-safety.txt index 05966e4b8c4..eb43b437ff3 100644 --- a/mps/manual/html/_sources/design/thread-safety.txt +++ b/mps/manual/html/_sources/design/thread-safety.txt @@ -1,6 +1,326 @@ +.. _design-thread-safety: + + .. index:: pair: thread safety; design -.. _design-thread-safety: -.. include:: ../../converted/thread-safety.rst +Thread safety in the MPS +======================== + +.. mps:prefix:: design.mps.thread-safety + + +Introduction +------------ + +:mps:tag:`intro` This describes how thread safety is achieved in the MPS. + + +Overview +-------- + +:mps:tag:`over` The MPS is expected to run in an environment with multiple +threads calling into the MPS. The initial approach is very simple. +Some of the code is known to operate with exclusive access to the data +it manipulates, so this code is safe. For the rest of the code, shared +data structures are locked by the use of a single binary lock +(design.mps.lock(0)) per arena. This lock is claimed on entry to the +MPS and released on exit from it. So there is at most a single thread +(per arena) running "inside" the MPS at a time. + + +Requirements +------------ + +:mps:tag:`req.mt` Code must work correctly in presence of multiple threads +all calling into the MPS. + +:mps:tag:`req.perf` Performance should not be unreasonably hindered. + + +Architecture +------------ + +:mps:tag:`arch.arena` Arena Lock: no shared data between arenas. + +:mps:tag:`arch.global.binary` Global binary lock: protects mutable data +shared between arenas -- that is, the arena ring, see +design.mps.arena.static.ring.lock. + +:mps:tag:`arch.global.recursive` Global recursive lock: protects static data +which must be initialized once -- for example, pool classes, see +design.mps.protocol.impl.init-lock. + +:mps:tag:`arch.other` Other: data not shared. + +:mps:tag:`arch.static` Static data: sigs: shared-non-mutable always inited +to same thing. + +:mps:tag:`arena-entry` Each arena has a single lock. Externally visible +calls fall into two categories. Simple: arena lock not held. Lock is +claimed on entry, and released on exit. Recall: These are callable +only after a call-back from the MPS. In this case a arena lock is +already held. + +:mps:tag:`interface` The definition of the interface should guarantee safe +use of calls (from a locking point of view). For example, a buffer +must be exclusive to a thread. + +:mps:tag:`buffers` The buffer code is designed not to need a lock in the +fast case. A lock is only claimed on the exceptional reserve, trip and +commit cases (fill and trip?). A buffer contains references to shared +data (via pool field). Accessing this shared data must involve a lock. + +:mps:tag:`deadlock` A strict ordering is required between the global and +arena locks to prevent deadlock. The binary global lock may not be +claimed while either the arena or recursive global lock is held; the +arena lock may not be claimed while the recursive global lock is held. +Each arena lock is independent of all other arena locks; that is, a +thread may not attempt to claim more than one arena lock at a time. + + +Analysis +-------- + +:mps:tag:`anal.simple` To have the code functioning correctly it should be +easy to change correctly. So a simple approach is desirable. We have +to also ensure that performance is not unreasonably downgraded. + +Performance cost of locking +........................... + +:mps:tag:`lock-cost` The cost of locking in performance terms are: + +- :mps:tag:`lock-cost.overhead` the overhead of claiming and releasing locks; + +- :mps:tag:`lock-cost.pause` the pauses caused by one thread being blocked + on another thread. + +- :mps:tag:`lock-cost.wait` the time wasted by one thread being blocked on + another thread. + +:mps:tag:`anal.perf.signif` :mps:ref:`.lock-cost.pause` is significant if there are +MPS functions that take a long time. Using more locks, e.g. having a +lock per pool as well as a lock per arena, is a way of decreasing the +locking conflict between threads (.lock-cost.pause and +:mps:ref:`.lock-cost.wait`). However this could increase +:mps:ref:`.lock-cost.overhead` significantly. + +:mps:tag:`anal.perf.work` But all MPS functions imply a small work-load +unless a collection is taking place. In the case of a collection, in +practice and certainly in the near future, all threads will most +likely be suspended while the collection work is going on. (The pages +being scanned will need to be unprotected which implies the mutator +will have to be stopped.) We also have to remember that unless we are +running on genuine multiprocessor :mps:ref:`.lock-cost.wait` is irrelevant. + +:mps:tag:`anal.perf.alloc` During typical use we expect that it is +allocation that is the most frequent activity. Allocation buffers +(design.mps.buffer) are designed to allow allocation in concurrent +threads without needing a lock. So the most significant time a thread +spends in the MPS will be on a buffer-fill or during a collection. The +next most significant use is likely to be buffer create and deletion, +as a separate buffer will be required for each thread. + +:mps:tag:`anal.perf.lock` So overall the performance cost of locking is, I +estimate, most significantly the overhead of calling the locking +functions. Hence it would be undesirable from a performance point of +view to have more than one lock. + +Recursive vs binary locks +......................... + +:mps:tag:`anal.reentrance` The simplest way to lock the code safely is to +define which code runs inside or outside the lock. Calling from the +outside to the inside implies a lock has to be claimed. Returning +means the lock has to be released. Control flow from outside to +outside and from inside to inside needs no locking action. To +implement this a function defined on the external interface needs to +claim the lock on entry and release it on exit. Our code currently +uses some external functions with the lock already held. There are two +ways to implement this: + +1. :mps:tag:`recursive` Each external function claims a recursive lock. + + - simple; + - have to worry about locking depth; + - extra locking overhead on internal calls of external functions; + +2. :mps:tag:`binary` Each external function claims a binary lock. Replace + each internal call of an external function with a call to a newly + defined internal one. + + - more code + - slightly easier to reason about + +:mps:tag:`anal.strategy` It seems that the :mps:ref:`.recursive` strategy is the +easiest to implement first, but could be evolved into a :mps:ref:`.binary` +strategy. (That evolution has now happened. tony 1999-08-31). + + +Ideas +----- + +:mps:tag:`sol.arena-lock` Lock per arena which locks all MPS structures +associated with the arena, except allocation buffers. + +:mps:tag:`sol.init` Shared static data may not be changed. It is initialised +before being read, and if re-initalised the values written must be +identical to those already there. Essentially only read-only shared +static data is allowed. + +:mps:tag:`sol.fine-grain` Use finer grained locks, for example, a lock per +per pool instance. Arena lock locks only operations on arena. Pool +locks are claimed per pool. An ordering on pool instances would avoid +deadlock. + +:mps:tag:`sol.global` Use global locks for genuinely global data which must +be updated dynamically. An ordering between global and arena locks +would avoid deadlock. + + +Implementation +-------------- + +Use MPS locks (design.mps.lock) to do locking. + +Locking Functions +................. + +:c:func:`ArenaEnter()` and :c:func:`ArenaLeave()` are used to claim and release the +arena lock. To implement this: + +- There is a lock for every arena. The arena class init function + allocates the lock as well as the arena itself. +- :c:func:`ArenaInit()` calls :c:func:`LockInit()` on the lock and initializes the + pointer to it from the arena. +- :c:func:`ArenaDestroy()` calls :c:func:`LockFinish()` on it. +- :c:func:`ArenaEnter()` claims the lock. +- :c:func:`ArenaLeave()` releases the lock. + +Shared and non-shared data +.......................... + +Non-shared data is data for which no other thread has a handle on it. +shared-non-mutable data is data which is never changed after +initialisation. It may be re-initialised, if re-initialisation does +not change its value. atomically updatable data is data which is not +locked, but may be shared because it is in a consistent state before +and after an update. + +A function is "safe" if it may safely execute without exclusive access +to the data it manipulates. + +A "safe" function may: + +- call other safe functions; +- manipulate non-shared data; +- read shared-non-mutable data; +- claim the arena lock around code which may manipulate shared data in + the arena. + +Each function in the external MPS interface falls into one of the +following categories: + +- calls :c:func:`ArenaEnter()` on entry and :c:func:`ArenaLeave()` on exit; +- uses :c:func:`PoolArena()` to identify the arena, before claiming the lock; +- uses :c:func:`BufferPool()` and :c:func:`PoolArena()` to identify the arena, before + claiming the lock; +- is not defined as external but is listed for explicitness; +- only claims the lock in otherwise unsafe situations (buffer code?); +- may be called externally but only in a situation where the arena + lock is already held; +- is the unique accessor of its data. + +So :c:func:`PoolArena()` and :c:func:`BufferPool()` must be "safe". ``pool->arena`` is +shared-non-mutable. ``buffer->pool`` is shared-non-mutable. + +Validation +.......... + +We have to be careful about validation. Any function that is called +from a arena-safe function without the arena-lock held, must itself be +safe, or manipulating non-shared data. + +For example, calling :c:func:`PoolIsValid()` before claiming the lock would be +wrong if :c:func:`PoolIsValid()` is unsafe. Defining it to be safe would +involve locking it, which if done in all similar situations would be +very expensive. + +Possibly remove validation from accessor methods; replace with +signature check and :c:func:`IsValid()` calls in callers of accessor +functions. + +Annotations?: +- safe +- non-shared +- shared-non-mutable + +Safe functions +.............. + +Arena + +- :c:func:`ArenaCreate()` -- no shared data; no lock; calls :c:func:`LockInit()`. +- :c:func:`ArenaDestroy()` -- no shared data; no lock (should only finish + arena after use); calls :c:func:`LockFinish()`. +- :c:func:`ArenaDescribe()` -- lock. + +Root (for the purposes of locking this module can be thought of as external) + +- :c:func:`RootCreate()` -- calls create +- :c:func:`RootCreateTable()` -- calls create +- create -- lock +- :c:func:`RootDestroy()` -- lock +- :c:func:`RootDescribe()` -- lock + +will be attached to arena, can lock now. + + +Pool + +- :c:func:`PoolCreate()` / :c:func:`PoolCreateV()` -- lock (Create calls CreateV which locks). +- :c:func:`PoolDestroy()` -- lock +- :c:func:`PoolAlloc()` -- lock +- :c:func:`PoolFree()` -- lock +- :c:func:`PoolArena()` -- accesses shared-non-mutable data only +- :c:func:`PoolDescribe()` -- lock + +Format + +- :c:func:`FormatCreate()` -- lock +- :c:func:`FormatDestroy()` -- lock + +Buffer + +- :c:func:`BufferCreate()` -- lock +- :c:func:`BufferDestroy()` -- lock +- :c:func:`BufferFill()` -- lock +- :c:func:`BufferTrip()` -- lock +- :c:func:`BufferPool()` -- accesses shared-non-mutable data only +- :c:func:`BufferDescribe()` -- lock +- :c:func:`BufferCommit()` -- "unsafe": buffer may be used by single thread + only. (but safe wrt arena) +- :c:func:`BufferReserve()` -- "unsafe": also + +PoolClass (only shared data is static and non-mutable) + +- :c:func:`PoolClass()` +- :c:func:`PoolClassAMC()` +- :c:func:`PoolClassMV()` +- :c:func:`PoolClassMFS()` + +Sig (as with :c:type:`PoolClass`, relies on static data reinitialised to +constant value) + +Collect + +- :c:func:`Collect()` -- lock + +Thread + +- :c:func:`ThreadRegister()` -- lock +- :c:func:`ThreadDeregister()` -- lock + + diff --git a/mps/manual/html/_sources/design/trace.txt b/mps/manual/html/_sources/design/trace.txt index caacef96048..8e75ee7807f 100644 --- a/mps/manual/html/_sources/design/trace.txt +++ b/mps/manual/html/_sources/design/trace.txt @@ -1,6 +1,237 @@ +.. _design-trace: + + .. index:: pair: tracer; design -.. _design-trace: -.. include:: ../../converted/trace.rst +Tracer +====== + +.. mps:prefix:: design.mps.trace + + +Introduction +------------ + +.. warning:: + + This document is currently a mixture of very old design notes (the + preformatted section immediately following) and some newer stuff. + It doesn't yet form anything like a complete picture. + + +Architecture +------------ + +:mps:tag:`instance.limit` There will be a limit on the number of traces that +can be created at any one time. This effectively limits the number of +concurrent traces. This limitation is expressed in the symbol +:c:macro:`TRACE_MAX`. + +.. note:: + + :c:macro:`TRACE_MAX` is currently set to 1, see request.mps.160020 + "Multiple traces would not work". David Jones, 1998-06-15. + +:mps:tag:`rate` See `mail.nickb.1997-07-31.14-37 `_. + +.. note:: + + Now revised? See request.epcore.160062 and + change.epcore.minnow.160062. David Jones, 1998-06-15. + +:mps:tag:`exact.legal` Exact references should either point outside the +arena (to non-managed address space) or to a tract allocated to a +pool. Exact references that are to addresses which the arena has +reserved but hasn't allocated memory to are illegal (the exact +reference couldn't possibly refer to a real object). Depending on the +future semantics of :c:func:`PoolDestroy()` we might need to adjust our +strategy here. See mail.dsm.1996-02-14.18-18 for a strategy of coping +gracefully with :c:func:`PoolDestroy()`. We check that this is the case in the +fixer. It may be sensible to make this check CRITICAL in certain +configurations. + +:mps:tag:`fix.fixed.all` ``ss->fixedSummary`` is accumulated (in the fixer) +for all the pointers whether or not they are genuine references. We +could accumulate fewer pointers here; if a pointer fails the +:c:func:`TractOfAddr()` test then we know it isn't a reference, so we needn't +accumulate it into the fixed summary. The design allows this, but it +breaks a useful post-condition on scanning (if the accumulation of +``ss->fixedSummary`` was moved the accuracy of ``ss->fixedSummary`` +would vary according to the "width" of the white summary). See +mail.pekka.1998-02-04.16-48 for improvement suggestions. + + +Analysis +-------- + +:mps:tag:`fix.copy-fail` Fixing can always succeed, even if copying the +referenced object has failed (due to lack of memory, for example), by +backing off to treating a reference as ambiguous. Assuming that fixing +an ambiguous reference doesn't allocate memory (which is no longer +true for AMC for example). See request.dylan.170560 for a slightly +more sophisticated way to proceed when you can no longer allocate +memory for copying. + + +Ideas +----- + +:mps:tag:`flip.after` To avoid excessive barrier impact on the mutator +immediately after flip, we could scan during flip other objects which +are "near" the roots, or otherwise known to be likely to be accessed +in the near future. + + +Implementation +-------------- + +Speed +..... + +:mps:tag:`fix` The fix path is critical to garbage collection speed. +Abstractly fix is applied to all the references in the non-white heap +and all the references in the copied heap. Remembered sets cut down +the number of segments we have to scan. The zone test cuts down the +number of references we call fix on. The speed of the remainder of the +fix path is still critical to system performance. Various +modifications to and aspects of the system are concerned with +maintaining the speed along this path. + +:mps:tag:`fix.tractofaddr` :c:func:`TractOfAddr()` is called on every reference that +passes the zone test and is on the critical path, to determine whether +the segment is white. There is no need to examine the segment to +perform this test, since whiteness information is duplicated in +tracts, specifically to optimize this test. :c:func:`TractOfAddr()` itself is +a simple class dispatch function (which dispatches to the arena +class's :c:func:`TractOfAddr()` method). Inlining the dispatch and inlining +the functions called by :c:func:`VMTractOfAddr()` makes a small but noticable +difference to the speed of the dylan compiler. + +:mps:tag:`fix.noaver` :c:func:`AVER()` statements in the code add bulk to the code +(reducing I-cache efficacy) and add branches to the path (polluting +the branch pedictors) resulting in a slow down. Removing all the +:c:func:`AVER()` statements from the fix path improves the overall speed of +the Dylan compiler by as much as 9%. + +:mps:tag:`fix.nocopy` :c:func:`AMCFix()` used to copy objects by using the format's +copy method. This involved a function call (through an indirection) +and in ``dylan_copy`` a call to ``dylan_skip`` (to recompute the +length) and call to ``memcpy`` with general parameters. Replacing this +with a direct call to ``memcpy`` removes these overheads and the call +to ``memcpy`` now has aligned parameters. The call to ``memcpy`` is +inlined by the C compiler. This change results in a 4–5% speed-up in +the Dylan compiler. + +:mps:tag:`reclaim` Because the reclaim phase of the trace (implemented by +:c:func:`TraceReclaim()`) examines every segment it is fairly time intensive. +rit's profiles presented in request.dylan.170551 show a gap between +the two varieties variety.hi and variety.wi. + +:mps:tag:`reclaim.noaver` Converting :c:func:`AVER()` statements in the loops of +:c:func:`TraceReclaim()`, :c:func:`PoolReclaim()`, :c:func:`AMCReclaim()` (:c:func:`LOReclaim()`? +:c:func:`AWLReclaim()`?) will result in a noticeable speed improvement. + +.. note:: + + Insert actual speed improvement here, if any. + + +Life cycle of a trace object +---------------------------- + +:c:func:`TraceCreate()` creates a trace in state ``TraceINIT`` + +Some segments get condemned (made white). + +:c:func:`TraceStart()` gets called which: + +- Derives an initial reference partition based on the existing + white set. The white zone set and the segments' summaries are used to + create an initial grey set. + +- Emits a :c:func:`GCStart()` message. + +- Initialises ``trace->rate`` by estimating the required scanning + rate. + +- Moves the trace into the state ``TraceUNFLIPPED``. + +- Immediately calls ``traceFlip`` which flips the trace and moves + it into state ``TraceFLIPPED``. + +Whilst a trace is alive every so often its ``traceQuantum`` method +gets invoked (via :c:func:`TracePoll()`) in order to do a quantum of tracing +work. ``traceQuantum`` is responsible for ticking through the trace's +top-level state machine. Most of the interesting work, the tracing, +happens in the ``TraceFLIPPED`` state. + +The trace transitions through its states in the following sequence: +``TraceINIT`` → (``TraceUNFLIPPED``) → ``TraceFLIPPED`` → +``TraceRECLAIM`` → ``TraceFINISHED``. + +Whilst ``TraceUNFLIPPED`` appears in the code, no trace does any work +in this state; all traces are immediately flipped to be in the +``TraceFLIPPED`` state (see above). + +Once the trace is in the ``TraceFINISHED`` state it performs no more +work and it can be safely destroyed. Generally the callers of +``traceQuantum`` will destroy the trace. + + +Making progress: scanning grey segments +....................................... + +Most of the interesting work of a trace, the actual tracing, happens +in the ``TraceFLIPPED`` state (work *would* happen in the +``TraceUNFLIPPED`` state, but that is not implemented). + +The tracer makes progress by choosing a grey segment to scan, and +scanning it. The actual scanning is performed by pools. + +Note that at all times a reference partition is maintained. + +The order in which the trace scans things determines the semantics of +certain types of references (in particular, weak and final +references). Or, to put it another way the desired semantics of weak +and final references impose certain restrictions on the order in which +the trace can scan things. + +The tracer uses a system of *reference ranks* (or just ranks) so that +it can impose an order on its scanning work. The ranks are ordered. + +The tracer proceeds band by band. The first band is all objects it can +reach by following references of the first rank. The second band is +all subsequent objects it can reach by following references of the +second and first ranks. The third band is all subsequent objects it +can reach by following references of the third, second, and first +ranks. And so on. The description of the tracer working like this +originated in [RHSK_2007-06-25]_. + +A trace keep track of which band it is tracing. This is returned by +the :c:func:`TraceBand()` method. Keeping this band information helps it +implement the semantics of finalization and weakness. The band used to +not be explicitly stored, but this hindered the implementation of good +finalization semantics (essentially in some circumstances finalization +messages were delayed by at least one collection cycle, see +job001658_. + +.. _job001658: https://info.ravenbrook.com/project/mps/issue/job001658/ + +The band is used when selecting a grey segment to scan (the selection +occurs in :c:func:`traceFindGrey()`). The tracer attempts to first find +segments whose rank is the current band, then segments whose rank is +previous to the current band, and so on. If there are no segments +found then the current band is exhausted and the current band is +incremented to the next rank. When the current band is moved through +all the ranks in this fashion there is no more tracing to be done. + + + +References +---------- + +.. [RHSK_2007-06-25] Richard Kistruck. Ravenbrook Limited. 2007-06-25. "`The semantics of rank-based tracing `__". + + diff --git a/mps/manual/html/_sources/design/type.txt b/mps/manual/html/_sources/design/type.txt index 6026dc77cbd..c931c65fafb 100644 --- a/mps/manual/html/_sources/design/type.txt +++ b/mps/manual/html/_sources/design/type.txt @@ -1,6 +1,522 @@ +.. _design-type: + + .. index:: pair: general types; design -.. _design-type: -.. include:: ../../converted/type.rst +General MPS types +================= + +.. mps:prefix:: design.mps.type + + +Introduction +------------ + +:mps:tag:`intro` See impl.h.mpmtypes. + + +Rationale +--------- + +Some types are declared to resolve a point of design, such as the best +type to use for array indexing. + +Some types are declared so that the intention of code is clearer. For +example, :c:type:`Byte` is necessarily ``unsigned char``, but it's better to +say :c:type:`Byte` in your code if it's what you mean. + + +Concrete types +-------------- + +.. c:type:: int Bool + +:mps:tag:`bool` The :c:type:`Bool` type is mostly defined so that the intention of +code is clearer. In C, Boolean expressions evaluate to ``int``, so +:c:type:`Bool` is in fact an alias for ``int``. + +:mps:tag:`bool.value` :c:type:`Bool` has two values, :c:macro:`TRUE` and :c:macro:`FALSE`. These +are defined to be ``1`` and ``0`` respectively, for compatibility with +C Boolean expressions (so one may set a :c:type:`Bool` to the result of a C +Boolean expression). + +:mps:tag:`bool.use` :c:type:`Bool` is a type which should be used when a Boolean +value is intended, for example, as the result of a function. Using a +Boolean type in C is a tricky thing. Non-zero values are "true" (when +used as control conditions) but are not all equal to :c:macro:`TRUE`. Use +with care. + +:mps:tag:`bool.check` :c:func:`BoolCheck()` simply checks whether the argument is +:c:macro:`TRUE` (``1``) or :c:macro:`FALSE` (``0``). + +:mps:tag:`bool.check.inline` The inline macro version of ``BoolCheck`` casts +the ``int`` to ``unsigned`` and checks that it is ``<= 1``. This is +safe, well-defined, uses the argument exactly once, and generates +reasonable code. + +:mps:tag:`bool.check.inline.smaller` In fact we can expect that the "inline" +version of :c:func:`BoolCheck()` to be smaller than the equivalent function +call. On IA-32 for example, a function call will be 3 instructions +(total 9 bytes), the inline code for :c:func:`BoolCheck()` will be 1 +instruction (total 3 bytes) (both sequences not including the test +which is the same length in either case). + +:mps:tag:`bool.check.inline.why` As well as being smaller (see +:mps:ref:`.bool.check.inline.smaller`) it is faster. On 1998-11-16 drj +compared ``w3i3mv\hi\amcss.exe`` running with and without the macro +for ``BoolCheck`` on the PC Aaron. "With" ran in 97.7% of the time +(averaged over 3 runs). + + +.. c:type:: int Res + +:mps:tag:`res` :c:type:`Res` is the type of result codes. A result code indicates +the success or failure of an operation, along with the reason for +failure. Like Unix error codes, the meaning of the code depends on the +call that returned it. These codes are just broad categories with +mnemonic names for various sorts of problems. + +=================== ======================================================= +Result code Description +=================== ======================================================= +``ResOK`` The operation succeeded. Return parameters may only be + updated if OK is returned, otherwise they must be left + untouched. +------------------- ------------------------------------------------------- +``ResFAIL`` Something went wrong which doesn't fall into any of the + other categories. The exact meaning depends on the + call. See documentation. +------------------- ------------------------------------------------------- +``ResRESOURCE`` A needed resource could not be obtained. Which resource + depends on the call. See also ``ResMEMORY``, which is a + special case of this. +------------------- ------------------------------------------------------- +``ResMEMORY`` Needed memory (committed memory, not address space) + could not be obtained. +------------------- ------------------------------------------------------- +``ResLIMIT`` An internal limitation was reached. For example, the + maximum number of somethings was reached. We should + avoid returning this by not including static + limitations in our code, as far as possible. (See + rule.impl.constrain and + rule.impl.limits.) +------------------- ------------------------------------------------------- +``ResUNIMPL`` The operation, or some vital part of it, is + unimplemented. This might be returned by functions + which are no longer supported, or by operations which + are included for future expansion, but not yet + supported. +------------------- ------------------------------------------------------- +``ResIO`` An I/O error occurred. Exactly what depends on the + function. +------------------- ------------------------------------------------------- +``ResCOMMIT_LIMIT`` The arena's commit limit would have been exceeded + as a result of allocation. +------------------- ------------------------------------------------------- +``ResPARAM`` An invalid parameter was passed. Normally reserved for + parameters passed from the client. +=================== ======================================================= + +:mps:tag:`res.use` :c:type:`Res` should be returned from any function which might +fail. Any other results of the function should be passed back in +"return" parameters (pointers to locations to fill in with the +results). + +.. note:: This is documented elsewhere, I think -- richard + +:mps:tag:`res.use.spec` The most specific code should be returned. + + +.. c:type:: void (*Fun)(void) + +:mps:tag:`fun` :c:type:`Fun` is the type of a pointer to a function about which +nothing more is known. + +:mps:tag:`fun.use` :c:type:`Fun` should be used where it's necessary to handle a +function in a polymorphic way without calling it. For example, if you +need to write a function ``g`` which passes another function ``f`` +through to a third function ``h``, where ``h`` knows the real type of +``f`` but ``g`` doesn't. + + +.. c:type:: MPS_T_WORD Word + +:mps:tag:`word` :c:type:`Word` is an unsigned integral type which matches the size +of the machine word, that is, the natural size of the machine +registers and addresses. + +:mps:tag:`word.use` :c:type:`Word` should be used where an unsigned integer is +required that might range as large as the machine word. + +:mps:tag:`word.source` :c:type:`Word` is derived from the macro :c:macro:`MPS_T_WORD` +which is declared in impl.h.mpstd according to the target platform +(design.mps.config.pf.word). + +:mps:tag:`word.conv.c` :c:type:`Word` is converted to :c:type:`mps_word_t` in the MPS C +Interface. + +:mps:tag:`word.ops` :c:func:`WordIsAligned()`, :c:func:`WordAlignUp()`, +:c:func:`WordAlignDown()` and :c:func:`WordRoundUp()`. + + +.. c:type:: unsigned char Byte + +:mps:tag:`byte` :c:type:`Byte` is an unsigned integral type corresponding to the +unit in which most sizes are measured, and also the units of +``sizeof``. + +:mps:tag:`byte.use` :c:type:`Byte` should be used in preference to ``char`` or +``unsigned char`` wherever it is necessary to deal with bytes +directly. + +:mps:tag:`byte.source` :c:type:`Byte` is a just pedagogic version of ``unsigned +char``, since ``char`` is the unit of ``sizeof``. + + +.. c:type:: Word Index + +:mps:tag:`index` :c:type:`Index` is an unsigned integral type which is large +enough to hold any array index. + +:mps:tag:`index.use` :c:type:`Index` should be used where the maximum size of the +array cannot be statically determined. If the maximum size can be +determined then the smallest unsigned integer with a large enough +range may be used instead. + + +.. c:type:: Word Count + +:mps:tag:`count` :c:type:`Count` is an unsigned integral type which is large +enough to hold the size of any collection of objects in the MPS. + +:mps:tag:`count.use` :c:type:`Count` should be used for a number of objects +(control or managed) where the maximum number of objects cannot be +statically determined. If the maximum number can be statically +determined then the smallest unsigned integer with a large enough +range may be used instead (although :c:type:`Count` may be preferable for +clarity). + +.. note:: + + Should :c:type:`Count` be used to count things that aren't represented + by objects (for example, a level)? I would say yes. gavinm + 1998-07-21 + +.. note:: + + Only where it can be determined that the maximum count is less + than the number of objects. pekka 1998-07-21 + + +.. c:type:: Word Accumulation + +:mps:tag:`accumulation` :c:type:`Accumulation` is an arithmetic type which is +large enough to hold accumulated totals of objects of bytes (for +example, total number of objects allocated, total number of bytes +allocated). + +:mps:tag:`accumulation.type` Currently it is ``double``, but the reason for +the interface is so that we can more easily change it if we want to +(if we decide we need more accuracy for example). + +:mps:tag:`accumulation.use` Currently the only way to use an +:c:type:`Accumulation` is to reset it (by calling ``AccumulatorReset``) and +accumulate amounts into it (by calling ``Accumulate``). There is no +way to read it at the moment, but that's okay, because no one seems to +want to. + +:mps:tag:`accumulation.future` Probably we should have methods which return +the accumulation into an ``unsigned long``, and also a ``double``; +these functions should return :c:type:`Bool` to indicate whether the +accumulation can fit in the requested type. Possibly we could have +functions which returned scaled accumulations. For example, +``AccumulatorScale(a, d)`` would divide the ``Accumulation a`` by +``double d`` and return the ``double`` result if it fitted into a +``double``. + + +.. c:type:: struct AddrStruct *Addr + +:mps:tag:`addr` :c:type:`Addr` is the type used for "managed addresses", that is, +addresses of objects managed by the MPS. + +:mps:tag:`addr.def` :c:type:`Addr` is defined as ``struct AddrStruct *``, but +:c:type:`AddrStruct` is never defined. This means that :c:type:`Addr` is always an +incomplete type, which prevents accidental dereferencing, arithmetic, +or assignment to other pointer types. + +:mps:tag:`addr.use` :c:type:`Addr` should be used whenever the code needs to deal +with addresses. It should not be used for the addresses of memory +manager data structures themselves, so that the memory manager remains +amenable to working in a separate address space. Be careful not to +confuse :c:type:`Addr` with ``void *``. + +:mps:tag:`addr.ops` Limited arithmetic is allowed on addresses using +:c:func:`AddrAdd()` and :c:func:`AddrOffset()` (impl.c.mpm). Addresses may also be +compared using the relational operators ``==``, ``!=``, ``<``, ``<=``, +``>``, and ``>=``. + +:mps:tag:`addr.ops.mem` We need efficient operators similar to :c:func:`memset()`, +:c:func:`memcpy()`, and :c:func:`memcmp()` on :c:type:`Addr`; these are called :c:func:`AddrSet()`, +:c:func:`AddrCopy()`, and :c:func:`AddrComp()`. When :c:type:`Addr` is compatible with +``void *``, these are implemented through the functions +:c:func:`mps_lib_memset()`, :c:func:`mps_lib_memcpy()`, and :c:func:`mps_lib_memcmp()` +functions in the plinth (impl.h.mpm). + +.. note:: + + No other implementation exists at present. pekka 1998-09-07 + +:mps:tag:`addr.conv.c` :c:type:`Addr` is converted to :c:type:`mps_addr_t` in the MPS C +Interface. :c:type:`mps_addr_t` is defined to be the same as ``void *``, so +using the MPS C Interface confines the memory manager to the same +address space as the client data. + + +.. c:type:: Word Size + +:mps:tag:`size` :c:type:`Size` is an unsigned integral type large enough to +hold the size of any object which the MPS might manage. + +:mps:tag:`size.byte` :c:type:`Size` should hold a size calculated in bytes. + +.. warning:: This may not be true for all existing code. + +:mps:tag:`size.use` :c:type:`Size` should be used whenever the code needs to deal +with the size of managed memory or client objects. It should not be +used for the sizes of the memory manager's own data structures, so +that the memory manager is amenable to working in a separate address +space. Be careful not to confuse it with ``size_t``. + +:mps:tag:`size.ops` :c:func:`SizeIsAligned()`, :c:func:`SizeAlignUp()`, +:c:func:`SizeAlignDown()` and :c:func:`SizeRoundUp()`. + +:mps:tag:`size.conv.c` :c:type:`Size` is converted to ``size_t`` in the MPS C +Interface. This constrains the memory manager to the same address +space as the client data. + + +.. c:type:: Word Align + +:mps:tag:`align` :c:type:`Align` is an unsigned integral type which is used to +represent the alignment of managed addresses. All alignments are +positive powers of two. :c:type:`Align` is large enough to hold the maximum +possible alignment. + +:mps:tag:`align.use` :c:type:`Align` should be used whenever the code needs to +deal with the alignment of a managed address. + +:mps:tag:`align.conv.c` :c:type:`Align` is converted to :c:type:`mps_align_t` in the MPS +C Interface. + + +.. c:type:: unsigned Shift + +:mps:tag:`shift` :c:type:`Shift` is an unsigned integral type which can hold the +amount by which a :c:type:`Word` can be shifted. It is therefore large +enough to hold the word width (in bits). + +:mps:tag:`shift.use` :c:type:`Shift` should be used whenever a shift value (the +right-hand operand of the ``<<`` or ``>>`` operators) is intended, to +make the code clear. It should also be used for structure fields which +have this use. + +:mps:tag:`shift.conv.c` :c:type:`Shift` is converted to :c:type:`mps_shift_t` in the MPS +C Interface. + + +.. c:type:: Addr Ref + +:mps:tag:`ref` :c:type:`Ref` is a reference to a managed object (as opposed to any +old managed address). :c:type:`Ref` should be used where a reference is +intended. + +.. note:: This isn't too clear -- richard + + +.. c:type:: Word RefSet + +:mps:tag:`refset` ``RefSet`` is a conservative approximation to a set of +references. See design.mps.refset. + + +.. c:type:: unsigned Rank + +:mps:tag:`rank` :c:type:`Rank` is an enumeration which represents the rank of a +reference. The ranks are: + +============= ===== ===================================================== +Rank Index Description +============= ===== ===================================================== +``RankAMBIG`` 0 The reference is ambiguous. That is, it must be + assumed to be a reference, but not updated in case it + isn't. +------------- ----- ----------------------------------------------------- +``RankEXACT`` 1 The reference is exact, and refers to an object. +------------- ----- ----------------------------------------------------- +``RankFINAL`` 2 The reference is exact and final, so special action + is required if only final or weak references remain + to the object. +------------- ----- ----------------------------------------------------- +``RankWEAK`` 3 The reference is exact and weak, so should be deleted + if only weak references remain to the object. +============= ===== ===================================================== + +:c:type:`Rank` is stored with segments and roots, and passed around. + +:c:type:`Rank` is converted to :c:type:`mps_rank_t` in the MPS C Interface. + +The ordering of the ranks is important. It is the order in which the +references must be scanned in order to respect the properties of +references of the ranks. Therefore they are declared explicitly with +their integer values. + +.. note:: Could :c:type:`Rank` be a ``short``? + +.. note:: + + This documentation should be expanded and moved to its own + document, then referenced from the implementation more thoroughly. + + +.. c:type:: Size Epoch + +:mps:tag:`epoch` An :c:type:`Epoch` is a count of the number of flips that have +occurred. It is used in the implementation of location dependencies. + +:c:type:`Epoch` is converted to :c:type:`mps_word_t` in the MPS C Interface, as a +field of :c:type:`mps_ld_s`. + + +.. c:type:: unsigned TraceId + +:mps:tag:`traceid` A :c:type:`TraceId` is an unsigned integer which is less than +:c:macro:`TRACE_MAX`. Each running trace has a different :c:type:`TraceId` which is +used to index into tables and bitfields used to remember the state of +that trace. + + +.. c:type:: unsigned TraceSet + +:mps:tag:`traceset` A :c:type:`TraceSet` is a bitset of :c:type:`TraceId`, +represented in the obvious way:: + + member(ti, ts) ⇔ ((1<base`` is the aligned pointer, +``vm->block`` is the pointer returned by :c:func:`malloc()`, which is used +in :c:func:`VMDestroy()`. + + diff --git a/mps/manual/html/_sources/design/vmo1.txt b/mps/manual/html/_sources/design/vmo1.txt new file mode 100644 index 00000000000..6715c5bd01f --- /dev/null +++ b/mps/manual/html/_sources/design/vmo1.txt @@ -0,0 +1,55 @@ +.. _design-vmo1: + + +.. index:: + pair: VM for Digital Unix; design + + +VM for Digital Unix +=================== + +.. mps:prefix:: design.mps.vmo1 + + +.. warning:: + + As of 2013-05-26, the MPS is no longer supported on Digital Unix, + so this document is only of historical interest. + + +Introduction +------------ + +:mps:tag:`readership` Any MPS developer. + +:mps:tag:`intro` This is the design of the VM Module for Digital UNIX (also +known as OSF/1 and Tru64 Unix; see os.o1). In general aspects +(including interface) the design is as for design.mps.vm. + + +Functions +--------- + +:mps:tag:`fun.unmap` :c:func:`VMUnmap()` "unmaps" a region by replacing the +existing mapping with a mapping using the ``vm->none_fd`` file +descriptor (see mumble mumble, :c:func:`VMCreate()`), and protection set to +:c:macro:`PROT_NONE` (that is, no access). + +:mps:tag:`fun.unmap.justify` Replacing the mapping in this way means that +the address space is still reserved and will not be used by calls to +:c:func:`mmap()` (perhaps in other libraries) which specify +:c:macro:`MAP_VARIABLE`. + +:mps:tag:`fun.unmap.offset` The offset for this mapping is the offset of the +region being unmapped in the VM; this gives the same effect as if +there was one mapping of the ``vm->none_fd`` from the base to the +limit of the VM (but "behind" all the other mappings that have been +created). + +:mps:tag:`fun.unmap.offset.justify` If this is not done (if for example the +offset is always specified as 0) then the VM will cause the kernel to +create a new file reference for each mapping created with +:c:func:`VMUnmap()`; eventually the kernel refuses the :c:func:`mmap()` call because it +can't create a new file reference. + + diff --git a/mps/manual/html/_sources/design/vmso.txt b/mps/manual/html/_sources/design/vmso.txt new file mode 100644 index 00000000000..561a07dec5e --- /dev/null +++ b/mps/manual/html/_sources/design/vmso.txt @@ -0,0 +1,140 @@ +.. _design-vmso: + + +.. index:: + pair: VM for Solaris; design + + +VM for Solaris +============== + +.. mps:prefix:: design.mps.vmso + +.. warning:: + + As of 2013-05-26, the MPS is no longer supported on Solaris, so + this document is only of historical interest. + + +Introduction +------------ + +:mps:tag:`intro` This is the design for the VM implementation on Solaris 2.x +(see os.so for OS details). The implementation is in MMsrc!vmso.c +(impl.c.vm). The design follows the design for and implements the +contract of the generic VM interface (design.mps.vm). To summarize: +The VM module provides a mechanism to reserve large (relative to the +amount of RAM) amounts of address space, and functions to map (back +with RAM) and unmap portions of this address space. + +:mps:tag:`source` Much of the implementation (and hence the design) was +inherited from the SunOS4 implementation. Not that there's any design +for that. You'll find the ``mmap(2)`` (for the system call :c:func:`mmap()`) +and the ``zero(7d)`` (for the device ``/dev/zero``) man pages useful +as well. The generic interface and some generic design is in +design.mps.vm. + + +Definitions +----------- + +:mps:tag:`def` See design.mps.vm.def.* for definitions common to all VMs. + + +Overview +-------- + +:mps:tag:`over` The system calls :c:func:`mmap()` and :c:func:`munmap()` are used to +access the underlying functionality. They are used in slightly unusual +ways, typically to overcome baroque features or implementation details +of the operating system. + +:mps:tag:`over.reserve` In order to reserve address space, a mapping to a +file (``/etc/passwd`` as it happens) is created with no protection +allowed. + +:mps:tag:`over.map` In order to map memory, a mapping to ``/dev/zero`` is +created. + +:mps:tag:`over.destroy` When the VM is destroyed, :c:func:`munmap()` is used to +remove all the mappings previously created. + + +Implementation +-------------- + +:mps:tag:`impl.create` :c:func:`VMCreate()` + +:mps:tag:`impl.create.vmstruct` Enough pages to hold the :c:type:`VMStruct` are +allocated by creating a mapping to ``/dev/zero`` (a read/write private +mapping), and using initializing the memory as a :c:type:`VMStruct`. + +:mps:tag:`impl.create.reserve` The size parameter is rounded up to page size +and this amount of address space is reserved. The address space is +reserved by creating a shared mapping to ``/etc/passwd`` with no +access allowed (the ``prot`` argument is :c:macro:`PROT_NONE`, and the +``flags`` argument is :c:macro:`MAP_SHARED`). + +:mps:tag:`impl.create.reserve.mmap.justify` :c:func:`mmap()` gives us a flexible +way to allocate address space without interfering with any other +component in the process. Because we don't specify :c:macro:`MAP_FIXED` we +are guaranteed to get a range of addresses that are not in use. Other +components must cooperate by not attempting to create mappings +specifying :c:macro:`MAP_FIXED` and an address in the range that the MPS has +reserved. + +:mps:tag:`impl.create.reserve.passwd.justify` Mapping ``/etc/passwd`` like +this worked on SunOS 4 (so this implementation inherited it). Mapping +``/dev/zero`` with ``prot=PROT_NONE`` and ``flags=MAP_PRIVATE`` does +not work because Solaris gratuitously allocates swap (even though you +can't use the memory). + +:mps:tag:`impl.create.reserve.improve` However, it would appears that or-ing +in :c:macro:`MAP_NORESERVE` mapping ``/dev/zero`` will reserve address space +without allocating swap, so this might be worth trying. That is, with +``prot=PROT_NONE`` and ``flags=MAP_PRIVATE|MAP_NORESERVE``. However +the following caveat comes from the original implementation: +"Experiments have shown that attempting to reserve address space by +mapping ``/dev/zero`` results in swap being reserved. This appears to +be a bug, so we work round it by using ``/etc/passwd``, the only file +we can think of which is pretty much guaranteed to be around." So that +might not work after all. + +:mps:tag:`impl.map` :c:func:`VMMap()` + +:mps:tag:`impl.map.zero` A mapping to ``/dev/zero`` is created at the +relevant addresses (overriding the map to ``/etc/passwd`` that was +previously in place for those addresses). The ``prot`` argument is +specified as ``PROT_READ|PROT_WRITE|PROT_EXEC`` (so that any access is +allowed), the ``flags`` argument as ``MAP_PRIVATE|MAP_FIXED``. The +flag :c:macro:`MAP_PRIVATE` means that the mapping is not shared with child +processes (child processes will have a mapping, but changes to the +memory will not be shared). The flag :c:macro:`MAP_FIXED` guarantees that we +get the mapping at the specified address). The ``zero(7d)`` man page +documents this as a way to create a "zero-initialized unnamed memory +object". + +:mps:tag:`impl.map.error` If there's not enough swap space for the mapping, +:c:func:`mmap()` will return :c:macro:`EAGAIN`, not :c:macro:`ENOMEM`, although you might +not think so from the man page. + +:mps:tag:`impl.unmap` :c:func:`VMUnmap()` + +:mps:tag:`impl.unmap.reserve` The relevant addresses are returned to the +reserved state by creating a mapping to ``/etc/passwd`` (overriding +the map ``/dev/zero`` that was previously in place for those +addresses). As for :c:func:`VMCreate()` (see :mps:ref:`.impl.create.reserve` above) +the ``prot`` argument is :c:macro:`PROT_NONE`, but the ``flags`` argument has +the addition :c:macro:`MAP_FIXED` flags (so is ``MAP_SHARED|MAP_FIXED``). + +:mps:tag:`impl.unmap.reserve.offset` The offset argument is specified to be +the offset of the addresses being unmapped from the base of the +reserved VM area. + +:mps:tag:`impl.unmap.reserve.offset.justify` Not specifying the offset like +this makes Solaris create a separate mapping (in the kernel) each time +Unmap is used, eventually the call to :c:func:`mmap()` will fail. Specifying +offset like this does not cause Solaris to create any extra mappings, +the existing mapping to ``/etc/passwd`` gets reused. + + diff --git a/mps/manual/html/_sources/design/writef.txt b/mps/manual/html/_sources/design/writef.txt index a771bd72375..6d442ee1f01 100644 --- a/mps/manual/html/_sources/design/writef.txt +++ b/mps/manual/html/_sources/design/writef.txt @@ -1,6 +1,107 @@ +.. _design-writef: + + .. index:: pair: WriteF function; design -.. _design-writef: -.. include:: ../../converted/writef.rst +The WriteF function +=================== + +.. mps:prefix:: design.mps.writef + + +Introduction +------------ + +:mps:tag:`intro` This document describes the :c:func:`WriteF()` function, which +allows formatted output in a manner similar to ANSI C ``printf``, but +allows the MPM to operate in a freestanding environment (see +design.mps.exec-env). + +:mps:tag:`background` The documents design.mps.exec-env and design.mps.lib +describe the design of the library interface and the reason that it +exists. + + +Design +------ + +:mps:tag:`no-printf` There is no dependency on :c:func:`printf()`. The MPM only +depends on :c:func:`fputc()` and :c:func:`fputs()`, via the Library Interface +(design.mps.lib). This makes it much easier to deploy the MPS in a +freestanding environment. This is achieved by implementing our own +internal output routines in mpm.c. + +Our output requirements are few, so the code is short. The only output +function which should be used in the rest of the MPM is :c:func:`WriteF()`, +which is similar to :c:func:`fprintf()`: + +.. c:function:: Res WriteF(mps_lib_FILE *stream, ...) + +:c:func:`WriteF()` expects a format string followed by zero or more items to +insert into the output, followed by another format string, more items, +and so on, and finally a :c:macro:`NULL` format string. For example:: + + WriteF(stream, + "Hello: $A\n", address, + "Spong: $U ($S)\n", number, string, + NULL); + +This makes :c:func:`Describe()` methods much easier to write. For example, :c:func:`BufferDescribe()` might contain the following code:: + + WriteF(stream, + "Buffer $P ($U) {\n", (WriteFP)buffer, (WriteFU)buffer->serial, + " base $A init $A alloc $A limit $A\n", + (WriteFA)buffer->base, (WriteFA)buffer->ap.init, + (WriteFA)buffer->ap.alloc, (WriteFA)buffer->ap.limit, + " Pool $P\n", (WriteFP)buffer->pool, + " Seg $P\n", (WriteFP)buffer->seg, + " rank $U\n", (WriteFU)buffer->rank, + " alignment $W\n", (WriteFW)buffer->alignment, + " grey $B\n", (WriteFB)buffer->grey, + " shieldMode $B\n", (WriteFB)buffer->shieldMode, + " p $P i $U\n", (WriteFP)buffer->p, (WriteFU)buffer->i, + "} Buffer $P ($U)\n", (WriteFP)buffer, (WriteFU)buffer->serial, + NULL); + +:mps:tag:`types` For each format ``$X`` that :c:func:`WriteF()` supports, there is a +type defined in impl.h.mpmtypes :c:func:`WriteFX()` which is the promoted +version of that type. These are provided both to ensure promotion and +to avoid any confusion about what type should be used in a cast. It is +easy to check the casts against the formats to ensure that they +correspond. + +:mps:tag:`types.future` It is possibly that this type set or similar may be +used in future in some generalisation of varargs in the MPS. + +:mps:tag:`formats` The formats supported are as follows. + +======= =========== ================== ====================================== +Code Bame Type Example rendering +======= =========== ================== ====================================== +``$A`` address :c:type:`Addr` ``000000019EF60010`` +``$P`` pointer ``void *`` ``000000019EF60100`` +``$F`` function ``void *(*)()`` ``0001D69E01000000`` (see `.f`_) +``$S`` string ``char *`` ``hello`` +``$C`` character ``char`` ``x`` +``$W`` word :c:type:`ULongest` ``0000000000109AE0`` +``$U`` decimal :c:type:`ULongest` ``42`` +``$B`` binary :c:type:`ULongest` ``00000000000000001011011110010001`` +``$$`` dollar -- ``$`` +======= =========== ================== ====================================== + +Note that ``WriteFC`` is an ``int``, because that is the default +promotion of a ``char`` (see :mps:ref:`.types`). + +:mps:tag:`snazzy` We should resist the temptation to make :c:func:`WriteF()` an +incredible snazzy output engine. We only need it for :c:func:`Describe()` +methods and assertion messages. At the moment it's a very simple bit +of code -- let's keep it that way. + +_`.f`: The ``F`` code is used for function pointers. ISO C forbids casting +function pointers to other types, so the bytes of their representation are +written sequentially, and may have a different endianness to other pointers. +Could be smarter, or even look up function names, but see :mps:ref:`.snazzy`. + + diff --git a/mps/manual/html/_sources/glossary/_Sidebar.txt b/mps/manual/html/_sources/glossary/_Sidebar.txt new file mode 100644 index 00000000000..e0e50826e07 --- /dev/null +++ b/mps/manual/html/_sources/glossary/_Sidebar.txt @@ -0,0 +1,2 @@ +* `Ravenbrook `_ +* `Google `_ diff --git a/mps/manual/html/_sources/glossary/home.txt b/mps/manual/html/_sources/glossary/home.txt new file mode 100644 index 00000000000..bb55975bf97 --- /dev/null +++ b/mps/manual/html/_sources/glossary/home.txt @@ -0,0 +1,33 @@ +.. _glossary: + +Memory Management Glossary +************************** + +.. include:: alphabet.txt + +.. toctree:: + :maxdepth: 1 + + a + b + c + d + e + f + g + h + i + k + l + m + n + o + p + q + r + s + t + u + v + w + z diff --git a/mps/manual/html/_sources/guide/advanced.txt b/mps/manual/html/_sources/guide/advanced.txt index a6604daf573..6835359e717 100644 --- a/mps/manual/html/_sources/guide/advanced.txt +++ b/mps/manual/html/_sources/guide/advanced.txt @@ -876,7 +876,11 @@ Segregation of objects When objects of different types have different properties (different sizes, lifetimes, references, layouts) it makes sense to segregate -them into pools of appropriate classes. +them into pools of appropriate classes. The garbage collector in the +MPS is designed to work efficiently with many pools: it traces +references between objects in different pools, and it coordinates the +scanning of the :term:`registers` and :term:`control stacks` (see +:ref:`topic-root-thread`). For example, the toy Scheme interpreter has a mixture of object types, some of which contain references to other objects (for example, pairs) diff --git a/mps/manual/html/_sources/guide/debug.txt b/mps/manual/html/_sources/guide/debug.txt index c38e09dbbec..e9fc93f951e 100644 --- a/mps/manual/html/_sources/guide/debug.txt +++ b/mps/manual/html/_sources/guide/debug.txt @@ -87,11 +87,11 @@ General debugging advice set dont-handle-bad-access 1 handle SIGBUS pass nostop noprint - If you are using GDB on Linux, run this command:: + If you are using GDB on Linux or FreeBSD, run this command:: - handle SIGXFSZ pass nostop noprint + handle SIGSEGV pass nostop noprint - (On either operating system, you can add these commands to your + (On these operating systems, you can add these commands to your ``.gdbinit`` if you always want them to be run.) diff --git a/mps/manual/html/_sources/guide/overview.txt b/mps/manual/html/_sources/guide/overview.txt index 322d9ea6258..02925361069 100644 --- a/mps/manual/html/_sources/guide/overview.txt +++ b/mps/manual/html/_sources/guide/overview.txt @@ -111,21 +111,24 @@ for example by calling :c:func:`mps_free`) and others are **scan** for :term:`references` to allocated blocks. See :ref:`topic-scanning`. -The arena needs you to tell it how to find your **roots**: references to -allocated blocks that are stored in static data, in memory not managed -by the MPS, or on your program's :term:`registers` or +The arena needs you to tell it how to find your **roots**: references +to allocated blocks that are stored in static data, in memory not +managed by the MPS, in your program's :term:`registers`, or on its :term:`control stack`. See :ref:`topic-root`. The MPS is designed to work with multi-threaded programs. Functions in -the C interface are thread safe, except in a few documented -cases. See :ref:`topic-thread`. The :term:`allocation point -protocol` provides fast lock-free allocation on multiple threads -simultaneously. See :ref:`topic-allocation`. +the C interface are thread safe, except in a few documented cases. See +:ref:`topic-thread`. The :term:`allocation point protocol` provides +fast lock-free allocation on multiple threads simultaneously. See +:ref:`topic-allocation`. The garbage collector is :term:`incremental `: it proceeds in small steps interleaved with the execution -of your program, so there are no long waits. See -:ref:`topic-collection`. +collection>`: it proceeds in small steps interleaved with the +execution of your program, so there are no long waits. The garbage +collector is designed to work efficiently with multiple pools, and +in cases where there are many references between objects in different +pools. See :ref:`topic-collection`. + What next? diff --git a/mps/manual/html/_sources/pool/intro.txt b/mps/manual/html/_sources/pool/intro.txt index 2346e1637bd..ca7d1265edc 100644 --- a/mps/manual/html/_sources/pool/intro.txt +++ b/mps/manual/html/_sources/pool/intro.txt @@ -92,7 +92,7 @@ Property AMC AMCZ AMS AWL LO ============================================= ===== ===== ===== ===== ===== ===== ===== ===== ===== ===== Supports :c:func:`mps_alloc`? no no no no no yes yes yes no no Supports :c:func:`mps_free`? no no no no no yes yes yes yes no -Supports allocation points? yes yes yes yes yes no no yes yes yes +Supports allocation points? yes yes yes yes yes no yes yes yes yes Supports allocation frames? yes yes yes yes yes no no yes yes yes Supports segregated allocation caches? no no no no no yes yes yes no no Timing of collections? [2]_ auto auto auto auto auto --- --- --- --- --- diff --git a/mps/manual/html/_sources/pool/mfs.txt b/mps/manual/html/_sources/pool/mfs.txt index b13870006df..66071937bcf 100644 --- a/mps/manual/html/_sources/pool/mfs.txt +++ b/mps/manual/html/_sources/pool/mfs.txt @@ -11,13 +11,16 @@ MFS (Manual Fixed Small) :term:`pool class` for small objects of fixed size. Unlike other manual pool classes, it is not subject to :term:`internal -fragmentation`. +fragmentation`: if the population remains bounded, the memory usage +remains bounded too. On the other hand, unlike :ref:`pool-mvt` and +:ref:`pool-mvff` it does not return unused memory to the arena for +reuse by other pools. -The implementation is very simple: unlike other :term:`pool classes` -which store their control structures separately from the allocated -blocks, MFS maintains a stack of free blocks using a pointer in the -free block. :c:func:`mps_alloc` pops this stack and :c:func:`mps_free` -pushes it. +The implementation is very simple: unlike most other :term:`pool +classes` which store their control structures separately from the +allocated blocks, MFS maintains a stack of free blocks using a pointer +in the free block. :c:func:`mps_alloc` pops this stack and +:c:func:`mps_free` pushes it. .. index:: diff --git a/mps/manual/html/_sources/pool/mvff.txt b/mps/manual/html/_sources/pool/mvff.txt index 2fc57c59c66..c7f358abcdb 100644 --- a/mps/manual/html/_sources/pool/mvff.txt +++ b/mps/manual/html/_sources/pool/mvff.txt @@ -202,7 +202,7 @@ MVFF interface :c:macro:`MPS_KEY_MVFF_SLOT_HIGH`, and :c:macro:`MPS_KEY_MVFF_FIRST_FIT` are as described above, and :c:macro:`MPS_KEY_POOL_DEBUG_OPTIONS` specifies the debugging - :c:options. See :c:type:`mps_debug_option_s`. + options. See :c:type:`mps_debug_option_s`. .. deprecated:: starting with version 1.112. diff --git a/mps/manual/html/_sources/topic/collection.txt b/mps/manual/html/_sources/topic/collection.txt index bad646ea8e5..af1c18dfce9 100644 --- a/mps/manual/html/_sources/topic/collection.txt +++ b/mps/manual/html/_sources/topic/collection.txt @@ -13,6 +13,13 @@ Garbage collection ================== +The :term:`arena` contains a :term:`garbage collector` that +coordinates the collection of garbage in all of its +:term:`automatically managed ` +:term:`pools`. The collector efficiently traces references between +:term:`roots` and pools, and between objects in different pools. It is +capable of collecting many automatically managed pools simultaneously. + .. index:: single: chain; generation diff --git a/mps/manual/html/_sources/topic/error.txt b/mps/manual/html/_sources/topic/error.txt index 805f50af3bf..abf1a1c2600 100644 --- a/mps/manual/html/_sources/topic/error.txt +++ b/mps/manual/html/_sources/topic/error.txt @@ -188,13 +188,43 @@ than the client program, but it is not unknown, so if you have made every effort to track down the cause (see :ref:`guide-debug`) without luck, :ref:`get in touch `. + +.. index:: + single: assertion + single: error handling; assertion; assertion handling + +.. _topic-error-assertion-handling: + +Assertion handling +.................. + +When the MPS detects an assertion failure, it calls the :term:`plinth` +function :c:func:`mps_lib_assert_fail`. Unless you have replaced the plinth, this behaves as follows: + +- In the :term:`cool` :term:`variety`, print the assertion message to + standard error and terminate the program by calling :c:func:`abort`. + +- In the :term:`hot` and :term:`rash` varieties, print the assertion + message to standard error and do *not* terminate the program. + +You can change this behaviour by providing your own plinth, or using +:c:func:`mps_lib_assert_fail_install`. + +In many applications, users don't want their program terminated when +the MPS detects an error, no matter how severe. A lot of MPS +assertions indicate that the program is going to crash very soon, but +there still may be a chance for a user to get some useful results or +save their work. This is why the default assertion handler only +terminates in the :term:`cool` :term:`variety`. + + .. index:: single: assertion; common causes .. _topic-error-cause: Common assertions and their causes ----------------------------------- +.................................. This section lists some commonly encountered assertions and suggests likely causes. If you encounter an assertion not listed here (or an @@ -264,30 +294,6 @@ this documentation. condition? -.. index:: - single: assertion - single: error handling; assertion; assertion handling - -.. _topic-error-assertion-handling: - -Assertion Handling ------------------- - -When the MPS detects an assertion failure, it calls the :term:`plinth` -function :c:func:`mps_lib_assert_fail`. If you have not replaced the -plinth, this will print the assertion message and terminate the program -in the :term:`cool` :term:`variety`, but *not* in the :term:`hot` or -:term:`rash` varieties. You can change this behaviour by providing your -own plinth, or using :c:func:`mps_lib_assert_fail_install`. - -In many applications, users don't want their program terminated when the -MPS detects an error, no matter how severe. A lot of MPS assertions -indicate that the program is going to crash very soon, but there still -may be a chance for a user to get some useful results or save their -work. This is why the default assertion handler only terminates in the -:term:`cool` :term:`variety`. - - .. index:: single: error handling; varieties single: variety diff --git a/mps/manual/html/_sources/topic/plinth.txt b/mps/manual/html/_sources/topic/plinth.txt index fc50e847a0e..41866ed76e0 100644 --- a/mps/manual/html/_sources/topic/plinth.txt +++ b/mps/manual/html/_sources/topic/plinth.txt @@ -116,8 +116,8 @@ I/O module .. note:: - In the ANSI I/O module, ``mpsioan.c``, this calls ``fopen`` on - the file named by the environment variable + In the ANSI I/O module, ``mpsioan.c``, this calls + :c:func:`fopen` on the file named by the environment variable :envvar:`MPS_TELEMETRY_FILENAME`. @@ -134,7 +134,8 @@ I/O module .. note:: - In the ANSI I/O module, ``mpsioan.c``, this calls ``fclose``. + In the ANSI I/O module, ``mpsioan.c``, this calls + :c:func:`fclose`. .. c:function:: mps_res_t mps_io_write(mps_io_t io, void *buf, size_t size) @@ -153,7 +154,8 @@ I/O module .. note:: - In the ANSI I/O module, ``mpsioan.c``, this calls ``fwrite``. + In the ANSI I/O module, ``mpsioan.c``, this calls + :c:func:`fwrite`. .. c:function:: mps_res_t mps_io_flush(mps_io_t io) @@ -177,7 +179,8 @@ I/O module .. note:: - In the ANSI I/O module, ``mpsioan.c``, this calls ``fflush``. + In the ANSI I/O module, ``mpsioan.c``, this calls + :c:func:`fflush`. .. index:: @@ -246,9 +249,9 @@ Library module In the ANSI Library module, ``mpsliban.c``, this reports the failure using ``fprintf(stderr, "...%s...", message)`` and, in the :term:`cool` :term:`variety`, terminates the program by - calling ``abort``. You can change this behaviour with - :c:func:`mps_lib_assert_fail_install`. For a discussion of - the default behaviour, see :ref:`topic-error-assertion-handling`. + calling :c:func:`abort`. You can change this behaviour with + :c:func:`mps_lib_assert_fail_install`. For a discussion of the + default behaviour, see :ref:`topic-error-assertion-handling`. .. c:function:: extern mps_lib_assert_fail_t mps_lib_assert_fail_install(mps_lib_assert_fail_t handler) @@ -292,13 +295,13 @@ Library module :c:func:`mps_lib_get_EOF` if not. This function is intended to have the same semantics as the - ``fputc`` function of the ANSI C Standard (:ref:`ISO/IEC 9899:1990 - ` §7.11.7.3). + :c:func:`fputc` function of the ANSI C Standard (:ref:`ISO/IEC + 9899:1990 ` §7.11.7.3). .. note:: In the ANSI Library module, ``mpsliban.c``, this is a simple - wrapper around ``fputc``. + wrapper around :c:func:`fputc`. .. c:function:: int mps_lib_fputs(const char *s, mps_lib_FILE *stream) @@ -310,8 +313,8 @@ Library module ``stream`` is the stream. This function is intended to have the same semantics as the - ``fputs`` function of the ANSI C Standard (:ref:`ISO/IEC 9899:1990 - ` §7.11.7.4). + :c:func:`fputs` function of the ANSI C Standard (:ref:`ISO/IEC + 9899:1990 ` §7.11.7.4). Return a non-negative integer if successful, or :c:func:`mps_lib_get_EOF` if not. @@ -319,7 +322,7 @@ Library module .. note:: In the ANSI Library module, ``mpsliban.c``, this is a simple - wrapper around ``fputs``. + wrapper around :c:func:`fputs`. .. c:function:: int mps_lib_get_EOF(void) @@ -367,7 +370,7 @@ Library module .. c:function:: int mps_lib_memcmp(const void *s1, const void *s2, size_t n) A :term:`plinth` function similar to the standard :term:`C` - function ``memcmp``. + function :c:func:`memcmp`. ``s1`` and ``s2`` point to :term:`blocks` of memory to be compared. @@ -379,19 +382,19 @@ Library module equal to, or less than the block pointed to by ``s2``. This function is intended to have the same semantics as the - ``memcmp`` function of the ANSI C Standard (:ref:`ISO/IEC + :c:func:`memcmp` function of the ANSI C Standard (:ref:`ISO/IEC 9899:1990 ` §7.11.4.1). .. note:: In the ANSI Library module, ``mpsliban.c``, this is a simple - wrapper around ``memcmp``. + wrapper around :c:func:`memcmp`. .. c:function:: void *mps_lib_memcpy(void *dest, const void *source, size_t n) A :term:`plinth` function similar to the standard :term:`C` - function ``memcpy``. + function :c:func:`memcpy`. ``dest`` points to the destination. @@ -402,7 +405,7 @@ Library module Returns ``dest``. This function is intended to have the same semantics as the - ``memcpy`` function of the ANSI C Standard (:ref:`ISO/IEC + :c:func:`memcpy` function of the ANSI C Standard (:ref:`ISO/IEC 9899:1990 ` §7.11.2.1). The MPS never passes overlapping blocks to @@ -411,13 +414,13 @@ Library module .. note:: In the ANSI Library module, ``mpsliban.c``, this is a simple - wrapper around ``memcpy``. + wrapper around :c:func:`memcpy`. .. c:function:: void *mps_lib_memset(void *s, int c, size_t n) A :term:`plinth` function similar to the standard :term:`C` - function ``memset``. + function :c:func:`memset`. ``s`` points to the :term:`block` to fill with the byte ``c``. @@ -428,13 +431,13 @@ Library module Returns ``s``. This function is intended to have the same semantics as the - ``memset`` function of the ANSI C Standard (:ref:`ISO/IEC + :c:func:`memset` function of the ANSI C Standard (:ref:`ISO/IEC 9899:1990 ` §7.11.6.1). .. note:: In the ANSI Library module, ``mpsliban.c``, this is a simple - wrapper around ``memset``. + wrapper around :c:func:`memset`. .. note:: diff --git a/mps/manual/html/_sources/topic/root.txt b/mps/manual/html/_sources/topic/root.txt index 823996f0d0e..28e2d08ada3 100644 --- a/mps/manual/html/_sources/topic/root.txt +++ b/mps/manual/html/_sources/topic/root.txt @@ -37,15 +37,17 @@ You can register a root at any time by calling one of the no two roots may overlap (that is, each reference is :term:`fixed` by at most one root). Roots may be: -1. on the program's :term:`control stack`; +1. in :term:`registers`; -2. in the program's static data; +2. on the program's :term:`control stack`; -3. in :term:`heap` not managed by the MPS (provided that you destroy +3. in the program's static data; + +4. in :term:`heap` not managed by the MPS (provided that you destroy the root before freeing it; see :ref:`the Scheme interpreter's global symbol table ` for an example); -4. in :term:`manually managed ` pools +5. in :term:`manually managed ` pools (provided that you remove the root before freeing it). Roots must not be in memory that is subject to :term:`garbage @@ -99,7 +101,7 @@ scan it for references: table of :term:`tagged references`; 5. :c:func:`mps_root_create_reg` if the root consists of the - registers and control stack of a thread. See + :term:`registers` and :term:`control stack` of a thread. See :ref:`topic-root-thread` below. diff --git a/mps/manual/html/_static/logo.png b/mps/manual/html/_static/logo.png index 42756c08d7a..f60476aa6ca 100644 Binary files a/mps/manual/html/_static/logo.png and b/mps/manual/html/_static/logo.png differ diff --git a/mps/manual/html/_static/pygments.css b/mps/manual/html/_static/pygments.css index 1a14f2ae1ab..d79caa151c2 100644 --- a/mps/manual/html/_static/pygments.css +++ b/mps/manual/html/_static/pygments.css @@ -13,11 +13,11 @@ .highlight .gr { color: #FF0000 } /* Generic.Error */ .highlight .gh { color: #000080; font-weight: bold } /* Generic.Heading */ .highlight .gi { color: #00A000 } /* Generic.Inserted */ -.highlight .go { color: #303030 } /* Generic.Output */ +.highlight .go { color: #333333 } /* Generic.Output */ .highlight .gp { color: #c65d09; font-weight: bold } /* Generic.Prompt */ .highlight .gs { font-weight: bold } /* Generic.Strong */ .highlight .gu { color: #800080; font-weight: bold } /* Generic.Subheading */ -.highlight .gt { color: #0040D0 } /* Generic.Traceback */ +.highlight .gt { color: #0044DD } /* Generic.Traceback */ .highlight .kc { color: #007020; font-weight: bold } /* Keyword.Constant */ .highlight .kd { color: #007020; font-weight: bold } /* Keyword.Declaration */ .highlight .kn { color: #007020; font-weight: bold } /* Keyword.Namespace */ diff --git a/mps/manual/html/design/alloc-frame.html b/mps/manual/html/design/alloc-frame.html new file mode 100644 index 00000000000..51d1c2656d6 --- /dev/null +++ b/mps/manual/html/design/alloc-frame.html @@ -0,0 +1,612 @@ + + + + + + + + + + 1. Allocation frame protocol — Memory Pool System 1.111.0 documentation + + + + + + + + + + + + + + + +
+

Navigation

+ +
+ +
+
+
+
+ +
+

1. Allocation frame protocol

+
+

1.1. Introduction

+

.intro: This document explains the design of the support for +allocation frames in MPS.

+

.readership: This document is intended for any MM developer.

+

.overview: Allocation frames are used for implementing stack pools; +each stack frame corresponds to an allocation frame. Allocation frames +may also be suitable for implementing other sub-pool groupings, such +as generations and ramp allocation patterns.

+

.overview.ambition: We now believe this to be a design that loses +too many advantages of stack allocation for questionable gains. The +requirements are almost entirely based on unanalysed anecdote, instead +of actual clients.

+
+

Note

+

We plan to supersede this with a stack pool design at some point +in the future. Pekka P. Pirinen, 2000-03-09.

+
+
+
+

1.2. Definitions

+

.def.alloc-frame: An allocation frame is a generic name for a +device which groups objects together with other objects at allocation +time, and which may have a parent/child relationship with other +allocation frames.

+
+
+

1.3. Purpose

+

.purpose.stack-allocation: The allocation frame protocol is +intended to support efficient memory management for stack allocation, +that is, the allocation of objects which have dynamic extent.

+

.purpose.general: The allocation frame protocol is intended to be +sufficiently general that it will be useful in supporting other types +of nested allocation patterns too. For example, it could be used to +for EPVM-style save and restore, ramp allocation patterns or +generations.

+
+
+

1.4. Requirements

+
+

1.4.1. Known requirements

+

.req.stack-alloc: Provide a interface for clients to describe a +stack allocation pattern, as an alternative to using the control +stack.

+

.req.efficient: Permit an implementation which is comparable in +efficiency to allocating on the control stack.

+

.req.ap: Support allocation via allocation points (APs).

+

.req.format: Support the allocation of formatted objects.

+

.req.scan: Ensure that objects in allocation frames can participate +in garbage collection by being scanned.

+

.req.fix: Ensure that objects in allocation frames can participate +in garbage collection by accepting Fix requests.

+

.req.condemn: Ensure that objects in allocation frames can +participate in garbage collection by being condemned.

+

.attr.locking: Minimize the synchronization cost for the creation +and destruction of frames.

+
+
+

1.4.2. Proto-requirements

+

.proto-req: The following are possible requirements that might be +important in the future. The design does not necessarily meet all +these requirements, but it does consider them all. Each requirement +either has direct support in the framework, or could be supported with +future additions to the framework.

+

.req.parallels: The allocation frame protocol should provide a +framework for exploiting the parallels between stack extents, +generations and “ramps”.

+

.req.pool-destroy: It should be possible to use allocation frames +to free all objects in a pool without destroying the pool.

+

.req.epvm: It should be possible to implement EPVM-style save and +restore operations by creating and destroying allocation frames.

+

.req.subst: It should be possible to substitute a stack pool with a +GC-ed pool so that erroneous use of a stack pool can be detected.

+

.req.format-extensions: It should be possible for stack pools to +utilize the same format as any other pool, including debugging formats +that include fenceposting, etc.

+

.req.mis-nest: Should ensure “mis-nested” stacks are safe.

+

.req.non-top-level: Should support allocation in the non-top stack +extent.

+

.req.copy-if-necessary: Should ensure that stack pools can support +“copy-if-necessary” (so that low-level system code can heapify stack +objects.)

+

.req.preserve: When an object is in an allocation frame which is +being destroyed, it should be possible to preserve that object in the +parent frame.

+

.req.contained: Should allow clients to ask if an object is +“contained” in a frame. The object is contained in a frame if it is +affected when the frame is ended.

+

.req.alloc-with-other: Should allow clients to allocate an object +in the same frame as another object.

+
+
+
+

1.5. Overview

+

.frame-classes: The protocol supports different types of allocation +frames, which are represented as “frame classes”. It’s up to pools to +determine which classes of allocation frames they support. Pools which +support more than one frame class rely on the client to indicate which +class is currently of interest. The client indicates this by means of +an operation which stores the class in the buffer to which the +allocation point is attached.

+

.frame-handles: Allocation frames are described via abstract “frame +handles”. Pools may choose what the representation of a frame handle +should be. Frame handles are static, and the client need not store +them in a GC root.

+

.lightweight-frames: The design includes an extension to the +allocation point protocol, which permits the creation and destruction +of allocation frames without the necessity for claiming the arena +lock. Such frames are called “lightweight frames”.

+
+
+

1.6. Operations

+

.op.intro: Each operation has both an external (client) interface +and an internal (MPS) interface. The external function takes an +allocation point as a parameter, determines which buffer and pool it +belongs to, and calls the internal function with the buffer and pool +as parameters.

+

.op.obligatory: The following operations are supported on any +allocation point which supports allocation frames:-

+

.operation.push: The PushFrame() operation creates a new +allocation frame of the currently chosen frame class, makes this new +frame the current frame, and returns a handle for the frame.

+

.operation.pop: The PopFrame() operation takes a frame handle +as a parameter. Some pool classes might insist or assume that this is +the handle for the current frame. It finds the parent of that frame +and makes it the current frame. The operation indicates that all +children of the new current frame contain objects which are likely to +be dead. The reclaim policy is up to the pool; some classes might +insist or assume that the objects must be dead, and eagerly free them. +Note that this might introduce the possibility of leaving dangling +pointers elsewhere in the arena. If so, it’s up to the pool to decide +what to do about this.

+

.op.optional: The following operations are supported for some +allocation frames, but not all. Pools may choose to support some or +all of these operations for certain frame classes. An unsupported +operation will return a failure value:-

+

.operation.select: The SelectFrame() operation takes a frame +handle as a parameter and makes that frame the current frame. It does +not indicate that any children of the current frame contain objects +which are likely to be dead.

+

.operation.select-addr: The SelectFrameOfAddr() operation takes +an address as a parameter and makes the frame of that address the +current frame. It does not indicate that any children of the current +frame contain objects which are likely to be dead.

+

.operation.in-frame: The AddrInFrame() operation determines +whether the supplied address is the address of an object allocated in +the supplied frame, or any child of that frame.

+

.operation.set: The SetFrameClass() operation takes a frame +class and an allocation point as parameters, and makes that the +current frame class for the allocation point. The next PushFrame() +operation will create a new frame of that class.

+
+
+

1.7. Interface

+
+

1.7.1. External types

+

.type.client.frame-handle: Frame handles are defined as the abstract +type mps_frame_t.

+
+
+struct mps_frame_class_s *mps_frame_class_t
+
+ +

.type.client.frame-class: Frame classes are defined as an abstract +type.

+

.type.client.frame-class.access: Clients access frame classes by +means of dedicated functions for each frame class.

+
+
+

1.7.2. External functions

+

.fn.client.push: mps_ap_frame_push() is used by clients to +invoke the PushFrame() operation. For lightweight frames, this +might not invoke the corresponding internal function.

+

.fn.client.pop: mps_ap_frame_pop() is used by clients to invoke +the PopFrame() operation. For lightweight frames, this might not +invoke the corresponding internal function.

+
+
+mps_res_t mps_ap_frame_select(mps_ap_t buf, mps_frame_t frame)
+
+ +

.fn.client.select: This following function is used by clients to +invoke the SelectFrame() operation.

+
+
+mps_res_t mps_ap_frame_select_from_addr(mps_ap_t buf, mps_addr_t addr)
+
+ +

.fn.client.select-addr: This function is used by clients to invoke +the SelectFrameOfAddr() operation.

+
+
+mps_res_t mps_ap_addr_in_frame(mps_bool_t *inframe_o, mps_ap_t buf, mps_addr_t *addrref, mps_frame_t frame)
+
+ +

.fn.client.in-frame: This function is used by clients to invoke the +AddrInFrame() operation.

+
+
+mps_res_t mps_ap_set_frame_class(mps_ap_t buf, mps_frame_class_t class)
+
+ +

.fn.client.set: This function is used by clients to invoke the +SetFrameClass() operation.

+
+
+mps_frame_class_t mps_alloc_frame_class_stack(void)
+
+ +

.fn.client.stack-frame-class: This function is used by clients to +access the frame class used for simple stack allocation.

+
+
+

1.7.3. Internal types

+
+
+struct AllocFrameStruct *AllocFrame
+
+ +

.type.frame-handle: Frame handles are defined as an abstract type.

+
+
+struct AllocFrameClassStruct *AllocFrameClass
+
+ +

.type.frame-class: Frame classes are defined as an abstract type.

+
+
+Res (*PoolFramePushMethod)(AllocFrame *frameReturn, Pool pool, Buffer buf)
+
+ +

.fn.push: A pool method of this type is called (if needed) to +invoke the PushFrame() operation.

+
+
+Res (*PoolFramePopMethod)(Pool pool, Buffer buf, AllocFrame frame)
+
+ +

.fn.pop: A pool method of this type is called (if needed) +to invoke the PopFrame operation:

+
+
+Res (*PoolFrameSelectMethod)(Pool pool, Buffer buf, AllocFrame frame)
+
+ +

.fn.select: A pool method of this type is called to invoke the +SelectFrame() operation.

+
+
+Res (*PoolFrameSelectFromAddrMethod)(Pool pool, Buffer buf, Addr addr)
+
+ +

.fn.select-addr: A pool method of this type is called to invoke the +SelectFrameOfAddr() operation.

+
+
+Res (*PoolAddrInFrameMethod)(Bool *inframeReturn, Pool pool, Seg seg, Addr *addrref, AllocFrame frame)
+
+ +

.fn.in-frame: A pool method of this type is called to invoke the +AddrInFrame() operation.

+
+
+Res (*PoolSetFrameClassMethod)(Pool pool, Buffer buf, AllocFrameClass class)
+
+ +

.fn.set: A pool method of this type is called to invoke the +SetFrameClass() operation.

+
+
+
+

1.8. Lightweight frames

+
+

1.8.1. Overview

+

.lw-frame.overview: Allocation points provide direct support for +lightweight frames, and are designed to permit PushFrame and PopFrame +operations without the need for locking and delegation to the pool +method. Pools can disable this mechanism for any allocation point, so +that the pool method is always called. The pool method will be called +whenever synchronization is required for other reasons (e.g. the +buffer is tripped).

+

.lw-frame.model: Lightweight frames offer direct support for a +particular model of allocation frame use, whereby the PushFrame +operation returns the current allocation pointer as a frame handle, +and the PopFrame operation causes the allocation pointer to be reset +to the address of the frame handle. This model should be suitable for +simple stack frames, where more advanced operations like SelectFrame +are not supported. It may also be suitable for more advanced +allocation frame models when they are being used simply. The use of a +complex operation always involves synchronization via locking, and the +pool may disable lightweight synchronization temporarily at this time.

+
+
+

1.8.2. State

+

.lw-frame.states: Allocation points supporting lightweight frames +will be in one of the following states:

+
++++ + + + + + + + + + + + +
ValidIndicates that PushFrame() can be a lightweight +operation and need not be synchronized.
PopPendingIndicates that there has been a PopFrame() operation +that the pool must respond to.
DisabledIndicates that the pool has disabled support for lightweight +operations for this AP.
+

These states are in addition to the state normally held by an AP for +allocation purposes. An AP will be in the Disabled state at creation.

+

.lw-frame.transitions: State transitions happen under the following +circumstances:

+ ++++ + + + + + + + + + + + + + + + + + + + + +
Valid → PopPendingAs a result of a client PopFrame() +operation.
Valid → DisabledAt the choice of the pool (for example, when +responding to a SelectFrame() operation).
PopPending → ValidAt the choice of the pool, when processing a +PopFrame().
PopPending → DisabledAt the choice of the pool, when processing a +PopFrame().
Disabled → ValidAt the choice of the pool.
Disabled → PopframeIllegal.
+

.lw-frame.state-impl: Each AP contains 3 additional fields to hold this state:

+
mps_addr_t frameptr;
+mps_bool_t enabled;
+mps_bool_t lwPopPending;
+
+
+

.lw-frame.enabled: The enabled slot holds the following values for +each state:

+ ++++ + + + + + + + + + + + +
ValidTRUE
PopPendingTRUE
DisabledFALSE
+

.lw-frame.frameptr: The frameptr slot holds the following values +for each state:

+ ++++ + + + + + + + + + + + +
ValidNULL
PopPendingFrame handle for most recently popped frame.
DisabledNULL
+

.lw-frame.lwPopPending: The lwPopPending slot holds the +following values for each state:

+ ++++ + + + + + + + + + + + +
ValidFALSE
PopPendingTRUE
DisabledFALSE
+

.lw-frame.state-for-gc: It is not necessary for the tracer, format +code, pool, or any other part of the GC support in MPS to read either +of the two additional AP fields in order to scan a segment which +supports a lightweight allocation frame.

+ +
+

1.8.3. Synchronization

+

.lw-frame.sync: The purpose of the design is that mutator may +access the state of an AP without locking with MPS (via the external +functions). The design assumes the normal MPS restriction that an +operation on an AP may only be performed by a single mutator thread at +a time. Each of the operations on allocation frames counts as an +operation on an AP.

+

.lw-frame.sync.pool: Pools are permitted to read or modify the +lightweight frame state of an AP only in response to an operation on +that AP.

+

.lw-frame.sync.external: The external functions +mps_ap_frame_push() and mps_ap_frame_pop() are permitted to +read the values of the enabled and frameptr fields for the +supplied AP without claiming the arena lock. They are permitted to +modify the frameptr field if and only if enabled == FALSE.

+

.lw-frame.sync.trip: When a buffer trip happens, and the trap +wasn’t set by MPS itself (that is, it wasn’t because of a flip or for +logging), then the buffer code must check whether the AP has state +PopPending. If it does, the buffer code must call the Pool.

+
+
+

1.8.4. Implementation

+

.lw-frame.push: The external PushFrame() operation +(mps_ap_frame_push()) performs the following operations:

+
IF (!APIsTrapped(ap) && StateOfFrame(ap) == Valid && ap->init == ap->alloc)
+   *frame_o = ap->init;
+ELSE
+  WITH_ARENA_LOCK
+    PerformInternalPushFrameOperation(...)
+  END
+END
+
+
+

.lw-frame.pop: The external PopFrame() operation +(mps_ap_frame_pop()) performs the following operations:

+
IF (StateOfFrame(ap) != Disabled)
+  TrapAP(ap);  /* ensure next allocation or push involves the pool */
+  ap->frameptr = frame;
+  ap->lwpopPending = TRUE;
+ELSE
+  WITH_ARENA_LOCK
+    PerformInternalPopFrameOperation(...)
+  END
+END
+
+
+
+ + + + + + + +
+
+ +

Table Of Contents

+ + +

Previous topic

+

Old design

+

Next topic

+

2. Arena

Downloads

+ +

+MPS Kit release 1.111.0
+All MPS Kit releases +

+ +

Issues

+ +

+Known issues
+Issues fixed in release 1.111.0 +

Contact us

+ +

mps-questions@ravenbrook.com

+
+
+
+ +
+

Navigation

+ +
+
+ © Copyright 2013, Ravenbrook Limited. + Created using Sphinx 1.1.3. +
+ + \ No newline at end of file diff --git a/mps/manual/html/design/arena.html b/mps/manual/html/design/arena.html index 7a9f51f18cb..3ddabd37c0f 100644 --- a/mps/manual/html/design/arena.html +++ b/mps/manual/html/design/arena.html @@ -8,7 +8,7 @@ - 1. Arena — Memory Pool System 1.111.0 documentation + 2. Arena — Memory Pool System 1.111.0 documentation @@ -28,8 +28,8 @@ - - + +
@@ -39,10 +39,10 @@

Navigation

index
  • - next |
  • - previous |
  • Memory Pool System 1.111.0 documentation »
  • Old design »
    • @@ -54,15 +54,15 @@

    Navigation

    -
    -

    1. Arena

    +
    +

    2. Arena

    -

    1.1. Introduction

    +

    2.1. Introduction

    .intro: This is the design of the arena structure.

    .readership: MPS developers.

    -

    1.2. Overview

    +

    2.2. Overview

    .overview: The arena serves two purposes. It is a structure that is the top-level state of the MPS, and as such contains a lot of fields which are considered “global”. And it provides raw memory to pools.

    @@ -75,7 +75,7 @@

    1.2. Overview -

    1.3. Definitions

    +

    2.3. Definitions

    .def.tract: Pools request memory from the arena by calling ArenaAlloc(). This returns a block comprising a contiguous sequence of “tracts”. A tract has a specific size (also known as the “arena @@ -84,16 +84,19 @@

    1.3. Definitions -

    1.4. Requirements

    -

    [copied from design.mps.arena.vm(1) and edited slightly – drj -1999-06-23]

    -

    [Where do these come from? Need to identify and document the sources -of requirements so that they are traceable to client requirements. -Most of these come from the architectural design -(design.mps.architecture) or the fix function design (design.mps.fix). -– richard 1995-08-28]

    +

    2.4. Requirements

    +
    +

    Note

    +

    Where do these come from? Need to identify and document the +sources of requirements so that they are traceable to client +requirements. Most of these come from the architectural design +(design.mps.architecture) or the fix function design +(design.mps.fix). Richard Brooksby, 1995-08-28.

    +

    They were copied from design.mps.arena.vm(1) and edited slightly. +David Jones, 1999-06-23.

    +
    -

    1.4.1. Block management

    +

    2.4.1. Block management

    .req.fun.block.alloc: The arena must provide allocation of contiguous blocks of memory.

    .req.fun.block.free: It must also provide freeing of contiguously @@ -110,12 +113,12 @@

    1.4.1. Block management.req.attr.block.align.min: The alignment of blocks shall not be less than MPS_PF_ALIGN for the architecture. This is so that pool classes can conveniently guarantee pool allocated blocks are aligned -to MPS_PF_ALIGN. (A trivial requirement)

    +to MPS_PF_ALIGN. (A trivial requirement.)

    .req.attr.block.grain.max: The granularity of allocation shall not be more than the grain size provided by the virtual mapping interface.

    -

    1.4.2. Address translation

    +

    2.4.2. Address translation

    .req.fun.trans: The arena must provide a translation from any address to either an indication that the address is not in any tract (if that is so) or the following data associated with the tract @@ -131,12 +134,12 @@

    1.4.2. Address translation

    -

    1.4.3. Iteration protocol

    +

    2.4.3. Iteration protocol

    .req.iter: er, there’s a tract iteration protocol which is presumably required for some reason?

    -

    1.4.4. Arena partition

    +

    2.4.4. Arena partition

    .req.fun.set: The arena must provide a method for approximating sets of addresses.

    .req.fun.set.time: The determination of membership shall take no @@ -144,20 +147,24 @@

    1.4.4. Arena partition -

    1.4.5. Constraints

    +

    2.4.5. Constraints

    .req.attr.space.overhead: req.dylan.attr.space.struct implies that the arena must limit the space overhead. The arena is not the only part that introduces an overhead (pool classes being the next most obvious), so multiple parts must cooperate in order to meet the ultimate requirements.

    -

    .req.attr.time.overhead: Time overhead constraint? [how can there be -a time “overhead” on a necessary component? drj 1999-06-23]

    +

    .req.attr.time.overhead: Time overhead constraint?

    +
    +

    Note

    +

    How can there be a time “overhead” on a necessary component? David +Jones, 1999-06-23.

    +
    -

    1.5. Architecture

    +

    2.5. Architecture

    -

    1.5.1. Statics

    +

    2.5.1. Statics

    .static: There is no higher-level data structure than a arena, so in order to support several arenas, we have to have some static data in impl.c.arena. See impl.c.arena.static.

    @@ -177,7 +184,7 @@

    1.5.1. Statics -

    1.5.2. Arena classes

    +

    2.5.2. Arena classes

    mps_arena_s *Arena
    @@ -215,7 +222,7 @@

    1.5.2. Arena classesNULL.

    -

    1.5.3. Tracts

    +

    2.5.3. Tracts

    .tract: The arena allocation function ArenaAlloc() allocates a block of memory to pools, of a size which is aligned to the arena alignment. Each alignment unit (grain) of allocation is represented by @@ -284,13 +291,13 @@

    1.5.3. TractsTraceFix() (see design.mps.trace.fix.tractofaddr).

    -

    1.5.4. Control pool

    +

    2.5.4. Control pool

    .pool: Each arena has a “control pool”, arena->controlPoolStruct, which is used for allocating MPS control data structures by calling ControlAlloc().

    -

    1.5.5. Polling

    +

    2.5.5. Polling

    .poll: ArenaPoll() is called “often” by other code (for instance, on buffer fill or allocation). It is the entry point for doing tracing work. If the polling clock exceeds a set threshold, and we’re not @@ -300,12 +307,17 @@

    1.5.5. PollingBufferEmpty -is not taken into account, because the splinter will rarely be useable -for allocation and we are wary of the clock running backward.

    +guard against running out of memory.

    +
    +

    Note

    +

    Clearly it really ought to: we have a requirement to not run out +of memory (see req.dylan.prot.fail-alloc, req.dylan.prot.consult), +and emergency tracing should not be our only story. David Jones, +1999-06-22.

    +
    +

    BufferEmpty() is not taken into account, because the splinter will +rarely be useable for allocation and we are wary of the clock running +backward.

    .poll.clamp: Polling is disabled when the arena is “clamped”, in which case arena->clamped is TRUE. Clamping the arena prevents background tracing work, and further new garbage collections from @@ -317,7 +329,7 @@

    1.5.5. PollingArenaPark() method.

    -

    1.5.6. Commit limit

    +

    2.5.6. Commit limit

    .commit-limit: The arena supports a client configurable “commit limit” which is a limit on the total amount of committed memory. The generic arena structure contains a field to hold the value of the @@ -341,7 +353,7 @@

    1.5.6. Commit limit -

    1.5.7. Spare committed (aka “hysteresis”)

    +

    2.5.7. Spare committed (aka “hysteresis”)

    .spare-committed: See mps_arena_spare_committed(). The generic arena structure contains two fields for the spare committed memory fund: spareCommitted records the total number of spare committed @@ -363,7 +375,7 @@

    1.5.7. Spare committed (aka “hysteresis”)spareCommitExceeded is called.

    -

    1.5.8. Locks

    +

    2.5.8. Locks

    .lock.ring: ArenaAccess() is called when we fault on a barrier. The first thing it does is claim the non-recursive global lock to protect the arena ring (see design.mps.lock(0)).

    @@ -385,22 +397,22 @@

    1.5.8. Locks -

    1.5.9. Location dependencies

    +

    2.5.9. Location dependencies

    .ld: Location dependencies use fields in the arena to maintain a history of summaries of moved objects, and to keep a notion of time, so that the staleness of location dependency can be determined.

    -

    1.5.10. Finalization

    +

    2.5.10. Finalization

    .final: There is a pool which is optionally (and dynamically) instantiated to implement finalization. The fields finalPool and isFinalPool are used.

    -

    1.6. Implementation

    +

    2.6. Implementation

    -

    1.6.1. Tract cache

    +

    2.6.1. Tract cache

    .tract.cache: When tracts are allocated to pools by ArenaAlloc(), the first tract of the block and it’s base address are cached in arena fields lastTract and lastTractBase. The function @@ -416,7 +428,7 @@

    1.6.1. Tract cacheNULL.

    -

    1.6.2. Control pool

    +

    2.6.2. Control pool

    .pool.init: The control pool is initialized by a call to PoolInit() during ArenaCreate().

    .pool.ready: All the other fields in the arena are made checkable @@ -427,7 +439,7 @@

    1.6.2. Control poolpoolReady.

    -

    1.6.3. Traces

    +

    2.6.3. Traces

    .trace: arena->trace[ti] is valid if and only if TraceSetIsMember(arena->busyTraces, ti).

    .trace.create: Since the arena created by ArenaCreate() has @@ -437,7 +449,7 @@

    1.6.3. Traces -

    1.6.4. Polling

    +

    2.6.4. Polling

    .poll.fields: There are three fields of a arena used for polling: pollThreshold, insidePoll, and clamped (see above). pollThreshold is the threshold for the next poll: it is set at the @@ -445,7 +457,7 @@

    1.6.4. PollingARENA_POLL_MAX.

    -

    1.6.5. Location dependencies

    +

    2.6.5. Location dependencies

    .ld.epoch: arena->epoch is the “current epoch”. This is the number of ‘flips’ of traces in the arena since the arena was created. From the mutator’s point of view locations change atomically at flip.

    @@ -464,7 +476,7 @@

    1.6.5. Location dependencies -

    1.6.6. Roots

    +

    2.6.6. Roots

    .root-ring: The arena holds a member of a ring of roots in the arena. It holds an incremental serial which is the serial of the next root.

    @@ -483,38 +495,38 @@

    1.6.6. RootsTable Of Contents

      -
    • 1. Arena
        -
      • 1.1. Introduction
        • -
      • 1.2. Overview
        • -
      • 1.3. Definitions
        • -
      • 1.4. Requirements
          -
        • 1.4.1. Block management
          • -
        • 1.4.2. Address translation
          • -
        • 1.4.3. Iteration protocol
          • -
        • 1.4.4. Arena partition
          • -
        • 1.4.5. Constraints
          • +
        • 2. Arena
            +
          • 2.1. Introduction
            • +
          • 2.2. Overview
            • +
          • 2.3. Definitions
            • +
          • 2.4. Requirements
            • -
          • 1.5. Architecture

            Previous topic

            -

            Old design

            +

            1. Allocation frame protocol

            Next topic

            -

            2. Bit tables

            Downloads

            +

            3. Virtual Memory Arena

            Downloads

            MPS Kit release 1.111.0
            @@ -552,10 +564,10 @@

            Navigation

            index
          • - next |
          • - previous |
          • Memory Pool System 1.111.0 documentation »
          • Old design »
            • diff --git a/mps/manual/html/design/arenavm.html b/mps/manual/html/design/arenavm.html new file mode 100644 index 00000000000..9c760fa780e --- /dev/null +++ b/mps/manual/html/design/arenavm.html @@ -0,0 +1,282 @@ + + + + + + + + + + 3. Virtual Memory Arena — Memory Pool System 1.111.0 documentation + + + + + + + + + + + + + + + +
            +

            Navigation

            + +
            + +
            +
            +
            +
            + +
            +

            3. Virtual Memory Arena

            +
            +

            3.1. Introduction

            +

            .intro: This document describes the detailed design of the Virtual +Memory Arena Class of the Memory Pool System. The VM Arena Class is +just one class available in the MPS. The generic arena part is +described in design.mps.arena.

            +
            +
            +

            3.2. Overview

            +

            .overview: VM arenas provide blocks of memory to all other parts of +the MPS in the form of “tracts” using the virtual mapping interface +(design.mps.vm) to the operating system. The VM Arena Class is not +expected to be provided on platforms that do not have virtual memory +(like MacOS, os.s7(1)).

            +

            .overview.gc: The VM Arena Class provides some special services on +these blocks in order to facilitate garbage collection:

            +

            .overview.gc.zone: Allocation of blocks with specific zones. This +means that the generic fix function (design.mps.fix) can use a fast +refset test to eliminate references to addresses that are not in the +condemned set. This assumes that a pool class that uses this placement +appropriately is being used (such as the generation placement policy +used by AMC: see design.mps.poolamc(1)) and that the pool selects the +condemned sets to coincide with zone stripes.

            +

            .overview.gc.tract: A fast translation from addresses to tract. +(See design.mps.arena.req.fun.trans)

            +
            +
            +

            3.3. Notes

            +

            .note.refset: Some of this document simply assumes that RefSets +(see the horribly incomplete design.mps.refset) have been chosen as +the solution for design.mps.arena.req.fun.set. It’s a lot simpler that +way. Both to write and understand.

            +
            +
            +

            3.4. Requirements

            +

            Most of the requirements are in fact on the generic arena (see +design.mps.arena.req). However, many of those requirements can only be +met by a suitable arena class design.

            +

            Requirements particular to this arena class:

            +
            +

            3.4.1. Placement

            +

            .req.fun.place: It must be possible for pools to obtain tracts at +particular addresses. Such addresses shall be declared by the pool +specifying what refset zones the tracts should lie in and what refset +zones the tracts should not lie in. It is acceptable for the arena to +not always honour the request in terms of placement if it has run out +of suitable addresses.

            +
            +
            +

            3.4.2. Arena partition

            +

            .req.fun.set: See design.mps.arena.req.fun.set. The approximation +to sets of address must cooperate with the placement mechanism in the +way required by .req.fun.place (above).

            +
            +
            +
            +

            3.5. Architecture

            +

            .arch.memory: The underlying memory is obtained from whatever +Virtual Memory interface (see design.mps.vm). @@@@ Explain why this is +used.

            +
            +
            +

            3.6. Solution ideas

            +

            .idea.grain: Set the arena granularity to the grain provided by the +virtual mapping module.

            +

            .idea.mem: Get a single large contiguous address area from the +virtual mapping interface and divide that up.

            +

            .idea.table: Maintain a table with one entry per grain in order to +provide fast mapping (shift and add) between addresses and table +entries.

            +

            .idea.table.figure: [missing figure]

            +

            .idea.map: Store the pointers (.req.fun.trans) in the table +directly for every grain.

            +

            .idea.zones: Partition the managed address space into zones (see +idea.zones) and provide the set approximation as a reference +signature.

            +

            .idea.first-fit: Use a simple first-fit allocation policy for +tracts within each zone (.idea.zones). Store the freelist in the +table (.idea.table).

            +

            .idea.base: Store information about each contiguous area (allocated +of free) in the table entry (.idea.table) corresponding to the base +address of the area.

            +

            .idea.shadow: Use the table (.idea.table) as a “shadow” of the +operating system’s page table. Keep information such as last access, +protection, etc. in this table, since we can’t get at this information +otherwise.

            +

            .idea.barrier: Use the table (.idea.table) to implement the +software barrier. Each segment can have a read and/or write barrier +placed on it by each process. (.idea.barrier.bits: Store a +bit-pattern which remembers which process protected what.) This will +give a fast translation from a barrier-protected address to the +barrier handler via the process table.

            +

            .idea.demand-table: For a 1 GiB managed address space with a 4 KiB +page size, the table will have 256K-entries. At, say, four words per +entry, this is 4 MiB of table. Although this is only an 0.4%, the +table shouldn’t be preallocated or initially it is an infinite +overhead, and with 1 MiB active, it is a 300% overhead! The address +space for the table should be reserved, but the pages for it mapped +and unmapped on demand. By storing the table in a tract, the status of +the table’s pages can be determined by looking at it’s own entries in +itself, and thus the translation lookup (.req.fun.trans) is slowed +to two lookups rather than one.

            +

            .idea.pool: Make the Arena Manager a pool class. Arena +initialization becomes pool creation. Tract allocation becomes +PoolAlloc(). Other operations become class-specific operations on +the “arena pool”.

            +
            +
            +

            3.7. Data structures

            +

            .tables: There are two table data structures: a page table, and an +alloc table.

            +

            .table.page.map: Each page in the VM has a corresponding page table +entry.

            +

            .table.page.linear: The table is a linear array of PageStruct +entries; there is a simple mapping between the index in the table and +the base address in the VM. Namely:

            +
              +
            • index to base address: base-address = arena-base + (index * page-size)
              • +
            • base address to index: index = (base-address - arena-base) / page-size
              • +
            +

            .table.page.partial: The table is partially mapped on an +“as-needed” basis. The function unusedTablePages() identifies +entirely unused pages occupied by the page table itself (that is, +those pages of the page table which are occupied by PageStruct +objects which all describe free pages). Tract allocation and freeing +use this function to map and unmap the page table with no hysteresis. +(There is restriction on the parameters you may pass to +unusedTablePages().)

            +

            .table.page.tract: Each page table entry contains a tract, which is +only valid if it is allocated to a pool. If it is not allocated to a +pool, the fields of the tract are used for other purposes. (See +design.mps.arena.tract.field.pool)

            +

            .table.alloc: The alloc table is a simple bit table (implemented +using the BT module, design.mps.bt).

            +

            .table.alloc.map: Each page in the VM has a corresponding alloc +table entry.

            +

            .table.alloc.semantics: The bit in the alloc table is set iff the +corresponding page is allocated (to a pool).

            +
            +
            +

            3.8. Notes

            +

            .fig.page: How the pages in the arena area are represented in the +tables.

            +

            [missing figure]

            +

            .fig.count: How a count table can be used to partially map the page +table, as proposed in request.dylan.170049.sol.map.

            +

            [missing figure]

            +
            +
            + + +
            +
            +
            +
            +
            + +

            Table Of Contents

            + + +

            Previous topic

            +

            2. Arena

            +

            Next topic

            +

            4. Bit tables

            Downloads

            + +

            +MPS Kit release 1.111.0
            +All MPS Kit releases +

            + +

            Issues

            + +

            +Known issues
            +Issues fixed in release 1.111.0 +

            Contact us

            + +

            mps-questions@ravenbrook.com

            +
            +
            +
            +
            +
            +

            Navigation

            + +
            +
            + © Copyright 2013, Ravenbrook Limited. + Created using Sphinx 1.1.3. +
            + + \ No newline at end of file diff --git a/mps/manual/html/design/bt.html b/mps/manual/html/design/bt.html index e76d6fdadc0..aa5722a9bab 100644 --- a/mps/manual/html/design/bt.html +++ b/mps/manual/html/design/bt.html @@ -8,7 +8,7 @@ - 2. Bit tables — Memory Pool System 1.111.0 documentation + 4. Bit tables — Memory Pool System 1.111.0 documentation @@ -28,8 +28,8 @@ - - + +
            @@ -39,10 +39,10 @@

            Navigation

            index
          • - next |
          • - previous |
          • Memory Pool System 1.111.0 documentation »
          • Old design »
            • @@ -54,10 +54,10 @@

            Navigation

            -
            -

            2. Bit tables

            +
            +

            4. Bit tables

            -

            2.1. Introduction

            +

            4.1. Introduction

            .intro: This is the design of the Bit Tables module. A Bit Table is a linear array of bits. A Bit Table of length n is indexed using an integer from 0 up to (but not including) n. Each bit in a Bit Table @@ -69,7 +69,7 @@

            Navigation

            .readership: MPS developers.

            -

            2.2. Definitions

            +

            4.2. Definitions

            .def.set: Set

            Used as a verb meaning to assign the value 1 or TRUE to a bit. @@ -105,7 +105,7 @@

            2.2. Definitions -

            2.3. Requirements

            +

            4.3. Requirements

            .req.bit: The storage for a Bit Table of n bits shall take no more than a small constant addition to the storage required for n bits. ..req.bit.why: This is so that clients can make some predictions @@ -236,7 +236,7 @@

            2.3. Requirements -

            2.4. Non requirements

            +

            4.4. Non requirements

            The following are not requirements but the current design could support them with little modification or does support them. Often they used to be requirements, but are no longer, or were added @@ -255,7 +255,7 @@

            2.4. Non requirements -

            2.5. Background

            +

            4.5. Background

            .background: Originally Bit Tables were used and implemented by PoolClassLO (design.mps.poollo). It was decided to lift them out into a separate module when designing the @@ -266,7 +266,7 @@

            2.5. Background -

            2.6. Clients

            +

            4.6. Clients

            .clients: Bit Tables are used throughout the MPS but the important uses are in the client and VM arenas (design.mps.arena.client(0) and design.mps.arena.vm(1)) a bit table is used to record whether each @@ -275,14 +275,14 @@

            2.6. Clients -

            2.7. Overview

            +

            4.7. Overview

            .over: Mostly, the design is as simple as possible. The significant complications are iteration (see .iteration below) and searching (see .fun.find-res-range below) because both of these are required to be fast.

            -

            2.8. Interface

            +

            4.8. Interface

            Word *BT
            @@ -400,7 +400,7 @@

            2.8. Interface.non-req.ops.test.range.same.

            .if.find.general: There are four functions (below) to find reset ranges. All the functions have the same prototype (for symmetry):

            -
            Bool find(Index *baseReturn, Index *limitReturn,
+
            Bool find(Index *baseReturn, Index *limitReturn,
           BT bt,
           Index searchBase, Index searchLimit,
           Count length);
@@ -490,9 +490,9 @@ 
            2.8. Interfacebase, limit). Meets .req.ops.copy.invert.
            
 
            
 
            
-
            2.9. Detailed design
            
+
            4.9. Detailed design
            
 
            
-
            2.9.1. Data structures
            
+
            4.9.1. Data structures
            
 
            .datastructure: Bit Tables will be represented as (a pointer to) an
 array of Word. A plain array is used instead of the more usual
 design convention of implementing an abstract data type as a structure
@@ -507,7 +507,7 @@ 
            2.9.1. Data structures
-
            2.9.2. Functions
            
+
            4.9.2. Functions
            
 
            .fun.size: BTSize(). Since a Bit Table is an array of Word, the
 size of a Bit Table of n bits is simply the number of words that it
 takes to store n bits times the number of bytes in a word. This is
@@ -706,7 +706,7 @@ 
            2.9.2. Functions
-
            2.10. Testing
            
+
            4.10. Testing
            
 
            .test: The following tests are available or have been used during
 development.
            
 
            .test.btcv: btcv.c. This is supposed to be a coverage test,
@@ -738,31 +738,31 @@ 
            2.10. TestingTable Of Contents
            
   
              
-
            • 2. Bit tables
                
-
              • 2.1. Introduction
                • 
-
              • 2.2. Definitions
                • 
-
              • 2.3. Requirements
                • 
-
              • 2.4. Non requirements
                • 
-
              • 2.5. Background
                • 
-
              • 2.6. Clients
                • 
-
              • 2.7. Overview
                • 
-
              • 2.8. Interface
                • 
-
              • 2.9. Detailed design
 
   
                Previous topic
                
-  
                1. Arena
                
+  
                3. Virtual Memory Arena
                
   
                Next topic
                
-  
                3. Coalescing block structure
                Downloads
                
+  
                5. Allocation buffers and allocation points
                Downloads
                
 
 
                
 MPS Kit release 1.111.0
                
@@ -788,10 +788,10 @@ 
                Navigation
                
           index
                • 
         
              • 
-          next |
                • 
         
              • 
-          previous |
                • 
         
              • Memory Pool System 1.111.0 documentation »
                • 
           
              • Old design »
                •  
diff --git a/mps/manual/html/design/buffer.html b/mps/manual/html/design/buffer.html
new file mode 100644
index 00000000000..541e2d46226
--- /dev/null
+++ b/mps/manual/html/design/buffer.html
@@ -0,0 +1,795 @@
+
+
+
+
+
+
+  
+    
+    
+    5. Allocation buffers and allocation points — Memory Pool System 1.111.0 documentation
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+     
+  
+  
+    
                
+      
                Navigation
                
+      
+    
                  
+
+    
                
+      
                
+        
                
+          
                
+            
+  
                
+
                5. Allocation buffers and allocation points
                
+
                
+
                5.1. Introduction
                
+
                .scope: This document describes the design of allocation buffers
+and allocation points.
                
+
                .purpose: The purpose of this document is to record design
+decisions made concerning allocation buffers and allocation points and
+justify those decisions in terms of requirements.
                
+
                .readership: The document is intended for reading by any MPS
+developer.
                
+
                
+
                
+
                5.2. Glossary
                
+
                trapped
                
+
                
+
                .def.trapped: The buffer is in a state such that the MPS gets
+to know about the next use of that buffer.
                
+
                
+
                
+
                5.3. Source
                
+
                .source.mail: Much of the juicy stuff about buffers is only
+floating around in mail discussions. You might like to try searching
+the archives if you can’t find what you want here.
                
+
                
+
                Note
                
+
                Mail archives are only accessible to Ravenbrook staff. RHSK
+2006-06-09.
                
+
                
+
                .source.synchronize: For a discussion of the synchronization
+issues:
                
+
+
                
+
                Note
                
+
                I believe that the sequence for flip in PTW’s message is
+incorrect. The operations should be in the other order. DRJ.
                
+
                
+
                .source.interface: For a description of the buffer interface in C
+prototypes:
                
+
+
                .source.qa: Discussions with QA were useful in pinning down the
+semantics and understanding of some obscure but important boundary
+cases. See the thread starting
+mail.richard.tucker.1997-05-12.09-45(0) with subject “notes on
+our allocation points discussion”:
                
+
+
                
+
                
+
                5.4. Requirements
                
+
                .req.fast: Allocation must be very fast.
                
+
                .req.thread-safe: Must run safely in a multi-threaded environment.
                
+
                .req.no-synch: Must avoid the use of thread-synchronization.
+(.req.fast)
                
+
                .req.manual: Support manual memory management.
                
+
                .req.exact: Support exact collectors.
                
+
                .req.ambig: Support ambiguous collectors.
                
+
                .req.count: Must record (approximately) the amount of allocation (in bytes).
                
+
                
+
                Note
                
+
                Actually not a requirement any more, but once was put forward as a
+Dylan requirement. Bits of the code still reflect this
+requirement. See request.dylan.170554.
                
+
                
+
                
+
                
+
                5.5. Classes
                
+
                .class.hierarchy: The Buffer data structure is designed to be
+subclassable (see design.mps.protocol).
                
+
                .class.hierarchy.buffer: The basic buffer class (BufferClass)
+supports basic allocation-point buffering, and is appropriate for
+those manual pools which don’t use segments (.req.manual). The
+Buffer class doesn’t support reference ranks (that is, the buffers
+have RankSetEMPTY). Clients may use BufferClass directly, or
+create their own subclasses (see .subclassing).
                
+
                .class.hierarchy.segbuf: Class SegBufClass is also provided for
+the use of pools which additionally need to associate buffers with
+segments. SegBufClass is a subclass of BufferClass. Manual
+pools may find it convenient to use SegBufClass, but it is
+primarily intended for automatic pools (.req.exact, .req.ambig).
+An instance of SegBufClass may be attached to a region of memory
+that lies within a single segment. The segment is associated with the
+buffer, and may be accessed with the BufferSeg() function.
+SegBufClass also supports references at any rank set. Hence this
+class or one of its subclasses should be used by all automatic pools
+(with the possible exception of leaf pools). The rank sets of buffers
+and the segments they are attached to must match. Clients may use
+SegBufClass directly, or create their own subclasses (see
+.subclassing).
                
+
                .class.hierarchy.rankbuf: Class RankBufClass is also provided
+as a subclass of SegBufClass. The only way in which this differs
+from its superclass is that the rankset of a RankBufClass is set
+during initialization to the singleton rank passed as an additional
+parameter to BufferCreate(). Instances of RankBufClass are of
+the same type as instances of SegBufClass, that is, SegBuf.
+Clients may use RankBufClass directly, or create their own
+subclasses (see .subclassing).
                
+
                .class.create: The buffer creation functions (BufferCreate()
+and BufferCreateV()) take a class parameter, which determines
+the class of buffer to be created.
                
+
                .class.choice: Pools which support buffered allocation should
+specify a default class for buffers. This class will be used when a
+buffer is created in the normal fashion by MPS clients (for example by
+a call to mps_ap_create()). Pools specify the default class by
+means of the bufferClass field in the pool class object. This
+should be a pointer to a function of type PoolBufferClassMethod.
+The normal class “Ensure” function (for example
+EnsureBufferClass()) has the appropriate type.
                
+
                .subclassing: Pools may create their own subclasses of the standard
+buffer classes. This is sometimes useful if the pool needs to add an
+extra field to the buffer. The convenience macro
+DEFINE_BUFFER_CLASS() may be used to define subclasses of buffer
+classes. See design.mps.protocol.int.define-special.
                
+
                .replay: To work with the allocation replayer (see
+design.mps.telemetry.replayer), the buffer class has to emit an event
+for each call to an external interface, containing all the parameters
+passed by the user. If a new event type is required to carry this
+information, the replayer (impl.c.eventrep) must then be extended to
+recreate the call.
                
+
                .replay.pool-buffer: The replayer must also be updated if the
+association of buffer class to pool or the buffer class hierarchy is
+changed.
                
+
                .class.method: Buffer classes provide the following methods (these
+should not be confused with the pool class methods related to the
+buffer protocol, described in .method):
                
+
                
+
                
+Res (*BufferInitMethod)(Buffer buffer, Pool pool, ArgList args)
                
+
                
+
+
                .class.method.init: init() is a class-specific initialization
+method called from BufferInit(). It receives the keyword arguments
+passed to to BufferInit(). Client-defined methods must call their
+superclass method (via a next-method call) before performing any
+class-specific behaviour. .replay.init: The init() method
+should emit a BufferInit<foo> event (if there aren’t any extra
+parameters, <foo> = "").
                
+
                
+
                
+void (*BufferFinishMethod)(Buffer buffer)
                
+
                
+
+
                .class.method.finish: finish() is a class-specific finish
+method called from BufferFinish(). Client-defined methods must
+call their superclass method (via a next-method call) after performing
+any class-specific behaviour.
                
+
                
+
                
+void (*BufferAttachMethod)(Buffer buffer, Addr base, Addr limit, Addr init, Size size)
                
+
                
+
+
                .class.method.attach: attach() is a class-specific method
+called whenever a buffer is attached to memory, via
+BufferAttach(). Client-defined methods must call their superclass
+method (via a next-method call) before performing any class-specific
+behaviour.
                
+
                
+
                
+void (*BufferDetachMethod)(Buffer buffer)
                
+
                
+
+
                .class.method.detach: detach() is a class-specific method
+called whenever a buffer is detached from memory, via
+BufferDetach(). Client-defined methods must call their superclass
+method (via a next-method call) after performing any class-specific
+behaviour.
                
+
                
+
                
+Seg (*BufferSegMethod)(Buffer buffer)
                
+
                
+
+
                .class.method.seg: seg() is a class-specific accessor method
+which returns the segment attached to a buffer (or NULL if there
+isn’t one). It is called from BufferSeg(). Clients should not need
+to define their own methods for this.
                
+
                
+
                
+RankSet (*BufferRankSetMethod)(Buffer buffer)
                
+
                
+
+
                .class.method.rankSet: rankSet() is a class-specific accessor
+method which returns the rank set of a buffer. It is called from
+BufferRankSet(). Clients should not need to define their own
+methods for this.
                
+
                
+
                
+void (*BufferSetRankSetMethod)(Buffer buffer, RankSet rankSet)
                
+
                
+
+
                .class.method.setRankSet: setRankSet() is a class-specific
+setter method which sets the rank set of a buffer. It is called from
+BufferSetRankSet(). Clients should not need to define their own
+methods for this.
                
+
                
+
                
+Res (*BufferDescribeMethod)(Buffer buffer, mps_lib_FILE *stream)
                
+
                
+
+
                .class.method.describe: describe() is a class-specific method
+called to describe a buffer, via BufferDescribe. Client-defined
+methods must call their superclass method (via a next-method call)
+before describing any class-specific state.
                
+
                
+
                
+
                5.6. Logging
                
+
                .logging.control: Buffers have a separate control for whether they
+are logged or not, this is because they are particularly high volume.
+This is a Boolean flag (bufferLogging) in the ArenaStruct.
                
+
                
+
                
+
                5.7. Measurement
                
+
                .count: Counting the allocation volume is done by maintaining two
+fields in the buffer struct:
                
+
                .count.fields: fillSize, emptySize.
                
+
                .count.monotonic: both of these fields are monotonically
+increasing.
                
+
                .count.fillsize: fillSize is an accumulated total of the size
+of all the fills (as a result of calling the PoolClass
+BufferFill() method) that happen on the buffer.
                
+
                .count.emptysize: emptySize is an accumulated total of the size of
+all the empties than happen on the buffer (which are notified to the
+pool using the PoolClass BufferEmpty() method).
                
+
                .count.generic: These fields are maintained by the generic buffer
+code in BufferAttach() and BufferDetach().
                
+
                .count.other: Similar count fields are maintained in the pool and
+the arena. They are maintained on an internal (buffers used internally
+by the MPS) and external (buffers used for mutator allocation points)
+basis. The fields are also updated by the buffer code. The fields are:
                
+
                  
+
                • in the pool: fillMutatorSize, fillInternalSize,
+emptyMutatorSize, and emptyInternalSize (4 fields);
                  • 
+
                • in the arena, fillMutatorSize, fillInternalSize,
+emptyMutatorSize, emptyInternalSize, and
+allocMutatorSize (5 fields).
                  • 
+
                
+
                .count.alloc.how: The amount of allocation in the buffer just
+after an empty is fillSize - emptySize. At other times this
+computation will include space that the buffer has the use of (between
+base and init) but which may not get allocated in (because the
+remaining space may be too large for the next reserve so some or all
+of it may get emptied). The arena field allocMutatorSize is
+incremented by the allocated size (between base and init)
+whenever a buffer is detached. Symmetrically this field is decremented
+by by the pre-allocated size (between base and init) whenever
+a buffer is attached. The overall count is asymptotically correct.
                
+
                .count.type: All the count fields are type double.
                
+
                .count.type.justify: This is because double is the type most likely
+to give us enough precision. Because of the lack of genuine
+requirements the type isn’t so important. It’s nice to have it more
+precise than long. Which double usually is.
                
+
                
+
                
+
                5.8. Notes from the whiteboard
                
+
                Requirements
                
+
                  
+
                • atomic update of words
                  • 
+
                • guarantee order of reads and write to certain memory locations.
                  • 
+
                
+
                Flip
                
+
                  
+
                • limit:=0
                  • 
+
                • record init for scanner
                  • 
+
                
+
                Commit
                
+
                  
+
                • init:=alloc
                  • 
+
                • if(limit = 0) ...
                  • 
+
                • L written only by MM
                  • 
+
                • A written only by client (except during synchronized MM op)
                  • 
+
                • I ditto
                  • 
+
                • I read by MM during flip
                  • 
+
                
+
                States
                
+
                  
+
                • busy
                  • 
+
                • ready
                  • 
+
                • trapped
                  • 
+
                • reset
                  • 
+
                
+
                
+
                Note
                
+
                There are many more states. DRJ.
                
+
                
+
                Misc
                
+
                  
+
                • During buffer ops all field values can change. Might trash perfectly
+good (“valid”?) object if pool isn’t careful.
                  • 
+
                
+
                
+
                
+
                5.9. Synchronization
                
+
                Buffers provide a loose form of synchronization between the mutator
+and the collector.
                
+
                The crucial synchronization issues are between the operation the pool
+performs on flip and the mutator’s commit operation.
                
+
                Commit
                
+
                  
+
                • read init
                  • 
+
                • write init
                  • 
+
                • Memory Barrier
                  • 
+
                • read limit
                  • 
+
                
+
                Flip
                
+
                  
+
                • write limit
                  • 
+
                • Memory Barrier
                  • 
+
                • read init
                  • 
+
                
+
                Commit consists of two parts. The first is the update to init.
+This is a declaration that the new object just before init is now
+correctly formatted and can be scanned. The second is a check to see
+if the buffer has been “tripped”. The ordering of the two parts is
+crucial.
                
+
                Note that the declaration that the object is correctly formatted is
+independent of whether the buffer has been tripped or not. In
+particular a pool can scan up to the init pointer (including the newly
+declared object) whether or not the pool will cause the commit to
+fail. In the case where the pool scans the object, but then causes the
+commit to fail (and presumably the allocation to occur somewhere
+else), the pool will have scanned a “dead” object, but this is just
+another example of conservatism in the general sense.
                
+
                Not that the read of init in the Flip sequence can in fact be
+arbitrarily delayed (as long as it is read before a buffered segment
+is scanned).
                
+
                On processors with Relaxed Memory Order (such as the DEC Alpha),
+Memory Barriers will need to be placed at the points indicated.
                
+
                * DESIGN
+*
+* design.mps.buffer.
+*
+* An allocation buffer is an interface to a pool which provides
+* very fast allocation, and defers the need for synchronization in
+* a multi-threaded environment.
+*
+* Pools which contain formatted objects must be synchronized so
+* that the pool can know when an object is valid.  Allocation from
+* such pools is done in two stages: reserve and commit.  The client
+* first reserves memory, then initializes it, then commits.
+* Committing the memory declares that it contains a valid formatted
+* object.  Under certain conditions, some pools may cause the
+* commit operation to fail.  (See the documentation for the pool.)
+* Failure to commit indicates that the whole allocation failed and
+* must be restarted.  When using a pool which introduces the
+* possibility of commit failing, the allocation sequence could look
+* something like this:
+*
+* do {
+*   res = BufferReserve(&p, buffer, size);
+*   if(res != ResOK) return res;       // allocation fails, reason res
+*   initialize(p);                     // p now points at valid object
+* } while(!BufferCommit(buffer, p, size));
+*
+* Pools which do not contain formatted objects can use a one-step
+* allocation as usual.  Effectively any random rubbish counts as a
+* "valid object" to such pools.
+*
+* An allocation buffer is an area of memory which is pre-allocated
+* from a pool, plus a buffer descriptor, which contains, inter
+* alia, four pointers: base, init, alloc, and limit.  Base points
+* to the base address of the area, limit to the last address plus
+* one.  Init points to the first uninitialized address in the
+* buffer, and alloc points to the first unallocated address.
+*
+*    L . - - - - - .         ^
+*      |           |     Higher addresses -'
+*      |   junk    |
+*      |           |       the "busy" state, after Reserve
+*    A |-----------|
+*      |  uninit   |
+*    I |-----------|
+*      |   init    |
+*      |           |     Lower addresses  -.
+*    B `-----------'         v
+*
+*    L . - - - - - .         ^
+*      |           |     Higher addresses -'
+*      |   junk    |
+*      |           |       the "ready" state, after Commit
+*  A=I |-----------|
+*      |           |
+*      |           |
+*      |   init    |
+*      |           |     Lower addresses  -.
+*    B `-----------'         v
+*
+* Access to these pointers is restricted in order to allow
+* synchronization between the pool and the client.  The client may
+* only write to init and alloc, but in a restricted and atomic way
+* detailed below.  The pool may read the contents of the buffer
+* descriptor at _any_ time.  During calls to the fill and trip
+* methods, the pool may update any or all of the fields
+* in the buffer descriptor.  The pool may update the limit at _any_
+* time.
+*
+* Access to buffers by these methods is not synchronized.  If a buffer
+* is to be used by more than one thread then it is the client's
+* responsibility to ensure exclusive access.  It is recommended that
+* a buffer be used by only a single thread.
+*
+* [Only one thread may use a buffer at once, unless the client
+* places a mutual exclusion around the buffer access in the usual
+* way.  In such cases it is usually better to create one buffer for
+* each thread.]
+*
+* Here are pseudo-code descriptions of the reserve and commit
+* operations.  These may be implemented in-line by the client.
+* Note that the client is responsible for ensuring that the size
+* (and therefore the alloc and init pointers) are aligned according
+* to the buffer's alignment.
+*
+* Reserve(buf, size)                   ; size must be aligned to pool
+*   if buf->limit - buf->alloc >= size then
+*     buf->alloc +=size                ; must be atomic update
+*     p = buf->init
+*   else
+*     res = BufferFill(&p, buf, size)  ; buf contents may change
+*
+* Commit(buf, p, size)
+*   buf->init = buf->alloc             ; must be atomic update
+*   if buf->limit == 0 then
+*     res = BufferTrip(buf, p, size)   ; buf contents may change
+*   else
+*     res = True
+* (returns True on successful commit)
+*
+* The pool must allocate the buffer descriptor and initialize it by
+* calling BufferInit.  The descriptor this creates will fall
+* through to the fill method on the first allocation.  In general,
+* pools should not assign resources to the buffer until the first
+* allocation, since the buffer may never be used.
+*
+* The pool may update the base, init, alloc, and limit fields when
+* the fallback methods are called.  In addition, the pool may set
+* the limit to zero at any time.  The effect of this is either:
+*
+*   1. cause the _next_ allocation in the buffer to fall through to
+*      the buffer fill method, and allow the buffer to be flushed
+*      and relocated;
+*
+*   2. cause the buffer trip method to be called if the client was
+*      between reserve and commit.
+*
+* A buffer may not be relocated under other circumstances because
+* there is a race between updating the descriptor and the client
+* allocation sequence.
                
+
                
+
                
+
                
+
                5.10. Interface
                
+
                
+
                
+Res BufferCreate(Buffer *bufferReturn, BufferClass class, Pool pool, Bool isMutator, ArgList args)
                
+
                
+
+
                .method.create: Create an allocation buffer in a pool. The buffer
+is created in the “ready” state.
                
+
                A buffer structure is allocated from the space control pool and
+partially initialized (in particularly neither the signature nor the
+serial field are initialized). The pool class’s bufferCreate()
+method is then called. This method can update (some undefined subset
+of) the fields of the structure; it should return with the buffer in
+the “ready” state (or fail). The remainder of the initialization then
+occurs.
                
+
                If and only if successful then a valid buffer is returned.
                
+
                
+
                
+void BufferDestroy(Buffer buffer)
                
+
                
+
+
                .method.destroy: Free a buffer descriptor. The buffer must be in
+the “ready” state, that is, not between a Reserve and Commit.
+Allocation in the area of memory to which the descriptor refers must
+cease after BufferDestroy() is called.
                
+
                Destroying an allocation buffer does not affect objects which have
+been allocated, it just frees resources associated with the buffer
+itself.
                
+
                The pool class’s bufferDestroy() method is called and then the
+buffer structure is uninitialized and freed.
                
+
                
+
                
+BufferCheck(Buffer buffer)
                
+
                
+
+
                .method.check: The check method is straightforward, the non-trivial dependencies checked are:
                
+
                  
+
                • The ordering constraints between base, init, alloc, and limit.
                  • 
+
                • The alignment constraints on base, init, alloc, and limit.
                  • 
+
                • That the buffer’s rank is identical to the segment’s rank.
                  • 
+
                
+
                
+
                
+void BufferAttach(Buffer buffer, Addr base, Addr limit, Addr init, Size size)
                
+
                
+
+
                .method.attach: Set the base, init, alloc, and limit fields so that
+the buffer is ready to start allocating in area of memory. The alloc
+field is set to init + size.
                
+
                .method.attach.unbusy: BufferAttach() must only be applied to
+buffers that are not busy.
                
+
                
+
                
+void BufferDetach(Buffer buffer, Pool pool)
                
+
                
+
+
                .method.detach: Set the seg, base, init, alloc, and limit fields to
+zero, so that the next reserve request will call the fill method.
                
+
                .method.detach.unbusy: BufferDetach() must only be applied to
+buffers that are not busy.
                
+
                
+
                
+Bool BufferIsReset(Buffer buffer)
                
+
                
+
+
                .method.isreset: Returns TRUE if and only if the buffer is in the
+reset state, that is, with base, init, alloc, and limit all set to
+zero.
                
+
                
+
                
+Bool BufferIsReady(Buffer buffer)
                
+
                
+
+
                .method.isready: Returns TRUE if and only if the buffer is not
+between a reserve and commit. The result is only reliable if the
+client is not currently using the buffer, since it may update the
+alloc and init pointers asynchronously.
                
+
                
+
                
+mps_ap_t (BufferAP)(Buffer buffer)
                
+
                
+
+
                Returns the APStruct substructure of a buffer.
                
+
                
+
                
+Buffer BufferOfAP(mps_ap_t ap)
                
+
                
+
+
                .method.ofap: Return the buffer which owns an APStruct.
                
+
                .method.ofap.thread-safe: BufferOfAP() must be thread safe (see
+impl.c.mpsi.thread-safety). This is achieved simply because the
+underlying operation involved is simply a subtraction.
                
+
                
+
                
+Arena BufferArena(Buffer buffer)
                
+
                
+
+
                .method.arena: Returns the arena which owns a buffer.
                
+
                .method.arena.thread-safe: BufferArena() must be thread safe
+(see impl.c.mpsi.thread-safety). This is achieved simple because the
+underlying operation is a read of shared-non-mutable data (see
+design.mps.thread-safety).
                
+
                
+
                
+Pool BufferPool(Buffer buffer)
                
+
                
+
+
                Returns the pool to which a buffer is attached.
                
+
                
+
                
+Res BufferReserve(Addr *pReturn, Buffer buffer, Size size, Bool withReservoirPermit)
                
+
                
+
+
                .method.reserve: Reserves memory from an allocation buffer.
                
+
                This is a provided version of the reserve procedure described above.
+The size must be aligned according to the buffer alignment. If
+successful, ResOK is returned and *pReturn is updated with a
+pointer to the reserved memory. Otherwise *pReturn is not touched.
+The reserved memory is not guaranteed to have any particular contents.
+The memory must be initialized with a valid object (according to the
+pool to which the buffer belongs) and then passed to the
+BufferCommit() method (see below). BufferReserve(0 may not be
+applied twice to a buffer without a BufferCommit() in-between. In
+other words, Reserve/Commit pairs do not nest.
                
+
                
+
                
+Res BufferFill(Addr *pReturn, Buffer buffer, Size size, Bool withReservoirPermit)
                
+
                
+
+
                .method.fill: Refills an empty buffer. If there is not enough space
+in a buffer to allocate in-line, BufferFill() must be called to
+“refill” the buffer.
                
+
                
+
                
+Bool BufferCommit(Buffer buffer, Addr p, Size size)
                
+
                
+
+
                .method.commit: Commit memory previously reserved.
                
+
                BufferCommit() notifies the pool that memory which has been
+previously reserved (see above) has been initialized with a valid
+object (according to the pool to which the buffer belongs). The
+pointer p must be the same as that returned by
+BufferReserve(), and the size must match the size passed to
+BufferReserve().
                
+
                BufferCommit() may not be applied twice to a buffer without a
+reserve in between. In other words, objects must be reserved,
+initialized, then committed only once.
                
+
                Commit returns TRUE if successful, FALSE otherwise. If commit
+fails and returns FALSE, the client may try to allocate again by
+going back to the reserve stage, and may not use the memory at p
+again for any purpose.
                
+
                Some classes of pool may cause commit to fail under rare
+circumstances.
                
+
                
+
                
+BufferTrip(Buffer buffer, Addr p, Size size)
                
+
                
+
+
                .method.trip: Act on a tripped buffer. The pool which owns a buffer
+may asynchronously set the buffer limit to zero in order to get
+control over the buffer. If this occurs after a BufferReserve()
+(but before the corresponding commit), then the BufferCommit()
+method calls BufferTrip() and the BufferCommit() method
+returns with the return value of BufferTrip().
                
+
                .method.trip.precondition: At the time trip is called, from
+BufferCommit(), the following are true:
                
+
+
                
+
                
+
                5.11. Diagrams
                
+
                Here are a number of diagrams showing how buffers behave. In general,
+the horizontal axis corresponds to mutator action (reserve, commit)
+and the vertical axis corresponds to collector action. I’m not sure
+which of the diagrams are the same as each other, and which are best
+or most complete when they are different, but they all attempt to show
+essentially the same information. It’s very difficult to get all the
+details in. These diagrams were drawn by Richard Brooksby, Richard
+Tucker, Gavin Matthews, and others in April 1997. In general, the
+later diagrams are, I suspect, more correct, complete and useful than
+the earlier ones. I have put them all here for the record. Richard
+Tucker, 1998-02-09.
                
+
                Buffer Diagram:
+Buffer States
                
+
                Buffer States (3-column)
+Buffer States (4-column)
+Buffer States (gavinised)
+Buffer States (interleaved)
+Buffer States (richardized)
                
+
                [missing diagrams]
                
+
                
+
                
+
+
+          
                
+        
                
+      
                
+      
                
+        
                
+            
+  
                Table Of Contents
                
+  
+
+  
                Previous topic
                
+  
                4. Bit tables
                
+  
                Next topic
                
+  
                6. Checking
                Downloads
                
+
+
                
+MPS Kit release 1.111.0
                
+All MPS Kit releases
+
                
+
+
                Issues
                
+
+
                
+Known issues
                
+Issues fixed in release 1.111.0
+
                Contact us
                
+
+
                mps-questions@ravenbrook.com
                
+        
                
+      
                
+      
                
+    
                
+    
                
+      
                Navigation
                
+      
+    
                
+    
                
+        © Copyright 2013, Ravenbrook Limited.
+      Created using Sphinx 1.1.3.
+    
                
+  
+
\ No newline at end of file
diff --git a/mps/manual/html/design/cbs.html b/mps/manual/html/design/cbs.html
deleted file mode 100644
index 98d896ab52e..00000000000
--- a/mps/manual/html/design/cbs.html
+++ /dev/null
@@ -1,777 +0,0 @@
-
-
-
-
-
-
-  
-    
-    
-    3. Coalescing block structure — Memory Pool System 1.111.0 documentation
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-     
-  
-  
-    
                
-      
                Navigation
                
-      
-    
                  
-
-    
                
-      
                
-        
                
-          
                
-            
-  
                
-
                3. Coalescing block structure
                
-
                
-
                3.1. Introduction
                
-
                .intro: This is the design for impl.c.cbs, which
-implements a data structure for the management of non-intersecting
-memory ranges, with eager coalescence.
                
-
                .readership: This document is intended for any MM developer.
                
-
                .source: design.mps.poolmv2, design.mps.poolmvff.
                
-
                .overview: The “coalescing block structure” is a set of
-addresses (or a subset of address space), with provision for efficient
-management of contiguous ranges, including insertion and deletion,
-high level communication with the client about the size of contiguous
-ranges, and detection of protocol violations.
                
-
                
-
                
-
                3.2. History
                
-
                .hist.0: This document was derived from the outline in
-design.mps.poolmv2(2). Written by Gavin Matthews
-1998-05-01.
                
-
                .hist.1: Updated by Gavin Matthews 1998-07-22 in response to
-approval comments in change.epcore.anchovy.160040 There is
-too much fragmentation in trapping memory.
                
-
                .hist.2: Updated by Gavin Matthews (as part of
-change.epcore.brisling.160158: MVFF cannot be instantiated
-with 4-byte alignment) to document new alignment restrictions.
                
-
                .hist.3: Converted from MMInfo database design document.
-Richard Brooksby, 2002-06-07.
                
-
                .hist.4: Converted to reStructuredText. Gareth Rees,
-2013-04-14.
                
-
                
-
                
-
                3.3. 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.
                
-
                .def.interesting: A block is interesting if it is of at least
-the minimum interesting size specified by the client.
                
-
                
-
                
-
                3.4. Requirements
                
-
                .req.set: Must maintain a set of addresses.
                
-
                .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.
                
-
                
-
                
-
                3.5. Interface
                
-
                .header: CBS is used through impl.h.cbs.
                
-
                
-
                3.5.1. External types
                
-
                
-
                
-typedef struct CBSStruct CBSStruct, *CBS;
                
-
                
-
-
                .type.cbs: CBS is the main datastructure 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 struct CBSBlockStruct CBSBlockStruct, *CBSBlock;
                
-
                
-
-
                .type.cbs.block: CBSBlock is the data-structure
-that represents an isolated contiguous range held by the CBS. It is
-returned by the new and delete methods described below.
                
-
                .type.cbs.method: The following methods are provided as
-callbacks to advise the client of certain events. The implementation
-of these functions should not cause any CBS function to be called on
-the same CBS. In this respect, the CBS module is not re-entrant.
                
-
                
-
                
-typedef void (*CBSChangeSizeMethod)(CBS cbs, CBSBlock block, Size oldSize, SizeNewSize);
                
-
                
-
-
                .type.cbs.change.size.method: CBSChangeSizeMethod
-is the function pointer type, four instances of which are optionally
-registered via CBSInit.
                
-
                These callbacks are invoked under CBSInsert(),
-CBSDelete(), or CBSSetMinSize() in certain
-circumstances. Unless otherwise stated, oldSize and newSize
-will both be non-zero, and different. The accessors
-CBSBlockBase(), CBSBlockLimit(), and
-CBSBlockSize() may be called from within these callbacks,
-except within the delete callback when newSize is zero. See
-.impl.callback for implementation details.
                
-
                
-
                
-typedef Bool (*CBSIterateMethod)(CBS cbs, CBSBlock block, void *closureP, unsigned long closureS);
                
-
                
-
-
                .type.cbs.iterate.method: CBSIterateMethod is a
-function pointer type for a client method invoked by the CBS module
-for every isolated contiguous range in address order, when passed to
-the CBSIterate() or CBSIterateLarge() functions. The
-function returns a boolean indicating whether to continue with the
-iteration.
                
-
                
-
                
-
                3.5.2. External functions
                
-
                
-
                
-Res CBSInit(Arena arena, CBS cbs, CBSChangeSizeMethod new, CBSChangeSizeMethod delete, CBSChangeSizeMethod grow, CBSChangeSizeMethod shrink, Size minSize, Align alignment, Bool mayUseInline)
                
-
                
-
-
                .function.cbs.init: CBSInit() is the function that
-initialises the CBS structure. It performs allocation in the supplied
-arena. Four methods are passed in as function pointers (see
-.type.* above), any of which may be NULL. It receives a
-minimum size, which is used when determining whether to call the
-optional methods. The mayUseInline Boolean indicates whether the
-CBS may use the memory in the ranges as a low-memory fallback (see
-.impl.low-mem). The alignment indicates the alignment of
-ranges to be maintained. An initialised CBS contains no ranges.
                
-
                .function.cbs.init.may-use-inline: If mayUseInline is
-set, then alignment must be at least sizeof(void *). In this
-mode, the CBS will never fail to insert or delete ranges, even if
-memory for control structures becomes short. Note that, in such cases,
-the CBS may defer notification of new/grow events, but will report
-available blocks in CBSFindFirst() and CBSFindLast().
-Such low memory conditions will be rare and transitory. See
-.align for more details.
                
-
                
-
                
-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(CBS cbs, Addr base, Addr limit)
                
-
                
-
-
                .function.cbs.insert: CBSInsert() is the function
-used to add a contiguous range specified by [base,limit) to the
-CBS. If any part of the range is already in the CBS, then
-ResFAIL is returned, and the CBS is unchanged. This
-function may cause allocation; if this allocation fails, and any
-contingency mechanism fails, then ResMEMORY is returned,
-and the CBS is unchanged.
                
-
                .function.cbs.insert.callback: CBSInsert() will invoke callbacks as follows:
                
-
                  
-
                • new: when a new block is created that is interesting. oldSize == 0; newSize >= minSize.
                  • 
-
                • new: when an uninteresting block coalesces to become interesting. 0 < oldSize < minSize <= newSize.
                  • 
-
                • delete: when two interesting blocks are coalesced.  grow will also be invoked in this case on the larger of the two blocks.  newSize == 0; oldSize >= minSize.
                  • 
-
                • grow: when an interesting block grows in size.  minSize <= oldSize < newSize.
                  • 
-
                
-
                
-
                
-Res CBSDelete(CBS cbs, Addr base, Addr limit)
                
-
                
-
-
                .function.cbs.delete: CBSDelete() is the function
-used to remove a contiguous range specified by [base,limit) from
-the CBS. If any part of the range is not in the CBS, then
-ResFAIL is returned, and the CBS is unchanged. This
-function may cause allocation; if this allocation fails, and any
-contingency mechanism fails, then ResMEMORY is returned,
-and the CBS is unchanged.
                
-
                .function.cbs.delete.callback: CBSDelete() will
-invoke callbacks as follows:
                
-
                  
-
                • delete: when an interesting block is entirely removed.  newSize == 0; oldSize >= minSize.
                  • 
-
                • delete: when an interesting block becomes uninteresting. 0 < newSize < minSize <= oldSize.
                  • 
-
                • new: when a block is split into two blocks, both of which are interesting. shrink will also be invoked in this case on the larger of the two blocks. oldSize == 0; newSize >= minSize.
                  • 
-
                • shrink: when an interesting block shrinks in size, but remains interesting. minSize <= newSize < oldSize.
                  • 
-
                
-
                
-
                
-void CBSIterate(CBS cbs, CBSIterateMethod iterate, void *closureP, unsigned long closureS)
                
-
                
-
-
                .function.cbs.iterate: CBSIterate() is the function
-used to iterate all isolated contiguous ranges in a CBS. It receives a
-pointer, unsigned long 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.
                
-
                
-
                
-void CBSIterateLarge(CBS cbs, CBSIterateMethod iterate, void *closureP, unsigned long closureS)
                
-
                
-
-
                .function.cbs.iterate.large: CBSIterateLarge() is the
-function used to iterate all isolated contiguous ranges of size
-greater than or equal to the client indicated minimum size in a CBS.
-It receives a pointer, unsigned long closure pair to pass on to the
-iterator method, and an iterator method to invoke on every large range
-in address order. If the iterator method returns FALSE, then the
-iteration is terminated.
                
-
                
-
                
-void CBSSetMinSize(CBS cbs, Size minSize)
                
-
                
-
-
                .function.cbs.set.min-size: CBSSetMinSize() is the
-function used to change the minimum size of interest in a CBS. This
-minimum size is used to determine whether to invoke the client
-callbacks from CBSInsert() and CBSDelete(). This
-function will invoke either the new or delete callback for all
-blocks that are (in the semi-open interval) between the old and new
-values. oldSize and newSize will be the same in these cases.
                
-
                
-
                
-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.
                
-
                
-
                
-Addr CBSBlockBase(CBSBlock block)
                
-
                
-
-
                .function.cbs.block.base: The CBSBlockBase() function
-returns the base of the range represented by the CBSBlock.
-This function may not be called from the delete callback when the
-block is being deleted entirely.
                
-
                
-
                Note
                
-
                The value of the base of a particular CBSBlock is not
-guaranteed to remain constant across calls to CBSDelete()
-and CBSInsert(), regardless of whether a callback is
-invoked.
                
-
                
-
                
-
                
-Addr CBSBlockLimit(CBSBlock block)
                
-
                
-
-
                .function.cbs.block.limit: The CBSBlockLimit()
-function returns the limit of the range represented by the
-CBSBlock. This function may not be called from the delete
-callback when the block is being deleted entirely.
                
-
                
-
                Note
                
-
                The value of the limit of a particular CBSBlock is not
-guaranteed to remain constant across calls to CBSDelete()
-and CBSInsert(), regardless of whether a callback is
-invoked.
                
-
                
-
                
-
                
-Size CBSBlockSize(CBSBlock block)
                
-
                
-
-
                .function.cbs.block.size: The CBSBlockSize() function
-returns the size of the range represented by the CBSBlock.
-This function may not be called from the delete callback when the
-block is being deleted entirely.
                
-
                
-
                Note
                
-
                The value of the size of a particular CBSBlock is not
-guaranteed to remain constant across calls to CBSDelete()
-and CBSInsert(), regardless of whether a callback is
-invoked.
                
-
                
-
                
-
                
-Res CBSBlockDescribe(CBSBlock block, mps_lib_FILE *stream)
                
-
                
-
-
                .function.cbs.block.describe: The CBSBlockDescribe()
-function prints a textual representation of the CBSBlock to
-the given stream. It is provided for debugging purposes only.
                
-
                
-
                
-Bool CBSFindFirst(Addr *baseReturn, Addr *limitReturn, CBS cbs, Size size, CBSFindDelete findDelete)
                
-
                
-
-
                .function.cbs.find.first: The CBSFindFirst() function
-locates the first block (in address order) within the CBS of at least
-the specified size, and returns its range. If there are no such
-blocks, it returns FALSE. It optionally deletes 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), which must come from
-this enumeration:
                
-
                enum {
-    CBSFindDeleteNONE,    /* don't delete after finding */
-    CBSFindDeleteLOW,     /* delete precise size from low end */
-    CBSFindDeleteHIGH,    /* delete precise size from high end */
-    CBSFindDeleteENTIRE   /* delete entire range */
-};
-
                
-
                
-
                
-
                
-Bool CBSFindLast(Addr *baseReturn, Addr *limitReturn, CBS cbs, Size size, CBSFindDelete findDelete)
                
-
                
-
-
                .function.cbs.find.last: The CBSFindLast() function
-locates the last block (in address order) within the CBS of at least
-the specified size, and returns its range. If there are no such
-blocks, it returns FALSE. Like CBSFindFirst(), it
-optionally deletes the range.
                
-
                
-
                
-Bool CBSFindLargest(Addr *baseReturn, Addr *limitReturn, CBS cbs, CBSFindDelete findDelete)
                
-
                
-
-
                .function.cbs.find.largest: The CBSFindLargest()
-function locates the largest block within the CBS, and returns its
-range. If there are no blocks, it returns FALSE. Like
-CBSFindFirst(), it optionally deletes the range (specifying
-CBSFindDeleteLOW or CBSFindDeleteHIGH has the same effect as
-CBSFindDeleteENTIRE).
                
-
                
-
                
-
                
-
                3.6. Alignment
                
-
                .align: When mayUseInline is specified to permit inline
-data structures and hence avoid losing memory in low memory
-situations, the alignments that the CBS supports are constrained by
-three requirements:
                
-
                  
-
                • The smallest possible range (namely one that is the alignment in
-size) must be large enough to contain a single void * pointer (see
-.impl.low-mem.inline.grain);
                  • 
-
                • Any larger range (namely one that is at least twice the alignment in
-size) must be large enough to contain two void * pointers (see
-.impl.low-mem.inline.block);
                  • 
-
                • It must be valid on all platforms to access a void * pointer
-stored at the start of an aligned range.
                  • 
-
                
-
                All alignments that meet these requirements are aligned to
-sizeof(void *), so we take that as the minimum alignment.
                
-
                
-
                
-
                3.7. Implementation
                
-
                .impl: Note that this section is concerned with describing
-various aspects of the implementation. It does not form part of the
-interface definition.
                
-
                
-
                3.7.1. Size change callback protocol
                
-
                .impl.callback: The size change callback protocol concerns
-the mechanism for informing the client of the appearance and
-disappearance of interesting ranges. The intention is that each range
-has an identity (represented by the CBSBlock). When blocks
-are split, the larger fragment retains the identity. When blocks are
-merged, the new block has the identity of the larger fragment.
                
-
                .impl.callback.delete: Consider the case when the minimum
-size is minSize, and CBSDelete() is called to remove a
-range of size middle. The two (possibly non-existant) neighbouring
-ranges have (possibly zero) sizes left and right. middle is part
-of the CBSBlock middleBlock.
                
-
                .impl.callback.delete.delete: The delete callback will be
-called in this case if and only if:
                
-
                left + middle + right >= minSize  &&  left < minSize  &&  right < minSize
-
                
-
                
-
                That is, the combined range is interesting, but neither remaining
-fragment is. It will be called with the following parameters:
                
-
                  
-
                • block: middleBlock
                  • 
-
                • oldSize: left + middle + right
                  • 
-
                • newSize: left >= right ? left : right
                  • 
-
                
-
                .impl.callback.delete.new: The new callback will be
-called in this case if and only if:
                
-
                left >= minSize  &&  right >= minSize
-
                
-
                
-
                That is, both remaining fragments are interesting. It will be called
-with the following parameters:
                
-
                  
-
                • block: a new block
                  • 
-
                • oldSize: 0
                  • 
-
                • newSize: left >= right ? right : left
                  • 
-
                
-
                .impl.callback.delete.shrink: The shrink callback will be
-called in this case if and only if:
                
-
                left + middle + right >= minSize && (left >= minSize || right >= minSize)
-
                
-
                
-
                That is, at least one of the remaining fragments is still interesting.  It will be called with the following parameters:
                
-
                  
-
                • block: middleBlock
                  • 
-
                • oldSize: left + middle + right
                  • 
-
                • newSize: left >= right ? left : right
                  • 
-
                
-
                .impl.callback.insert: Consider the case when the minimum
-size is minSize, and CBSInsert() is called to add a range
-of size middle. The two (possibly non-existant) neighbouring
-blocks are leftBlock and rightBlock, and have (possibly zero)
-sizes left and right.
                
-
                .impl.callback.insert.delete: The delete callback will be
-called in this case if and only if:
                
-
                
-
                left >= minSize  &&  right >= minSize
                
-
                That is, both neighbours were interesting. It will be called with the
-following parameters:
                
-
                  
-
                • block: left >= right ? rightBlock : leftBlock
                  • 
-
                • oldSize: left >= right ? right : left
                  • 
-
                • newSize: 0
                  • 
-
                
-
                .impl.callback.insert.new: The new callback will be
-called in this case if and only if:
                
-
                
-
                left + middle + right >= minSize  &&  left < minSize  &&  right < minSize
                
-
                That is, the combined block is interesting, but neither neighbour was.
-It will be called with the following parameters:
                
-
                  
-
                • block: left >= right ? leftBlock : rightBlock
                  • 
-
                • oldSize: left >= right ? left : right
                  • 
-
                • newSize: left + middle + right
                  • 
-
                
-
                .impl.callback.insert.grow: The grow callback will be
-called in this case if and only if:
                
-
                left + middle + right >= minSize && (left >= minSize || right >= minSize)
-
                
-
                
-
                That is, at least one of the neighbours was interesting. It will be
-called with the following parameters:
                
-
                  
-
                • block: left >= right ? leftBlock : rightBlock
                  • 
-
                • oldSize: left >= right ? left : right
                  • 
-
                • newSize: left + middle + right
                  • 
-
                
-
                
-
                
-
                3.7.2. 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 for comparison is the base of another range.
                
-
                .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.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 is O(log(n)) in 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(). Except when the
-emergency lists (see .impl.low-mem) are in use, they are
-also searched.
                
-
                
-
                
-
                3.7.3. Low memory behaviour
                
-
                .impl.low-mem: Low memory situations cause problems 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:
                
-
                .impl.low-mem.no-inline: If mayUseInline is FALSE,
-then the range is not added to the CBS, and the call to
-CBSInsert() or CBSDelete() returns ResMEMORY.
                
-
                .impl.low-mem.inline: If mayUseInline is TRUE:
                
-
                .impl.low-mem.inline.block: If the range is large enough to
-contain an inline block descriptor consisting of two pointers, then it
-is kept on an emergency block list. The CBS will eagerly attempt to
-add this block back into the splay tree during subsequent calls to
-CBSInsert() and CBSDelete(). The CBS will also keep
-its emergency block list in address order, and will coalesce this list
-eagerly. Some performance degradation will be seen when the emergency
-block list is in use. Ranges on this emergency block list will not be
-made available to the CBS’s client via callbacks. CBSIterate()
-and CBSIterateLarge() will not iterate over ranges on this
-list.
                
-
                .impl.low-mem.inline.block.structure: The two pointers stored
-are to the next such block (or NULL), and to the limit of the
-block, in that order.
                
-
                .impl.low-mem.inline.grain: Otherwise, the range must be
-large enough to contain an inline grain descriptor consisting of one
-pointer, then it is kept on an emergency grain list. The CBS will
-eagerly attempt to add this grain back into either the splay tree or
-the emergency block list during subsequent calls to
-CBSInsert() and CBSDelete(). The CBS will also keep
-its emergency grain list in address order. Some performance
-degradation will be seen when the emergency grain list is in use.
-Ranges on this emergency grain list will not be made available to the
-CBS’s client via callbacks. CBSIterate() and
-CBSIterateLarge() will not iterate over ranges on this list.
                
-
                .impl.low-mem.inline.grain.structure: The pointer stored is
-to the next such grain, or NULL.
                
-
                
-
                
-
                3.7.4. The CBS block
                
-
                .impl.cbs.block: The block contains a base-limit pair and a
-splay tree node.
                
-
                .impl.cbs.block.special: The base and limit may be equal if
-the block is halfway through being deleted.
                
-
                .impl.cbs.block.special.just: This conflates values and
-status, but is justified because block size is very important.
                
-
                
-
                
-
                
-
                3.8. 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.pool: Several pools (currently MVT (Manual Variable Temporal) and
-MVFF (Manual Variable First Fit)) are implemented on top of a CBS. These pool are
-subject to testing in development, QA, and are/will be heavily
-exercised by customers.
                
-
                
-
                
-
                3.9. 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.hybrid: It would be possible to attenuate the problem
-of .risk.overhead (below) by using a single word bit set to
-represent the membership in a (possibly aligned) word-width of grains.
-This might be used for block sizes less than a word-width of grains,
-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).
                
-
                
-
                
-
                3.10. Risks
                
-
                .risk.overhead: Clients should note that the current
-implementation of CBSs has a space overhead proportional to the number
-of isolated contiguous ranges. [Four words per range.] If the CBS
-contains every other grain in an area, then the overhead will be large
-compared to the size of that area. [Four words per two grains.] See
-.future.hybrid for a suggestion to solve this problem. An
-alternative solution is to use CBSs only for managing long ranges.
                
-
                
-
                
-
                3.11. Proposed hybrid implementation
                
-
                
-
                Note
                
-
                The following relates to a pending re-design and does not yet
-relate to any working source version. GavinM 1998-09-25
                
-
                
-
                The CBS system provides its services by combining the services
-provided by three subsidiary CBS modules:
                
-
                  
-
                • CBSST – Splay Tree: Based on out-of-line splay trees; must
-allocate to insert isolated, which may therefore fail.
                  • 
-
                • CBSBL – Block List: Based on a singly-linked list of variable
-sized ranges with inline descriptors; ranges must be at least large
-enough to store the inline descriptor.
                  • 
-
                • CBSGL – Grain List: Based on a singly-linked list of fixed size
-ranges with inline descriptors; the ranges must be the alignment of
-the CBS.
                  • 
-
                
-
                The three sub-modules have a lot in common. Although their methods are
-not invoked via a dispatcher, they have been given consistent
-interfaces, and consistent internal appearance, to aid maintenance.
                
-
                Methods supported by sub-modules (not all sub-modules support all
-methods):
                
-
                  
-
                • MergeRange – Finds any ranges in the specific CBS adjacent to
-the supplied one. If there are any, it extends the ranges, possibly
-deleting one of them. This cannot fail, but should return FALSE
-if there is an intersection between the supplied range and a range
-in the specific CBS.
                  • 
-
                • InsertIsolatedRange – Adds a range to the specific CBS that is
-not adjacent to any range already in there. Depending on the
-specific CBS, this may be able to fail for allocation reasons, in
-which case it should return FALSE. It should AVER() if
-the range is adjacent to or intersects with a range already there.
                  • 
-
                • RemoveAdjacentRanges – Finds and removes from the specific CBS
-any ranges that are adjacent to the supplied range. Should return
-FALSE if the supplied range intersects with any ranges already
-there.
                  • 
-
                • DeleteRange – Finds and deletes the supplied range from the
-specific CBS. Returns a tri-state result:
                    
-
                  • Success – The range was successfully deleted. This may have
-involved the creation of a new range, which should be done via
-CBSInsertIsolatedRange.
                    • 
-
                  • ProtocolError – Either some non-trivial strict subset of the
-supplied range was in the specific CBS, or a range adjacent to the
-supplied range was in the specific CBS. Either of these indicates
-a protocol error.
                    • 
-
                  • NoIntersection – The supplied range was not found in the CBS.
-This may or not be a protocol error, depending on the invocation
-context.
                    • 
-
                  
-
                  • 
-
                • FindFirst – Returns the first (in address order) range in the
-specific CBS that is at least as large as the supplied size, or
-FALSE if there is no such range.
                  • 
-
                • FindFirstBefore – As FindFirst, but only finds ranges prior
-to the supplied address.
                  • 
-
                • FindLast – As FindFirst, but finds the last such range in
-address order.
                  • 
-
                • FindLastAfter – FindLast equivalent of FindFirstBefore.
                  • 
-
                • Init – Initialise the control structure embedded in the CBS.
                  • 
-
                • Finish – Finish the control structure embedded in the CBS.
                  • 
-
                • InlineDescriptorSize – Returns the aligned size of the inline descriptor.
                  • 
-
                • Check – Checks the control structure embedded in the CBS.
                  • 
-
                
-
                The CBS supplies the following utilities:
                
-
                  
-
                • CBSAlignment – Returns the alignment of the CBS.
                  • 
-
                • CBSMayUseInline – Returns whether the CBS may use the memory in
-the ranges stored.
                  • 
-
                • CBSInsertIsolatedRange – Wrapper for CBS*InsertIsolatedRange.
                  • 
-
                
-
                Internally, the CBS* sub-modules each have an internal structure
-CBS*Block that represents an isolated range within the module. It
-supports the following methods (for sub-module internal use):
                
-
                  
-
                • BlockBase – Returns the base of the associated range;
                  • 
-
                • BlockLimit
                  • 
-
                • BlockRange
                  • 
-
                • BlockSize
                  • 
-
                
-
                
-
                
-
-
-          
                
-        
                
-      
                
-      
                
-        
                
-            
-  
                Table Of Contents
                
-  
-
-  
                Previous topic
                
-  
                2. Bit tables
                
-  
                Next topic
                
-  
                4. Checking
                Downloads
                
-
-
                
-MPS Kit release 1.111.0
                
-All MPS Kit releases
-
                
-
-
                Issues
                
-
-
                
-Known issues
                
-Issues fixed in release 1.111.0
-
                Contact us
                
-
-
                mps-questions@ravenbrook.com
                
-        
                
-      
                
-      
                
-    
                
-    
                
-      
                Navigation
                
-      
-    
                
-    
                
-        © Copyright 2013, Ravenbrook Limited.
-      Created using Sphinx 1.1.3.
-    
                
-  
-
\ No newline at end of file
diff --git a/mps/manual/html/design/check.html b/mps/manual/html/design/check.html
index dbbfddbc686..6600fa47ee5 100644
--- a/mps/manual/html/design/check.html
+++ b/mps/manual/html/design/check.html
@@ -8,7 +8,7 @@
   
     
     
-    4. Checking — Memory Pool System 1.111.0 documentation
+    6. Checking — Memory Pool System 1.111.0 documentation
     
     
     
@@ -28,8 +28,8 @@
     
     
     
-    
-     
+    
+     
   
   
     
                
@@ -39,10 +39,10 @@ 
                Navigation
                
           index
         
              • 
-          next |
                • 
         
              • 
-          previous |
                • 
         
              • Memory Pool System 1.111.0 documentation »
                • 
           
              • Old design »
                •  
@@ -54,16 +54,16 @@ 
                Navigation
                
         
                
           
                
             
-  
                
-
                4. Checking
                
+  
                
+
                6. Checking
                
 
                
-
                4.1. Introduction
                
+
                6.1. Introduction
                
 
                .intro: This documents the design of structure checking within the
 MPS.
                
 
                .readership: MPS developers.
                
 
                
 
                
-
                4.2. Implementation
                
+
                6.2. Implementation
                
 
                .level: There are three levels of checking:
                
 
                  
 
                1. .level.sig: The lowest level checks only that the
@@ -159,19 +159,19 @@ 
                  4.2. ImplementationTable Of Contents

            .var.cool: COOL

            Intended for use during development. Moderately thorough internal @@ -192,9 +192,12 @@

            1.5.1. Abstract Build Function.build.srcs: The “srcs” are the set of sources that must be compiled in order to build the target. The set of sources may vary depending on the configuration. For example, different sets of sources -may be required to build different architectures. [This is a -dependency between the makefile (or whatever) and the module -configuration in config.h.]

            +may be required to build different architectures.

            +
            +

            Note

            +

            This is a dependency between the makefile (or whatever) and the +module configuration in config.h.

            +

            .build.libs: The “libs” are the set of libraries to which the compiled sources must be linked in order to build the target. For example, when building a test program, it might include the ANSI C @@ -215,27 +218,28 @@

            1.5.2. File Structure.mod.impls.

            -

            1.5.3. Modules and Naming

            +

            1.5.3. Modules and naming

            .mod.unique: Each module has an identifier which is unique within the MPS.

            .mod.impls: Each module has one or more implementations which may be -in any language supported by the relevant build environment. -.mod.primary: The primary implementation of a module is written in +in any language supported by the relevant build environment.

            +

            .mod.primary: The primary implementation of a module is written in target-independent ANSI C in a source file with the same name as the -module. .mod.an: Where there are platform-specific implementations -and an inferior portable ANSI C fallback implementation, “an” is used in -place of the platform code. .mod.secondary: The names of other -implementations should begin with the same prefix (the module id or a -shortened version of it) and be suffixed with on or more target -parameter codes (defined below). In particular, the names of assembly -language sources must include the target parameter code for the relevant -architecture.

            +module.

            +

            .mod.an: Where there are platform-specific implementations and an +inferior portable ANSI C fallback implementation, “an” is used in +place of the platform code.

            +

            .mod.secondary: The names of other implementations should begin +with the same prefix (the module id or a shortened version of it) and +be suffixed with on or more target parameter codes (defined below). In +particular, the names of assembly language sources must include the +target parameter code for the relevant architecture.

            .mod.example: For example, the stack scanner is defined in ss.h (which is platform-independent). It has some platform-independent C in ss.c and, for example, ssw3i6mv.c is specific to Windows on the x64 architecture built with Microsoft Visual C.

            -

            1.5.4. Build System Rationale

            +

            1.5.4. Build system rationale

            .build.rat: This simple design makes it possible to build the MPS using many different tools. Microsoft Visual C and other graphical development tools do not support much in the way of generated sources, @@ -303,7 +307,7 @@

            1.6. Implementation.conf).

            -

            1.6.1. Target Platform Detection

            +

            1.6.1. Target platform detection

            .pf: The target platform is “detected” by the preprocessor directives in mpstd.h.

            .pf.form: This file consists of sets of directives of the form:

            @@ -340,16 +344,16 @@

            1.6.1. Target Platform Detection.pf.word: The declaration of MPS_T_WORD defines the unsigned -integral type which corresponds, on the detected target, to the machine -word. It is used to defined the MPS Word type (design.mps.type.word). -[Insert backwards ref there.] (We avoid using typedef here because -mpstd.h could potentially be included in assembly language source -code.) For example:

            +integral type which corresponds, on the detected target, to the +machine word. It is used to defined the MPS Word type +(design.mps.type.word). For example:

            #define MPS_T_WORD      unsigned long
            +

            We avoid using typedef here because mpstd.h could potentially +be included in assembly language source code.

            .pf.word-width: The declaration of MPS_WORD_WIDTH defines the -number of bits in the type defined by MPS_T_WORD (.pf.word) on the +number of bits in the type defined by MPS_T_WORD (.pf.word) on the target. For example:

            #define MPS_WORD_WIDTH  32
            @@ -380,37 +384,31 @@

            1.6.1. Target Platform Detection -

            1.6.2. Target Varieties

            +

            1.6.2. Target varieties

            .var: The target variety is handled by preprocessor directives in -impl.h.config. .var.form: The file contains sets of directives of -the form:

            -
            #elif defined(CONFIG_VAR_DF)
-#define MPS_VAR_DF
-#define ASSERT_MPSI
-#define ASSERT_MPM
-etc.
+impl.h.config.
            
+
            .var.form: The file contains sets of directives of the form:
            
+
            #if defined(CONFIG_VAR_COOL)
+#define CONFIG_ASSERT
+#define CONFIG_ASSERT_ALL
+#define CONFIG_STATS
 
            
 
            
 
            .var.detect: The configured variety is one of the variety
-preprocessor definitions passed to the build function (.build.defs),
-e.g. CONFIG_VAR_HOT. These are decoupled so that it’s possible to
-tell the difference between overridden settings etc.  [Explain.]
            
+preprocessor definitions passed to the build function
+(.build.defs), for example, CONFIG_VAR_COOL. These are
+decoupled in order to keep the number of supported varieties small,
+controlling each feature (for example, assertions) by a single
+preprocessor definition, and maintaining flexibility about which
+features are enabled in each variety.
            
 
            .var.symbols: The directives should define whatever symbols are
-necessary to control annotations.  These symbols parameterize other
-parts of the code, such as the declaration of assertions, etc.  The
-symbols should all begin with the prefix MPS_VAR\_.
            
-
            [Tidy this up:]
-Note, anything which can be configured, is configured, even if it’s just
-configured to “NONE” meaning nothing.  This makes sure that you can’t
-choose something by omission.  Where these symbols are used there will
-be a #error to catch the unused case.  Exception: To allow simple
-building of the MPS with “cc -c mps.c” we choose CONFIG_VAR_HOT by
-default.
-[This is a general principle which applies to other configuration stuff too.]
            
+necessary to control featrues. These symbols parameterize other parts
+of the code, such as the declaration of assertions, etc. The symbols
+should all begin with the prefix CONFIG_.
            -

            1.7. Source Code Configuration

            +

            1.7. Source code configuration

            .conf: This section describes how the configuration may affect the source code of the MPS.

            .conf.limit: The form of dependency allowed is carefully limited to @@ -447,19 +445,19 @@

            1.7.2. Abstract and Concrete Module Interfaces
            #if defined(PROT_FOO)
-void ProtSpong(Foo foo, Bar bar);
+void ProtSpong(Foo foo, Bar bar);
 #else
-int ProtSpong(Bar bar, Foo foo);
+int ProtSpong(Bar bar, Foo foo);
 #endif

            This example shows how:

            #ifdef PROTECTION
-void ProtSync(Space space);
-/* more decls. */
+void ProtSync(Space space);
+/* more decls. */
 #else /* PROTECTION not */
 #define ProtSync(space) NOOP
-/* more decls. */
+/* more decls. */
 #endif /* PROTECTION */
            @@ -511,18 +509,24 @@

            1.8. To document

            1.9. References

            - + + + + + +
            [RB_2012-09-07]Richard Brooksby. Ravenbrook Limited. 2012-09-07. “The critical path through the MPS”.
            + + + + + +
            [RB_2012-09-13]Richard Brooksby. Ravenbrook Limited. 2013-09-13. “The Configura CET custom mainline”.
            + + + + + +
            [PP_2005-03-01]Pekka Pirinen. Global Graphics. 2005-03-01. “MPS platforms”.

            @@ -545,19 +549,19 @@

            Table Of Contents

          • 1.3. Definitions
          • 1.4. Overview
            • -
          • 1.5. The Build System
              -
            • 1.5.1. Abstract Build Function
              • +
            • 1.5. The build system
            • 1.6. Implementation
              • -
            • 1.7. Source Code Configuration
                +
              • 1.7. Source code configuration diff --git a/mps/manual/html/design/critical-path.html b/mps/manual/html/design/critical-path.html index 145c3effc93..302a60224cf 100644 --- a/mps/manual/html/design/critical-path.html +++ b/mps/manual/html/design/critical-path.html @@ -54,8 +54,12 @@

                Navigation

                -
                -

                2. The critical path through the MPS

                +
                +

                2. The critical path through the MPS

                +
                +
                single: critical path +single: path; critical +single: Memory Pool System; critical path

                2.1. Introduction

                The critical path is a key concept in the design of the Memory Pool @@ -131,15 +135,21 @@

                2.3. How the MPS avoids scanning and fixing

                2.4. Where to find the critical path

                Very briefly, the critical path consists of five stages:

                -
                  -
                1. The scanner, which iterates over pointers in objects. The MPS has +
                    +

                  1. The scanner, which iterates over pointers in objects. The MPS has several internal scanners, but the most important ones will be format scanners in client code registered through mps_format_create() -functions. [Insert ref to manual explaining how to write a good -scanner.]

                    2. -
                  2. The first-stage fix, which filters out pointers inline in the +functions.

                    +
                    +

                    Note

                    +

                    There needs to be a chapter in the manual explaining how to +write a good scanner. Then that could be linked from here.

                    +
                    +
                    3. +

                  3. The first-stage fix, which filters out pointers inline in the scanner. This is implemented in MPS_FIX() macros in -mps.h.

                    4. +mps.h.

                    +

                  1. The second-stage fix, which filters out pointers using general @@ -148,7 +158,7 @@

                    2.4. Where to find the critical pathThe third-stage fix, which filters out pointers using pool-specific information. Implemented in pool class functions called AMCFix(), -LOFix(), etc. in pool*.c.

                    +LOFix(), etc. in pool*.c.

                  2. Preserving the object, which might entail

                      @@ -171,18 +181,18 @@

                      2.5. The format scannerHere is an example of part of a format scanner for scanning contiguous runs of pointers, from fmtdy.c, the scanner for the Open Dylan runtime:

                      -
                      static mps_res_t dylan_scan_contig(mps_ss_t mps_ss,
-                                   mps_addr_t *base, mps_addr_t *limit)
+
                      static mps_res_t dylan_scan_contig(mps_ss_t mps_ss,
+                                   mps_addr_t *base, mps_addr_t *limit)
 {
-  mps_res_t res;
-  mps_addr_t *p;        /* reference cursor */
-  mps_addr_t r;         /* reference to be fixed */
+  mps_res_t res;
+  mps_addr_t *p;        /* reference cursor */
+  mps_addr_t r;         /* reference to be fixed */
 
   MPS_SCAN_BEGIN(mps_ss) {
           p = base;
     loop: if(p >= limit) goto out;
           r = *p++;
-          if(((mps_word_t)r&3) != 0) /* pointers tagged with 0 */
+          if(((mps_word_t)r&3) != 0) /* pointers tagged with 0 */
             goto loop;             /* not a pointer */
           if(!MPS_FIX1(mps_ss, r)) goto loop;
           res = MPS_FIX2(mps_ss, p-1);
@@ -286,7 +296,7 @@ 
                      2.7. The third stage fix in the pool classRankAMBIG) then it
-can’t be changed, so even a [copying] pool class can’t move an object.
+can’t be changed, so even a copying pool class can’t move an object.
 On the other hand, if the pointer is weak (RankWEAK) then the pool fix
 method shouldn’t preserve the object at all, even if it’s condemned.
                      
 
                      The exact details of the logic that the pool fix must implement in
@@ -302,13 +312,13 @@ 
                      2.7. The third stage fix in the pool classLOFix() is the pool fix method for the Leaf
-Only pool class. It implements a [marking] garbage collector, and does
+
                      As a simple example, LOFix() is the pool fix method for the Leaf
+Only pool class. It implements a marking garbage collector, and does
 not have to worry about scanning preserved objects because it is used
 to store objects that don’t contain pointers. (It is used in compiler
 run-time systems to store binary data such as character strings, thus
 avoiding any scanning, decoding, or remembered set overhead for them.)
                      
-
                      LOFix() filters any ambiguous pointers that aren’t aligned, since
+
                      LOFix() filters any ambiguous pointers that aren’t aligned, since
 they can’t point to objects it allocated. Otherwise it subtracts the
 segment base address and shifts the result to get an index into a mark
 bit table. If the object wasn’t marked and the pointer is weak, then
@@ -340,10 +350,12 @@ 
                      2.8. Other considerations
 
                      
 
                      2.9. References
                      
-
+
+
+
+
+
+
                      [MMRef]“The Memory Management Reference”; <http://www.memorymanagement.org/>.
                      
 
                      
 
                      
 
diff --git a/mps/manual/html/design/diag.html b/mps/manual/html/design/diag.html
new file mode 100644
index 00000000000..0a802106c85
--- /dev/null
+++ b/mps/manual/html/design/diag.html
@@ -0,0 +1,378 @@
+
+
+
+
+
+
+  
+    
+    
+    9. Diagnostic feedback — Memory Pool System 1.111.0 documentation
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+     
+  
+  
+    
                      
+      
                      Navigation
                      
+      
+    
                        
+
+    
                      
+      
                      
+        
                      
+          
                      
+            
+  
                      
+
                      9. Diagnostic feedback
                      
+
                      
+
                      9.1. Introduction
                      
+
                      .intro: This document describes how to use the diagnostic feedback
+mechanism in the Memory Pool System.
                      
+
                      .sources: Initially abased on [RHSK_2007-04-13] and [RHSK_2007-04-18].
                      
+
                      
+
                      
+
                      9.2. Overview
                      
+
                      Diagnostic feedback is information created by the MPS diagnostic
+system for the purpose of helping MPS programmers client-code
+programmers.
                      
+
                      Such a piece of information is called “a diagnostic”. (See also
+.parts.)
                      
+
                      A diagnostic is not intended to be end-user readable (or visible), or
+machine-parseable.
                      
+
                      A diagnostic is not intended to be stable from one release to the
+next: it may be modified or removed at any time.
                      
+
                      
+
                      
+
                      9.3. Requirements
                      
+
                      MPS diagnostic feedback code must do these things:
                      
+
                        
+
                      • calculate, store, and propagate data;
                        • 
+
                      • collate, synthesise, and format it into a human-useful diagnostic;
                        • 
+
                      • control (for example, filter) output of diagnostics;
                        • 
+
                      • use a channel to get the diagnostic out.
                        • 
+
                      
+
                      Note: the knowledge/code/logic for constructing the human-useful
+message is kept inside normal MPS source code. This means it is always
+in-sync with changes to the MPS. This also means that any external
+utilities used to display the messages do not need to understand, or
+keep in sync with, the details of what’s going inside the MPS.
                      
+
                      
+
                      
+
                      9.4. Usage
                      
+
                      To run the MPS and get diagnostic output from it:
                      
+
                        
+
                      1. Use a variety with diagnostics compiled-in. Currently, that means
+variety.di. See config.h.
                        2. 
+
                      2. Check that the diagnostics you require are generated, by looking in
+MPS source for invocations of the appropriate macro (for example,
+DIAG_SINGLEF()).
                        3. 
+
                      3. Check that the diagnostics you require will be output, by looking
+at the diagnostic filter rules in diag.c.
                        4. 
+
                      4. Run the MPS and client in an environment that supports the channel
+used (for example, at a command-line if using WriteF()).
                        5. 
+
                      
+
                      
+
                      9.4.1. What is a diagnostic?
                      
+
                      A diagnostic has three parts:
                      
+
                        
+
                      1. a trigger condition, that causes this diagnostic to be emitted;
                        2. 
+
                      2. a text tag (for example, “TraceStart”) which is the name of this
+diagnostic; and
                        3. 
+
                      3. a paragraph of human-useful text.
                        4. 
+
                      
+
                      A diagnostic is emitted by the MPS at a certain point in time when a
+certain event happens.
                      
+
                      Diagnostics are not nested. Every diagnostic must have a tag. Each
+diagnostic should have a unique tag (uniqueness is just to help the
+humans; the diagnostic system does not care).
                      
+
                      The paragraph of text can be many lines long. It usually explains what
+event caused the diagnostic to be emitted, and commonly also includes
+the output of some Describe() methods for various relevant
+objects. (For example, the TraceStart diagnostic might call, and
+include the output generated by, the TraceDescribe() method).
                      
+
                      
+
                      
+
                      9.4.2. How do I control (filter) which diagnostics I see?
                      
+
                      All diagnostics are emitted and then filtered according to the
+“diagnostic filter rules”.
                      
+
                      The first level of control is filtering by tag. (For example, only
+show TraceStart diagnostics).
                      
+
                      The second level of control is filtering by paragraph content. (For
+example, only show TraceStart diagnostics where the trace is
+started because a nursery generation is full).
                      
+
                      The third level of control is filtering by line content. (For example,
+only show lines containing the word whiteSet).
                      
+
                      See diag.c for details.
                      
+
                      Note: the entire filtering mechanism can be turned off, so that
+diagnostics go immediately to mps_lib_get_stdout(0, with no
+buffering or filtering See impl.c.diag.filter-disable.
                      
+
                      
+
                      
+
                      
+
                      9.5. How to write a diagnostic
                      
+
                      
+
                      9.5.1. Improve stateless Describe methods where possible
                      
+
                      Where possible, don’t put clever code into an event-triggered
+diagnostic: put it into a stateless Describe() method instead, and
+then call that method when emitting your diagnostic.
                      
+
                      For example:
                      
+
                      FooDescribe(Foo foo, mps_lib_FILE *stream)
+{
+  /* show value of new "quux" field */
+  WriteF(stream, "Foo: $P { quux: $U }\n", foo, foo->quux);
+}
+
+FooWibble(Foo foo)
+{
+  ...
+  DIAG_FIRSTF(( "FooWibble", "Wibbling foo $P", foo, NULL));
+  DIAG( FooDescribe(foo, DIAG_STREAM); );
+  DIAG_END("FooWibble");
+  ...
+}
+
                      
+
                      
+
                      This is much better, because other people can use your human-useful
+output in their diagnostics, or ‘live’ in a debugger.
                      
+
                      
+
                      
+
                      9.5.2. Use the output macros
                      
+
                      For a simple diagnostic, use DIAG_SINGLEF(). This begins the tag,
+puts text into the paragraph, and ends the tag immediately.
                      
+
                      For a more complex diagnostic, the first call must be
+DIAG_FIRSTF(), which begins a diag tag.
                      
+
                      While a tag is current, you can add text to the diagnostic’s paragraph
+using DIAG_MOREF(), and WriteF( DIAG_STREAM, ... ).
                      
+
                      
+
                      Note
                      
+
                      DIAG_STREAM is not a real standard C library stream. If you
+want stream-level access, you may use Stream_fputc() and
+Stream_fputs().
                      
+
                      
+
                      End the tag by calling DIAG_END.
                      
+
                      
+
                      
+
                      9.5.3. Compile away in non-diag varieties; no side effects
                      
+
                      Wrap non-output code with the DIAG() and DIAG_DECL() macros,
+to make sure that non-diag varieties do not execute
+diagnostic-generating code.
                      
+
                      For complex diagnostic-generating code, it may be cleaner to move it
+into a separate local function. Put _diag on the end of the function
+name (for example, TraceStart_diag()).
                      
+
                      Obviously, diagnostic-generating code must have no side effects.
                      
+
                      
+
                      
+
                      9.5.4. Choosing tags
                      
+
                      Tags should be valid C identifiers. Unless you know of a good reason
+why not. (Not currently checked).
                      
+
                      There’s no formal scheme for tag naming, but make it helpful and
+informally hierarchical, for example, TraceBegin, TraceStart,
+TraceEnd, and so on, not BeginTrace, EndTrace.
                      
+
                      
+
                      
+
                      9.5.5. Writing good paragraph text
                      
+
                      IMPORTANT: Make your diagnostics easy to understand! Other people will
+read your diagnostics! Make them clear and helpful. Do not make them
+terse and cryptic. If you use symbols, print a key in the diagnostic.
+(If you don’t want to see this the screen clutter, then you can always
+add a filter rule to your personal rule set to filter it out).
                      
+
                      
+
                      
+
                      9.5.6. Maintaining helpful filter rules
                      
+
                      If you add a noisy diagnostic, add a rule to the default ruleset to
+turn it off.
                      
+
                      
+
                      
+
                      
+
                      9.6. How the MPS diagnostic system works
                      
+
                      
+
                      9.6.1. Channels
                      
+
                      The recommended channel is WriteF() to standard output.
                      
+
                      Other possible of future channels might be:
                      
+
                        
+
                      • printf();
                        • 
+
                      • a new type (yet to be defined) of mps_message;
                        • 
+
                      • squirt them into the telemetry-log-events system;
                        • 
+
                      • telnet.
                        • 
+
                      
+
                      Currently, only printf() and WriteF() are supported. See the
+DIAG_WITH_ macros in mpm.h.
                      
+
                      You can also use a debugger to call Describe() methods directly,
+from within the debugger.
                      
+
                      Note: it is unfortunate that choice of channel may (for some channels)
+also dictate the form of the code that synthesises the message. (For
+example, WriteF() style parameter-expansion is not possible when
+using the printf() channel, because there is no way to get
+WriteF() to produce its output into a string). This is just a
+technical hitch; logically, the code that synthesises a diagnostic
+message should not care which channel will be used to transmit it out
+of the MPS.
                      
+
                      
+
                      
+
                      9.6.2. Parts of the MPS diagnostic system
                      
+
                      .parts: The following facilities are considered part of the MPS
+diagnostic system:
                      
+
                        
+
                      • the Describe() methods.
                        • 
+
                      • the DIAG macros (DIAG, DIAG_DECL, DIAG_*F, and so on);
                        • 
+
                      • the STATISTIC macros (see mpm.h);
                        • 
+
                      • the METER macros and meter subsystem.
                        • 
+
                      
+
                      
+
+
                      
+
                      
+
                      9.7. References
                      
+
+
+
+
+
+
                      [RHSK_2007-04-13]Richard Kistruck. 2007-04-13. “diagnostic feedback from the MPS”.
                      
+
+
+
+
+
+
                      [RHSK_2007-04-18]Richard Kistruck. 2007-04-18. “Diverse types of diagnostic feedback”.
                      
+
                      
+
                      
+
+
+          
                      
+        
                      
+      
                      
+      
                      
+        
                      
+            
+  
                      Table Of Contents
                      
+  
+
+  
                      Previous topic
                      
+  
                      8. Collection framework
                      
+  
                      Next topic
                      
+  
                      10. Finalization
                      Downloads
                      
+
+
                      
+MPS Kit release 1.111.0
                      
+All MPS Kit releases
+
                      
+
+
                      Issues
                      
+
+
                      
+Known issues
                      
+Issues fixed in release 1.111.0
+
                      Contact us
                      
+
+
                      mps-questions@ravenbrook.com
                      
+        
                      
+      
                      
+      
                      
+    
                      
+    
                      
+      
                      Navigation
                      
+      
+    
                      
+    
                      
+        © Copyright 2013, Ravenbrook Limited.
+      Created using Sphinx 1.1.3.
+    
                      
+  
+
\ No newline at end of file
diff --git a/mps/manual/html/design/finalize.html b/mps/manual/html/design/finalize.html
index d45ea90db70..0370c0446b0 100644
--- a/mps/manual/html/design/finalize.html
+++ b/mps/manual/html/design/finalize.html
@@ -8,7 +8,7 @@
   
     
     
-    7. Finalization — Memory Pool System 1.111.0 documentation
+    10. Finalization — Memory Pool System 1.111.0 documentation
     
     
     
@@ -28,8 +28,8 @@
     
     
     
-    
-     
+    
+     
   
   
     
                      
@@ -39,10 +39,10 @@ 
                      Navigation
                      
           index
         
                    • 
-          next |
                      • 
         
                    • 
-          previous |
                      • 
         
                    • Memory Pool System 1.111.0 documentation »
                      • 
           
                    • Old design »
                      •  
@@ -54,10 +54,10 @@ 
                      Navigation
                      
         
                      
           
                      
             
-  
                      
-
                      7. Finalization
                      
+  
                      
+
                      10. Finalization
                      
 
                      
-
                      7.1. Overview
                      
+
                      10.1. Overview
                      
 
                      .overview: Finalization is implemented internally using the
 Guardian Pool Class (design.mps.poolmrg). Objects can be registered
 for finalization using an interface function (called
@@ -66,15 +66,15 @@ 
                      Navigation
                      
 implements a Message Class which implements the finalization messages.
                      
 
                      
 
                      
-
                      7.2. Requirements
                      
+
                      10.2. Requirements
                      
 
                      .req: Historically only Dylan had requirements for finalization,
 see req.dylan.fun.final. Now (2003-02-19) Configura have requirements
 for finalization. Happily they are very similar.
                      
 
                      
 
                      
-
                      7.3. Architecture
                      
+
                      10.3. Architecture
                      
 
                      
-
                      7.3.1. External interface
                      
+
                      10.3.1. External interface
                      
 
                      .if.register: mps_finalize() increases the number of times that
 an object has been registered for finalization by one. The object must
 have been allocated from the arena (space). Any finalization messages
@@ -92,7 +92,7 @@ 
                      7.3.1. External interface
 
                      
 
                      
-
                      7.4. Implementation
                      
+
                      10.4. Implementation
                      
 
                      .int.over: Registering an object for finalization corresponds to
 allocating a reference of rank FINAL to that object. This reference is
 allocated in a guardian object in a pool of PoolClassMRG (see
@@ -130,13 +130,17 @@ 
                      7.4. Implementation.access.invariants: We protect the invariants by using special
 routines ArenaRead() and ArenaPoke() to read and write the
-reference. This works as long as there’s no write-barrier collection.
-[Instead of ArenaPoke(), we could put in an ArenaWrite() that
-would be identical to ArenaPoke(), except for AVERring the invariant
-(or it can just AVER there are no busy traces unflipped). When we get
-write-barrier collection, we could change it to do the real thing, but
-in the absence of a write-barrier, it’s functionally identical to
-ArenaPoke(). Pekka 1997-12-09]
                      
+reference. This works as long as there’s no write-barrier collection.
                      
+
                      
+
                      Note
                      
+
                      Instead of ArenaPoke(), we could put in an ArenaWrite()
+that would be identical to ArenaPoke(), except that it would
+AVER() the invariant (or it can just AVER() that there are
+no busy traces unflipped). When we get write-barrier collection,
+we could change it to do the real thing, but in the absence of a
+write-barrier, it’s functionally identical to ArenaPoke().
+Pekka P. Pirinen, 1997-12-09.
                      
+
                      
 
                      
 
                      
 
@@ -151,24 +155,24 @@ 
                      7.4. ImplementationTable Of Contents

                      -
                      -

                      3. Transliterating the alphabet into hexadecimal

                      +
                      +

                      3. Transliterating the alphabet into hexadecimal

                      3.1. Introduction

                      .scope: This document explains how to represent the alphabet as @@ -109,7 +109,7 @@

                      3.3. Justification -

                      3.4. 4. Notes

                      +

                      3.4. Notes

                      .change: This transliteration differs from the old transliteration used for signatures (see design.mps.sig(0)), as follows: J:6->1; L:1->7; N:9->4; R:4->6; W:8->3; X:5->8; Y:E->I.

                      @@ -147,7 +147,7 @@

                      Table Of Contents

                    • 3.1. Introduction
                    • 3.2. Transliteration
                    • 3.3. Justification
                      • -
                    • 3.4. 4. Notes
                      • +
                    • 3.4. Notes

              @@ -156,8 +156,8 @@

              Previous topic

              2. The critical path through the MPS

              Next topic

              -

              4. Keyword arguments in the MPS

              Downloads

              +

              4. C Style – formatting

              Downloads

              MPS Kit release 1.111.0
              @@ -183,7 +183,7 @@

              Navigation

              index
            • - next |
            • + + + + + + + 4. C Style – formatting — Memory Pool System 1.111.0 documentation + + + + + + + + + + + + + + + +
              +

              Navigation

              +               +
              + +
              +
              +
              +
              + +
              +

              4. C Style – formatting

              +
              +

              4.1. Introduction

              +

              .scope: This document describes the Ravenbrook conventions for the +general format of C source code in the MPS.

              +

              .readership: This document is intended for anyone working on or with the +C source code.

              +
              +
              +

              4.2. General Formatting Conventions

              +
              +

              4.2.1. Line Width

              +

              .width: Lines should be no wider than 72 characters. .width.why: Many +people use 80 column terminal windows so that multiple windows can be +placed side by side. Restricting lines to 72 characters allows line +numbering to be used (in vi for example) and also allows diffs to be +displayed without overflowing the terminal.

              +
              +
              +

              4.2.2. White Space

              +

              .space.notab: No tab characters should appear in the source files. +Ordinary spaces should be used to indent and format the sources. +.space.notab.why: Tab characters are displayed differently on different +platforms, and sometimes translated back and forth, destroying layout +information.

              +

              .space.punct: There should always be whitespace after commas and +semicolons and similar punctuation.

              +

              .space.op: Put white space around operators in expressions, except when +removing it would make the expression clearer by binding certain +sub-expressions more tightly. For example:

              +
              foo = x + y*z;
+
              +
              +

              .space.control: One space between the keyword, switch, while, +for and the following paren. .space.control.why: This distinguishes +control statements lexically from function calls, making it easier to +distinguish them visually and when searching with tools like grep.

              +

              .space.function.not: No space between a function name and the following +paren beginning its argument list.

              +
              +
              +

              4.2.3. Sections and Paragraphs

              +

              .section: Source files can be thought of as breaking down into +“sections” and “paragraphs”. A section might be the leader comment of a +file, the imports, or a set of declarations which are related.

              +

              .section.space: Precede sections by two blank lines (except the first +one in the file, which should be the leader comment in any case).

              +

              .section.comment: Each section should start with a banner comment (see +.comment.banner) describing what the section contains.

              +

              .para: Within sections, code often breaks down into natural units called +“paragraphs”. A paragraph might be a set of strongly related +declarations (Init and Finish, for example), or a few lines of code +which it makes sense to consider together (the assignment of fields into +a structure, for example).

              +

              .para.space: Precede paragraphs by a single blank line.

              +
              +
              +

              4.2.4. Statements

              +

              .statement.one: Generally only have at most one statement per line. In +particular the following are deprecated:

              +
              if (thing) return;
+
+a=0; b=0;
+
+case 0: f = inRampMode ? AMCGen0RampmodeFrequency : AMCGen0Frequency;
+
              +
              +

              .statement.one.why: Debuggers can often only place breakpoints on lines, +not expressions or statements within a line. The if (thing) return; is +a particularly important case, if thing is a reasonably rare return +condition then you might want to breakpoint it in a debugger session. +Annoying because if (thing) return; is quite compact and pleasing +otherwise.

              +
              +
              +

              4.2.5. Indentation

              +

              .indent: Indent the body of a block by two spaces. For formatting +purposes, the “body of a block” means:

              +
                +
              • statements between braces,
                • +
              • a single statement following a lone if;
                • +
              • statements in a switch body; see .switch.
                • +
              +

              (.indent.logical: The aim is to group what we think of as logical +blocks, even though they may not exactly match how “block” is used in +the definition of C syntax).

              +

              Some examples:

              +
              if (res != ResOK) {
+  SegFinish(&span->segStruct);
+  PoolFreeP(MV->spanPool, span, sizeof(SpanStruct));
+  return res;
+}
+
+if (res != ResOK)
+  goto error;
+
+if (j == block->base) {
+  if (j+step == block->limit) {
+    if (block->thing)
+      putc('@', stream);
+  }
+} else if (j+step == block->limit) {
+  putc(']', stream);
+  pop_bracket();
+} else {
+  putc('.', stream);
+}
+
+switch (c) {
+case 'A':
+  c = 'A';
+  p += 1;
+  break;
+}
+
              +
              +

              .indent.goto-label: Place each goto-label on a line of its own, +outdented to the same level as the surrounding block. Then indent the +non-label part of the statement normally.

              +
              result foo(void)
+{
+  statement();
+  if (error)
+    goto foo;
+  statement();
+  return OK;
+
+foo:
+  unwind();
+  return ERROR;
+}
+
              +
              +

              .indent.case-label: Outdent case- and default-labels in a switch +statement in the same way as .indent.goto-label. See .switch.

              +

              .indent.cont: If an expression or statement won’t fit on a single line, +indent the continuation lines by two spaces, apart from the following +exception:

              +

              .indent.cont.parens: if you break a statement inside a parameter list or +other parenthesized expression, indent so that the continuation lines up +just after the open parenthesis. For example:

              +
              PoolClassInit(&PoolClassMVStruct,
+              "MV", init, finish, allocP, freeP,
+              NULL, NULL, describe, isValid);
+
              +
              +

              .indent.cont.expr: Note that when breaking an expression it is clearer +to place the operator at the start of the continuation line:

              +
              CHECKL(AddrAdd((Addr)chunk->pageTableMapped,
+               BTSize(chunk->pageTablePages))
+       <= AddrAdd(chunk->base, chunk->ullageSize));
+
              +
              +

              This is particularly useful in long conditional expressions that use && +and ||. For example:

              +
              } while(trace->state != TraceFINISHED
+        && (trace->emergency || traceWorkClock(trace) < pollEnd));
+
              +
              +

              .indent.hint: Usually, it is possible to determine the correct +indentation for a line by looking to see if the previous line ends with +a semicolon. If it does, indent to the same amount, otherwise indent by +two more spaces. The main exceptions are lines starting with a close +brace, goto-labels, and line-breaks between parentheses.

              +
              +
              +

              4.2.6. Positioning of Braces

              +

              .brace.otb: Use the “One True Brace” (or OTB) style. This places the +open brace after the control word or expression, separated by a space, +and when there is an else, places that after the close brace. For +example:

              +
              if(isBase) {
+  new->base = limit;
+  new->limit = block->limit;
+  block->limit = base;
+  new->next = block->next;
+  block->next = new;
+} else {
+  new->base = block->base;
+  new->limit = base;
+  block->base = limit;
+  new->next = block;
+  *prev = new;
+}
+
              +
              +

              The same applies to struct, enum, union.

              +

              .brace.otb.function.not: OTB is never used for function definitions.

              +

              .brace.always: Braces are always required after if, else, switch, +while, do, and for.

              +

              .brace.always.except: Except that a lone if with no else is allowed +to drop its braces when its body is a single simple statement. Typically +this will be a goto or an assignment. For example:

              +
              if (res != ResOK)
+  goto failStart;
+
              +
              +

              Note in particular that an if with an else must have braces on both +paths.

              +
              +
              +

              4.2.7. Switch Statements

              +

              .switch: format switch statements like this:

              +
              switch (action) {
+case WIBBLE:
+case WOBBLE:
+  {
+    int angle;
+    err = move(plate, action, &angle);
+  }
+  break;
+
+case QUIET:
+  drop();
+  /* fall-through */
+
+case QUIESCENT:
+  err = 0;
+  break;
+
+default:
+  NOTREACHED;
+  break;
+}
+
              +
              +

              The component rules that result in this style are:

              +

              .switch.break: The last line of every case-clause body must be an +unconditional jump statement (usually break, but may be goto, +continue, or return), or if a fall-through is intended, the comment +/* fall-through */. (Note: if the unconditional jump should never be +taken, because of previous conditional jumps, use NOTREACHED on the +line before it). This rule is to prevent accidental fall-throughs, even +if someone makes a editing mistake that causes a conditional jump to be +missed.

              +

              .switch.default: It is usually a good idea to have a default-clause, +even if all it contains is NOTREACHED and break. Remember that +NOTREACHED doesn’t stop the process in all build varieties.

              +
              +
              +

              4.2.8. Formatting Comments

              +

              .comment: There are three types of comments: banners, paragraph +comments, and columnar comments.

              +

              .comment.banner: Banner comments come at the start of sections. A banner +comment consists of a heading usually composed of a symbol, an em-dash +(–) and an short explanation, followed by English text which is +formatted using conventional text documentation guidelines (see +guide.text). The open and close comment tokens (/* and */) are +placed at the top and bottom of a column of asterisks. The text is +separated from the asterisks by one space. Place a blank line between +the banner comment and the section it comments. For example:

              +
              /* BlockStruct --  Block descriptor
+ *
+ * The pool maintains a descriptor structure for each
+ * contiguous allocated block of memory it manages.
+ * The descriptor is on a simple linked-list of such
+ * descriptors, which is in ascending order of address.
+ */
+
+typedef struct BlockStruct {
+
              +
              +

              .comment.para: Paragraph comments come at the start of paragraphs in the +code. A paragraph comment consists of formatted English text, with each +line wrapped by the open and close comment tokens (/* and */). +(This avoids problems when cutting and pasting comments.) For example:

              +
              /* If the freed area is in the base sentinel then insert */
+/* the new descriptor after it, otherwise insert before. */
+if(isBase) {
+
              +
              +

              .comment.para.precede: Paragraph comments, even one-liners, precede the +code to which they apply.

              +

              .comment.column: Columnar comments appear in a column to the right of +the code. They should be used sparingly, since they clutter the code and +make it hard to edit. Use them on variable declarations and structure, +union, or enum declarations. They should start at least at column 32 +(counting from 0, that is, on a tab-stop), and should be terse +descriptive text. Abandon English sentence structure if this makes the +comment clearer. Don’t write more than one line. Here’s an example:

              +
              typedef struct PoolMVStruct {
+  Pool blockPool;           /* for block descriptors */
+  Pool spanPool;            /* for span descriptors */
+  size_t extendBy;          /* size to extend pool by */
+  size_t avgSize;           /* estimate of allocation size */
+  size_t maxSize;           /* estimate of maximum size */
+  Addr space;               /* total free space in pool */
+  Addr lost;                /* lost when free can't allocate */
+  struct SpanStruct *spans; /* span chain */
+} PoolMVStruct;
+
              +
              +
              +
              +

              4.2.9. Macros

              +

              .macro.careful: Macros in C are a real horror bag, be extra careful. +There’s lots that could go here, but proper coverage probably deserves a +separate document. Which isn’t written yet.

              +

              .macro.general: Do try and follow the other formatting conventions for +code in macro definitions.

              +

              .macro.backslash: Backslashes used for continuation lines in macro +definitions should be put on the right somewhere where they will be less +in the way. Example:

              +
              #define RAMP_RELATION(X)                       \
+  X(RampOUTSIDE,        "outside ramp")        \
+  X(RampBEGIN,          "begin ramp")          \
+  X(RampRAMPING,        "ramping")             \
+  X(RampFINISH,         "finish ramp")         \
+  X(RampCOLLECTING,     "collecting ramp")
+
              +
              +
              +
              +
              +

              4.3. History

              +
                +
              • 2007-06-04 DRJ Adopted from Harlequin MMinfo version and edited.
                • +
              • 2007-06-04 DRJ Changed .width from 80 to 72. Banned space between +if and (. Required braces on almost everything. Clarified that +paragraph comments precede the code.
                • +
              • 2007-06-13 RHSK Removed .brace.block, because MPS source always +uses .brace.otb. Remove .indent.elseif because it is obvious (ahem) and +showing an example is sufficient. New rules for .switch.*: current MPS +practice is a mess, so lay down a neat new law.
                • +
              • 2007-06-27 RHSK Added .space.function.not.
                • +
              • 2007-07-17 DRJ Added .macro.*
                • +
              • 2012-09-26 RB Converted to Markdown and reversed inconsistent +switch “law”.
                • +
              +
              + +
              + + +
              +
              +
              +
              +
              + +

              Table Of Contents

              + + +

              Previous topic

              +

              3. Transliterating the alphabet into hexadecimal

              +

              Next topic

              +

              5. Keyword arguments in the MPS

              Downloads

              + +

              +MPS Kit release 1.111.0
              +All MPS Kit releases +

              + +

              Issues

              + +

              +Known issues
              +Issues fixed in release 1.111.0 +

              Contact us

              + +

              mps-questions@ravenbrook.com

              +
              +
              +
              +
              +
              +

              Navigation

              + +
              +
              + © Copyright 2013, Ravenbrook Limited. + Created using Sphinx 1.1.3. +
              + + \ No newline at end of file diff --git a/mps/manual/html/design/index.html b/mps/manual/html/design/index.html index d338e790983..281a50530a8 100644 --- a/mps/manual/html/design/index.html +++ b/mps/manual/html/design/index.html @@ -64,19 +64,19 @@

              Navigation

            • 1.3. Definitions
            • 1.4. Overview
              • -
            • 1.5. The Build System
                -
              • 1.5.1. Abstract Build Function
                • +
              • 1.5. The build system
              • 1.6. Implementation
                • -
              • 1.7. Source Code Configuration
                • -
              • 4. Keyword arguments in the MPS
                  -
                • 4.1. Introduction
                  • -
                • 4.2. Overview
                  • -
                • 4.3. Internals
                  • -
                • 4.4. The varargs legacy
                  • -
                • 4.5. References
                  • +
                • 4. C Style – formatting
                    +
                  • 4.1. Introduction
                    • +
                  • 4.2. General Formatting Conventions
                    • -
                  • 5. Ring data structure
                    • -
                  • 6. Signatures in the MPS diff --git a/mps/manual/html/design/interface-c.html b/mps/manual/html/design/interface-c.html new file mode 100644 index 00000000000..b04ebc977c7 --- /dev/null +++ b/mps/manual/html/design/interface-c.html @@ -0,0 +1,406 @@ + + + + + + + + + + 12. C interface design — Memory Pool System 1.111.0 documentation + + + + + + + + + + + + + + + +
                    +

                    Navigation

                    + +
                    + +
                    +
                    +
                    +
                    + +
                    +

                    12. C interface design

                    +
                    +

                    12.1. Introduction

                    +

                    .scope: This document is the design for the Memory Pool System +(MPS) interface to the C Language, impl.h.mps.

                    +

                    .bg: See mail.richard.1996-07-24.10-57.

                    +
                    +
                    +

                    12.2. Analysis

                    +
                    +

                    12.2.1. Goals

                    +

                    .goal.c: The file impl.h.mps is the C external interface to the +MPS. It is the default interface between client code written in C and +the MPS. .goal.cpp: impl.h.mps is not specifically designed to be +an interface to C++, but should be usable from C++.

                    +
                    +
                    +

                    12.2.2. Requirements

                    +

                    .req: The interface must provide an interface from client code +written in C to the functionality of the MPS required by the product +(see req.product), Dylan (req.dylan), and the Core RIP (req.epcore).

                    +

                    mps.h may not include internal MPS header files (such as +pool.h).

                    +

                    It is essential that the interface cope well with change, in order to +avoid restricting possible future MPS developments. This means that +the interface must be “open ended” in its definitions. This accounts +for some of the apparently tortuous methods of doing things +(mps_fmt_A_t, for example). The requirement is that the MPS should +be able to add new functionality, or alter the implementation of +existing functionality, without affecting existing client code. A +stronger requirement is that the MPS should be able to change without +recompiling client code. This is not always possible.

                    +
                    +

                    Note

                    +

                    .naming.global was presumably done in response to unwritten +requirements regarding the use of the name spaces in C, perhaps +these:

                    +
                      +
                    • .req.name.iso: The interface shall not conflict in terms of +naming with any interfaces specified by ISO C and all reasonable +future versions.
                      • +
                    • .req.name.general: The interface shall use a documented and +reasonably small portion of the namespace so that clients can +interoperate easily.
                      • +
                    +

                    David Jones, 1998-10-01.

                    +
                    +
                    +
                    +
                    +

                    12.3. Architecture

                    +

                    .fig.arch: The architecture of the MPS Interface

                    +

                    [missing figure]

                    +

                    Just behind mps.h is the file mpsi.c, the “MPS interface +layer” which does the job of converting types and checking parameters +before calling through to the MPS proper, using internal MPS methods.

                    +
                    +
                    +

                    12.4. General conventions

                    +

                    .naming: The external interface names should adhere to the +documented interface conventions; these are found in +doc.mps.ref-man.if-conv(0).naming. They are paraphrased/recreated +here.

                    +

                    .naming.unixy: The external interface does not follow the same +naming conventions as the internal code. The interface is designed to +resemble a more conventional C, Unix, or Posix naming convention.

                    +

                    .naming.case: Identifiers are in lower case, except +non-function-like macros, which are in upper case.

                    +

                    .naming.global: All publicised identifiers are +prefixed mps_ or MPS_.

                    +

                    .naming.all: All identifiers defined by the MPS +should begin mps_ or MPS_ or _mps_.

                    +

                    .naming.type: Types are suffixed _t.

                    +

                    .naming.struct: Structure types and tags are suffixed _s.

                    +

                    .naming.union: Unions types and tags are suffixed _u.

                    +

                    .naming.scope: The naming conventions apply to all identifiers (see +ISO C §6.1.2); this includes names of functions, variables, types +(through typedef), structure and union tags, enumeration members, +structure and union members, macros, macro parameters, labels.

                    +

                    .naming.scope.labels: labels (for goto statements) should be +rare, only in special block macros and probably not even then.

                    +
                    +

                    Note

                    +

                    This principle is not adhered to in the source code, which uses +goto for handling error cases. Gareth Rees, 2013-05-27.

                    +
                    +

                    .naming.scope.other: The naming convention would also extend to +enumeration types and parameters in functions prototypes but both of +those are prohibited from having names in an interface file.

                    +

                    .type.gen: The interface defines memory addresses as void * and +sizes as size_t for compatibility with standard C (in particular, +with malloc()). These types must be binary compatible with the +internal types Addr and Size respectively. Note that this +restricts the definitions of the internal types Addr and Size +when the MPS is interfaced with C, but does not restrict the MPS in +general.

                    +

                    .type.opaque: Opaque types are defined as pointers to structures +which are never defined. These types are cast to the corresponding +internal types in mpsi.c.

                    +

                    .type.trans: Some transparent structures are defined. The client is +expected to read these, or poke about in them, under restrictions +which should be documented. The most important is probably the +allocation point (mps_ap_s) which is part of allocation buffers. +The transparent structures must be binary compatible with +corresponding internal structures. For example, the fields of +mps_ap_s must correspond with APStruct internally. This is +checked by mpsi.c in mps_check().

                    +

                    .type.pseudo: Some pseudo-opaque structures are defined. These only +exist so that code can be inlined using macros. The client code +shouldn’t mess with them. The most important case of this is the scan +state (mps_ss_s) which is accessed by the in-line scanning macros, +MPS_SCAN_* and MPS_FIX*.

                    +

                    .type.enum: There should be no enumeration types in the interface. +Note that enum specifiers (to declare integer constants) are fine as +long as no type is declared. See guide.impl.c.misc.enum.type.

                    +

                    .type.fun: Whenever function types or derived function types (such +as pointer to function) are declared a prototype should be used and +the parameters to the function should not be named. This includes the +case where you are declaring the prototype for an interface function.

                    +

                    .type.fun.example: So use:

                    +
                    extern mps_res_t mps_alloc(mps_addr_t *, mps_pool_t, size_t, ...);
+
                    +
                    +

                    rather than:

                    +
                    extern mps_res_t mps_alloc(mps_addr_t *addr_return, mps_pool_t pool , size_t size, ...);
+
                    +
                    +

                    and:

                    +
                    typedef mps_addr_t (*mps_fmt_class_t)(mps_addr_t);
+
                    +
                    +

                    rather than:

                    +
                    typedef mps_addr_t (*mps_fmt_class_t)(mps_addr_t object);
+
                    +
                    +

                    See guide.impl.c.misc.prototype.parameters.

                    +
                    +
                    +

                    12.5. Checking

                    +

                    .check.space: When the arena needs to be recovered from a parameter +it is check using AVERT(Foo, foo) before any attempt to call +FooArena(foo). The macro AVERT() in impl.h.assert performs +simple thread-safe checking of foo, so it can be called outside of +ArenaEnter() and ArenaLeave().

                    +

                    .check.types: We use definitions of types in both our external +interface and our internal code, and we want to make sure that they +are compatible. (The external interface changes less often and hides +more information.) At first, we were just checking their sizes, which +wasn’t very good, but I’ve come up with some macros which check the +assignment compatibility of the types too. This is a sufficiently +useful trick that I thought I’d send it round. It may be useful in +other places where types and structures need to be checked for +compatibility at compile time.

                    +

                    These macros don’t generate warnings on the compilers I’ve tried.

                    +
                    +
                    +COMPATLVALUE(lvalue1, lvalue2)
                    +
                    + +

                    This macro checks the assignment compatibility of two lvalues. It uses +sizeof() to ensure that the assignments have no effect.

                    +
                    #define COMPATLVALUE(lv1, lv2) \
+  ((void)sizeof((lv1) = (lv2)), (void)sizeof((lv2) = (lv1)), TRUE)
+
                    +
                    +
                    +
                    +COMPATTYPE(type1, type2)
                    +
                    + +

                    This macro checks that two types are assignment-compatible and equal +in size. The hack here is that it generates an lvalue for each type by +casting zero to a pointer to the type. The use of sizeof() avoids +the undefined behaviour that would otherwise result from dereferencing +a null pointer.

                    +
                    #define COMPATTYPE(t1, t2) \
+  (sizeof(t1) == sizeof(t2) && \
+   COMPATLVALUE(*((t1 *)0), *((t2 *)0)))
+
                    +
                    +
                    +
                    +COMPATFIELDAPPROX(structure1, field1, structure2, field2)
                    +
                    + +

                    This macro checks that the offset and size of two fields in two +structure types are the same.

                    +
                    #define COMPATFIELDAPPROX(s1, f1, s2, f2) \
+  (sizeof(((s1 *)0)->f1) == sizeof(((s2 *)0)->f2) && \
+   offsetof(s1, f1) == offsetof(s2, f2))
+
                    +
                    +
                    +
                    +COMPATFIELD(structure1, field1, structure2, field2)
                    +
                    + +

                    This macro checks the offset, size, and assignment-compatibility of +two fields in two structure types.

                    +
                    #define COMPATFIELD(s1, f1, s2, f2) \
+  (COMPATFIELDAPPROX(s1, f1, s2, f2) && \
+   COMPATLVALUE(((s1 *)0)->f1, ((s2 *)0)->f2))
+
                    +
                    +
                    +
                    +

                    12.6. Binary compatibility issues

                    +

                    As in, “Enumeration types are not allowed” (see +mail.richard.1995-09-08.09-28).

                    +

                    There are two main aspects to run-time compatibility: binary interface +and protocol. The binary interface is all the information needed to +correctly use the library, and includes external symbol linkage, +calling conventions, type representation compatibility, structure +layouts, etc. The protocol is how the library is actually used by the +client code – whether this is called before that – and determines +the semantic correctness of the client with respect to the library.

                    +

                    The binary interface is determined completely by the header file and +the target. The header file specifies the external names and the +types, and the target platform specifies calling conventions and type +representation. There is therefore a many-to-one mapping between the +header file version and the binary interface.

                    +

                    The protocol is determined by the implementation of the library.

                    +
                    +
                    +

                    12.7. Constraints

                    +

                    .cons: The MPS C Interface constrains the MPS in order to provide +useful memory management services to a C or C++ program.

                    +

                    .cons.addr: The interface constrains the MPS address type, Addr +(design.mps.type.addr), to being the same as C’s generic pointer type, +void *, so that the MPS can manage C objects in the natural way.

                    +

                    .pun.addr: We pun the type of mps_addr_t (which is void *) +into Addr (an incomplete type, see design.mps.type.addr). This +happens in the call to the scan state’s fix function, for example.

                    +

                    .cons.size: The interface constrains the MPS size type, Size +(design.mps.type.size), to being the same as C’s size type, +size_t, so that the MPS can manage C objects in the natural way.

                    +

                    .pun.size: We pun the type of size_t in mps.h into Size in +the MPM, as an argument to the format methods. We assume this works.

                    +

                    .cons.word: The MPS assumes that Word (design.mps.type.word) +and Addr (design.mps.type.addr) are the same size, and the +interface constrains Word to being the same size as C’s generic +pointer type, void *.

                    +
                    +
                    +

                    12.8. Notes

                    +

                    The file mpstd.h is the MPS target detection header. It decodes +preprocessor symbols which are predefined by build environments in +order to determine the target platform, and then defines uniform +symbols, such as MPS_ARCH_I3, for use internally by the MPS.

                    +

                    There is a design document for the mps interface, +design.mps.interface, but it was written before we had the idea of +having a C interface layer. It is quite relevant, though, and could be +updated. We should use it during the review.

                    +

                    All exported identifiers and file names should begin with mps_ or +MPS_ so that they don’t clash with other systems.

                    +

                    We should probably have a specialized set of rules and a special +checklist for this interface.

                    +

                    .fmt.extend: This paragraph should be an explanation of why +mps_fmt_A_t is so called. The underlying reason is future +extensibility.

                    +

                    .thread-safety: Most calls through this interface lock the space +and therefore make the MPM single-threaded. In order to do this they +must recover the space from their parameters. Methods such as +ThreadSpace() must therefore be callable when the space is not +locked. These methods are tagged with the tag of this note.

                    +

                    .lock-free: Certain functions inside the MPM are thread-safe and do +not need to be serialized by using locks. They are marked with the tag +of this note.

                    +

                    .form: Almost all functions in this implementation simply cast +their arguments to the equivalent internal types, and cast results +back to the external type, where necessary. Only exceptions are noted +in comments.

                    +
                    +
                    + + +
                    +
                    +
                    +
                    +
                    + +

                    Table Of Contents

                    + + +

                    Previous topic

                    +

                    11. The generic fix function

                    +

                    Next topic

                    +

                    13. I/O subsystem

                    Downloads

                    + +

                    +MPS Kit release 1.111.0
                    +All MPS Kit releases +

                    + +

                    Issues

                    + +

                    +Known issues
                    +Issues fixed in release 1.111.0 +

                    Contact us

                    + +

                    mps-questions@ravenbrook.com

                    +
                    +
                    +
                    +
                    +
                    +

                    Navigation

                    + +
                    +
                    + © Copyright 2013, Ravenbrook Limited. + Created using Sphinx 1.1.3. +
                    + + \ No newline at end of file diff --git a/mps/manual/html/design/io.html b/mps/manual/html/design/io.html new file mode 100644 index 00000000000..cda8b724e48 --- /dev/null +++ b/mps/manual/html/design/io.html @@ -0,0 +1,494 @@ + + + + + + + + + + 13. I/O subsystem — Memory Pool System 1.111.0 documentation + + + + + + + + + + + + + + + +
                    +

                    Navigation

                    + +
                    + +
                    +
                    +
                    +
                    + +
                    +

                    13. I/O subsystem

                    +
                    +

                    13.1. Introduction

                    +

                    .intro: This document is the design of the MPS I/O Subsystem, a +part of the plinth.

                    +

                    .readership: This document is intended for MPS developers.

                    +
                    +
                    +

                    13.2. Background

                    +

                    .bg: This design is partly based on the design of the Internet User +Datagram Protocol (UDP). Mainly I used this to make sure I hadn’t left +out anything which we might need.

                    +
                    +
                    +

                    13.3. Purpose

                    +

                    .purpose: The purpose of the MPS I/O Subsystem is to provide a +means to measure, debug, control, and test a memory manager build +using the MPS.

                    +

                    .purpose.measure: Measurement consists of emitting data which can +be collected and analysed in order to improve the attributes of +application program, quite possibly by adjusting parameters of the +memory manager (see overview.mps.usage).

                    +

                    .purpose.control: Control means adjusting the behaviour of the MM +dynamically. For example, one might want to adjust a parameter in +order to observe the effect, then transfer that adjustment to the +client application later.

                    +

                    .purpose.test: Test output can be used to ensure that the memory +manager is behaving as expected in response to certain inputs.

                    +
                    +
                    +

                    13.4. Requirements

                    +
                    +

                    13.4.1. General

                    +

                    .req.fun.non-hosted: The MPM must be a host-independent system.

                    +

                    .req.attr.host: It should be easy for the client to set up the MPM +for a particular host (such as a washing machine).

                    +
                    +
                    +

                    13.4.2. Functional

                    +

                    .req.fun.measure: The subsystem must allow the MPS to transmit +quantitative measurement data to an external tool so that the system +can be tuned.

                    +

                    .req.fun.debug: The subsystem must allow the MPS to transmit +qualitative information about its operation to an external tool so +that the system can be debugged.

                    +

                    .req.fun.control: The subsystem must allow the MPS to receive +control information from an external tool so that the system can be +adjusted while it is running.

                    +

                    .req.dc.env.no-net: The subsystem should operate in environments +where there is no networking available.

                    +

                    .req.dc.env.no-fs: The subsystem should operate in environments +where there is no filesystem available.

                    +
                    +
                    +
                    +

                    13.5. Architecture

                    +

                    .arch.diagram: I/O Architecture Diagram

                    +

                    [missing diagram]

                    +

                    .arch.int: The I/O Interface is a C function call interface by +which the MPM sends and receives “messages” to and from the hosted I/O +module.

                    +

                    .arch.module: The modules are part of the MPS but not part of the +freestanding core system (see design.mps.exec-env). The I/O module is +responsible for transmitting those messages to the external tools, and +for receiving messages from external tools and passing them to the +MPM.

                    +

                    .arch.module.example: For example, the “file implementation” might +just send/write telemetry messages into a file so that they can be +received/read later by an off-line measurement tool.

                    +

                    .arch.external: The I/O Interface is part of interface to the +freestanding core system (see design.mps.exec-env). This is so that +the MPS can be deployed in a freestanding environment, with a special +I/O module. For example, if the MPS is used in a washing machine the +I/O module could communicate by writing output to the seven-segment +display.

                    +
                    +

                    13.5.1. Example configurations

                    +

                    .example.telnet: This shows the I/O subsystem communicating with a +telnet client over a TCP/IP connection. In this case, the I/O +subsystem is translating the I/O Interface into an interactive text +protocol so that the user of the telnet client can talk to the MM.

                    +

                    [missing diagram]

                    +

                    .example.file: This shows the I/O subsystem dumping measurement +data into a file which is later read and analysed. In this case the +I/O subsystem is simply writing out binary in a format which can be +decoded.

                    +

                    [missing diagram]

                    +

                    .example.serial: This shows the I/O subsystem communicating with a +graphical analysis tool over a serial link. This could be useful for a +developer who has two machines in close proximity and no networking +support.

                    +

                    .example.local: In this example the application is talking directly +to the I/O subsystem. This is useful when the application is a +reflective development environment (such as MLWorks) which wants to +observe its own behaviour.

                    +

                    [missing diagram]

                    +
                    +
                    +
                    +

                    13.6. Interface

                    +

                    .if.msg: The I/O interface is oriented around opaque binary +“messages” which the I/O module must pass between the MPM and external +tools. The I/O module need not understand or interpret the contents of +those messages.

                    +

                    .if.msg.opaque: The messages are opaque in order to minimize the +dependency of the I/O module on the message internals. It should be +possible for clients to implement their own I/O modules for unusual +environments. We do not want to reveal the internal structure of our +data to the clients. Nor do we want to burden them with the details of +our protocols. We’d also like their code to be independent of ours, so +that we can expand or change the protocols without requiring them to +modify their modules.

                    +

                    .if.msg.dgram: Neither the MPM nor the external tools should assume +that the messages will be delivered in finite time, exactly once, or +in order. This will allow the I/O modules to be implemented using +unreliable transport layers such as the Internet User Datagram Protocl +(UDP). It will also give the I/O module the freedom to drop +information rather than block on a congested network, or stop the +memory manager when the disk is full, or similar events which really +shouldn’t cause the memory manager to stop working. The protocols we +need to implement at the high level can be design to be robust against +lossage without much difficulty.

                    +
                    +

                    13.6.1. I/O module state

                    +

                    .if.state: The I/O module may have some internal state to preserve. +The I/O Interface defines a type for this state, mps_io_t, a +pointer to an incomplete structure mps_io_s. The I/O module is at +liberty to define this structure.

                    +
                    +
                    +

                    13.6.2. Message types

                    +

                    .if.type: The I/O module must be able to deliver messages of +several different types. It will probably choose to send them to +different destinations based on their type: telemetry to the +measurement tool, debugging output to the debugger, etc.

                    +
                    typedef int mps_io_type_t;
+enum {
+  MPS_IO_TYPE_TELEMETRY,
+  MPS_IO_TYPE_DEBUG
+};
+
                    +
                    +
                    +
                    +

                    13.6.3. Limits

                    +

                    .if.message-max: The interface will define an unsigned integral +constant MPS_IO_MESSAGE_MAX which will be the maximum size of +messages that the MPM will pass to mps_io_send() (.if.send) and +the maximum size it will expect to receive from mps_io_receive().

                    +
                    +
                    +

                    13.6.4. Interface set-up and tear-down

                    +

                    .if.create: The MPM will call mps_io_create() to set up the I/O +module. On success, this function should return MPS_RES_OK. It may +also initialize a “state” value which will be passed to subsequent +calls through the interface.

                    +

                    .if.destroy: The MPM will call mps_io_destroy() to tear down +the I/O module, after which it guarantees that the state value will +not be used again. The state parameter is the state previously +returned by mps_io_create() (.if.create).

                    +
                    +
                    +

                    13.6.5. Message send and receive

                    +
                    +
                    +extern mps_res_t mps_io_send(mps_io_t state, mps_io_type_t type, void *message, size_t size)
                    +
                    + +

                    .if.send: The MPM will call mps_io_send() when it wishes to +send a message to a destination. The state parameter is the state +previously returned by mps_io_create() (.if.create). The +type parameter is the type (.if.type) of the message. The +message parameter is a pointer to a buffer containing the message, +and size is the length of that message, in bytes. The I/O module +must make an effort to deliver the message to the destination, but is +not expected to guarantee delivery. The function should return +MPS_RES_IO only if a serious error occurs that should cause the +MPM to return with an error to the client application. Failure to +deliver the message does not count.

                    +
                    +

                    Note

                    +

                    Should there be a timeout parameter? What are the timing +constraints? mps_io_send() shouldn’t block.

                    +
                    +
                    +
                    +extern mps_res_t mps_io_receive(mps_io_t state, void **buffer_o, size_t *size_o)
                    +
                    + +

                    .if.receive: The MPM will call mps_io_receive() when it wants +to see if a message has been sent to it. The state parameter is +the state previously returned by mps_io_create() (.if.create). +The buffer_o parameter is a pointer to a value which should be +updated with a pointer to a buffer containing the message received. +The size_o parameter is a pointer to a value which should be +updated with the length of the message received. If there is no +message ready for receipt, the length returned should be zero.

                    +
                    +

                    Note

                    +

                    Should we be able to receive truncated messages? How can this be +done neatly?

                    +
                    +
                    +
                    +
                    +

                    13.7. I/O module implementations

                    +
                    +

                    13.7.1. Routeing

                    +

                    The I/O module must decide where to send the various messages. A +file-based implementation could put them in different files based on +their types. A network-based implementation must decide how to address +the messages. In either case, any configuration must either be +statically compiled into the module, or else read from some external +source such as a configuration file.

                    +
                    +
                    +
                    +

                    13.8. Notes

                    +

                    The external tools should be able to reconstruct stuff from partial +info. For example, you come across a fragment of an old log containing +just a few old messages. What can you do with it?

                    +

                    Here’s some completely untested code which might do the job for UDP.

                    +
                    #include "mpsio.h"
+
+#include <sys/types.h>
+#include <sys/socket.h>
+#include <netinet/in.h>
+#include <arpa/inet.h>
+#include <fcntl.h>
+#include <errno.h>
+
+typedef struct mps_io_s {
+  int sock;
+  struct sockaddr_in mine;
+  struct sockaddr_in telemetry;
+  struct sockaddr_in debugging;
+} mps_io_s;
+
+static mps_bool_t inited = 0;
+static mps_io_s state;
+
+
+mps_res_t mps_io_create(mps_io_t *mps_io_o)
+{
+  int sock, r;
+
+  if(inited)
+    return MPS_RES_LIMIT;
+
+  state.mine = /* setup somehow from config */;
+  state.telemetry = /* setup something from config */;
+  state.debugging = /* setup something from config */;
+
+  /* Make a socket through which to communicate. */
+  sock = socket(AF_INET, SOCK_DGRAM, 0);
+  if(sock == -1) return MPS_RES_IO;
+
+  /* Set socket to non-blocking mode. */
+  r = fcntl(sock, F_SETFL, O_NDELAY);
+  if(r == -1) return MPS_RES_IO;
+
+  /* Bind the socket to some UDP port so that we can receive messages. */
+  r = bind(sock, (struct sockaddr *)&state.mine, sizeof(state.mine));
+  if(r == -1) return MPS_RES_IO;
+
+  state.sock = sock;
+
+  inited = 1;
+
+  *mps_io_o = &state;
+  return MPS_RES_OK;
+}
+
+
+void mps_io_destroy(mps_io_t mps_io)
+{
+  assert(mps_io == &state);
+  assert(inited);
+
+  (void)close(state.sock);
+
+  inited = 0;
+}
+
+
+mps_res_t mps_io_send(mps_io_t mps_io, mps_type_t type,
+                      void *message, size_t size)
+{
+  struct sockaddr *toaddr;
+
+  assert(mps_io == &state);
+  assert(inited);
+
+  switch(type) {
+    MPS_IO_TYPE_TELEMETRY:
+    toaddr = (struct sockaddr *)&state.telemetry;
+    break;
+
+    MPS_IO_TYPE_DEBUGGING:
+    toaddr = (struct sockaddr *)&state.debugging;
+    break;
+
+    default:
+    assert(0);
+    return MPS_RES_UNIMPL;
+  }
+
+  (void)sendto(state.sock, message, size, 0, toaddr, sizeof(*toaddr));
+
+  return MPS_RES_OK;
+}
+
+
+mps_res_t mps_io_receive(mps_io_t mps_io,
+                         void **message_o, size_t **size_o)
+{
+  int r;
+  static char buffer[MPS_IO_MESSAGE_MAX];
+
+  assert(mps_io == &state);
+  assert(inited);
+
+  r = recvfrom(state.sock, buffer, sizeof(buffer), 0, NULL, NULL);
+  if(r == -1)
+    switch(errno) {
+      /* Ignore interrupted system calls, and failures due to lack */
+      /* of resources (they might go away.) */
+      case EINTR: case ENOMEM: case ENOSR:
+      r = 0;
+      break;
+
+      default:
+      return MPS_RES_IO;
+    }
+
+  *message_o = buffer;
+  *size_o = r;
+  return MPS_RES_OK;
+}
+
                    +
                    +
                    +
                    +

                    13.9. Attachments

                    +

                    “O Architecture Diagram” +“O Configuration Diagrams”

                    +
                    +
                    + + +
                    +
                    +
                    +
                    +
                    + +

                    Table Of Contents

                    + + +

                    Previous topic

                    +

                    12. C interface design

                    +

                    Next topic

                    +

                    14. Library interface

                    Downloads

                    + +

                    +MPS Kit release 1.111.0
                    +All MPS Kit releases +

                    + +

                    Issues

                    + +

                    +Known issues
                    +Issues fixed in release 1.111.0 +

                    Contact us

                    + +

                    mps-questions@ravenbrook.com

                    +
                    +
                    +
                    +
                    +
                    +

                    Navigation

                    + +
                    +
                    + © Copyright 2013, Ravenbrook Limited. + Created using Sphinx 1.1.3. +
                    + + \ No newline at end of file diff --git a/mps/manual/html/design/keyword-arguments.html b/mps/manual/html/design/keyword-arguments.html index c5a2eb9df5b..03ea43d150f 100644 --- a/mps/manual/html/design/keyword-arguments.html +++ b/mps/manual/html/design/keyword-arguments.html @@ -8,7 +8,7 @@ - 4. Keyword arguments in the MPS — Memory Pool System 1.111.0 documentation + 5. Keyword arguments in the MPS — Memory Pool System 1.111.0 documentation @@ -28,8 +28,8 @@ - - + +
                    @@ -39,10 +39,10 @@

                    Navigation

                    index
                  • - next |
                  • - previous |
                  • Memory Pool System 1.111.0 documentation »
                  • Design »
                    • @@ -54,10 +54,10 @@

                    Navigation

                    -
                    -

                    4. Keyword arguments in the MPS

                    +
                    +

                    5. Keyword arguments in the MPS

                    -

                    4.1. Introduction

                    +

                    5.1. Introduction

                    Up to version 1.111, the Memory Pool System used varags to pass arguments to arena and pool classes, because the general MPS interface can’t specify what arguments those classes might need in C prototypes. This @@ -67,12 +67,12 @@

                    4.1. Introduction -

                    4.2. Overview

                    +

                    5.2. Overview

                    The basic design is not specific to the MPS. The keyword argument list is passed as an array of argument structures which look like this:

                    -
                    typedef struct mps_key_s *mps_key_t;
+
                    typedef struct mps_key_s *mps_key_t;
 typedef struct mps_arg_s {
-  mps_key_t key;
+  mps_key_t key;
   union {
     int i;
     char c;
@@ -120,14 +120,14 @@ 
                    4.2. Overview
-
                    4.3. Internals
                    
+
                    5.3. Internals
                    
 
                    Internally, keys are static constant structures which are signed and contain
 a checking method for the argument, like this:
                    
 
                    typedef struct mps_arg_s *Arg;
 typedef struct mps_key_s {
   Sig sig;              /* Always KeySig */
   const char *name;
-  Bool check(Arg arg);
+  Bool check(Arg arg);
 } KeyStruct;
 
                    
 
                    
@@ -156,7 +156,7 @@ 
                    4.3. Internals
-
                    4.4. The varargs legacy
                    
+
                    5.4. The varargs legacy
                    
 
                    For backward compatibility, varargs to arena and pool creation are
 converted into keyword arguments by position, using a method in the
 arena or pool class. For example:
                    
@@ -179,12 +179,13 @@ 
                    4.4. The varargs legacy
 
                    
 
                    
-
                    4.5. References
                    
-
+
                    5.5. References
                    
+
+
+
+
+
+
                    [RB_2012-05-24]Richard Brooksby. Ravenbrook Limited. 2012-05-24. “Keyword and optional arguments”.
                    
 
                    
 
                    
 
@@ -199,22 +200,22 @@ 
                    4.5. ReferencesTable Of Contents
                    
   
                      
-
                    • 4. Keyword arguments in the MPS
 
   
                      Previous topic
                      
-  
                      3. Transliterating the alphabet into hexadecimal
                      
+  
                      4. C Style – formatting
                      
   
                      Next topic
                      
   
                      5. Ring data structure
                      Downloads
                      
+                        title="next chapter">6. Ring data structure
                      Downloads
                      
 
 
                      
 MPS Kit release 1.111.0
                      
@@ -240,10 +241,10 @@ 
                      Navigation
                      
           index
                      • 
         
                    • 
-          next |
                      • 
         
                    • 
-          previous |
                      • 
         
                    • Memory Pool System 1.111.0 documentation »
                      • 
           
                    • Design »
                      •  
diff --git a/mps/manual/html/design/lib.html b/mps/manual/html/design/lib.html
new file mode 100644
index 00000000000..2f06085c540
--- /dev/null
+++ b/mps/manual/html/design/lib.html
@@ -0,0 +1,197 @@
+
+
+
+
+
+
+  
+    
+    
+    14. Library interface — Memory Pool System 1.111.0 documentation
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+     
+  
+  
+    
                      
+      
                      Navigation
                      
+      
+    
                        
+
+    
                      
+      
                      
+        
                      
+          
                      
+            
+  
                      
+
                      14. Library interface
                      
+
                      
+
                      14.1. Introduction
                      
+
                      .intro: This document is the design of the MPS Library Interface, a
+part of the plinth.
                      
+
                      .readership: Any MPS developer. Any clients that are prepared to
+read this in order to get documentation.
                      
+
                      
+
                      
+
                      14.2. Goals
                      
+
                      .goal: The goals of the MPS library interface are:
                      
+
                      .goal.host: To control the dependency of the MPS on the hosted ISO
+C library so that the core MPS remains freestanding (see
+design.mps.exec-env).
                      
+
                      .goal.free: To allow the core MPS convenient access to ISO C
+functionality that is provided on freestanding platforms (see
+design.mps.exec-env.std.com.free).
                      
+
                      
+
                      
+
                      14.3. Description
                      
+
                      
+
                      14.3.1. Overview
                      
+
                      .overview.access: The core MPS needs to access functionality that
+could be provided by an ISO C hosted environment.
                      
+
                      .overview.hosted: The core MPS must not make direct use of any
+facilities in the hosted environment (design.mps.exec-env). However,
+it is sensible to make use of them when the MPS is deployed in a
+hosted environment.
                      
+
                      .overview.hosted.indirect: The core MPS does not make any direct
+use of hosted ISO C library facilities. Instead, it indirects through
+the MPS Library Interface, impl.h.mpslib.
                      
+
                      .overview.free: The core MPS can make direct use of freestanding
+ISO C library facilities and does not need to include any of the
+header files <limits.h>, <stdarg.h>, and <stddef.h>
+directly.
                      
+
                      .overview.complete: The MPS Library Interface can be considered as
+the complete “interface to ISO” (in that it provides direct access to
+facilities that we get in a freestanding environment and equivalents
+of any functionality we require from the hosted environment).
                      
+
                      .overview.provision.client: In a freestanding environment the
+client is expected to provide functions meeting this interface to the
+MPS.
                      
+
                      .overview.provision.hosted: In a hosted environment,
+impl.c.mpsliban may be used. It just maps impl.h.mpslib directly onto
+the ISO C library equivalents.
                      
+
                      [missing diagram]
                      
+
                      
+
                      
+
                      14.3.2. Outside the interface
                      
+
                      We provide impl.c.mpsliban to the client, for two reasons:
                      
+
                        
+
                      1. the client can use it to connect the MPS to the ISO C library if it
+exists;
                        2. 
+
                      2. as an example implementation of the MPS Library Interface.
                        3. 
+
                      
+
                      
+
                      
+
                      
+
                      14.4. Implementation
                      
+
                      .impl: The MPS Library Interface comprises a header file
+impl.h.mpslib and some documentation.
                      
+
                      .impl.decl: The header file defines the interface to definitions
+which parallel those parts of the non-freestanding ISO headers which
+are used by the MPS.
                      
+
                      .impl.include: The header file also includes the freestanding
+headers <limits.h>, <stdarg.h>, and <stddef.h> (and not
+<float.h>, though perhaps it should).
                      
+
                      
+
                      
+
+
+          
                      
+        
                      
+      
                      
+      
                      
+        
                      
+            
+  
                      Table Of Contents
                      
+  
+
+  
                      Previous topic
                      
+  
                      13. I/O subsystem
                      
+  
                      Next topic
                      
+  
                      15. The lock module
                      Downloads
                      
+
+
                      
+MPS Kit release 1.111.0
                      
+All MPS Kit releases
+
                      
+
+
                      Issues
                      
+
+
                      
+Known issues
                      
+Issues fixed in release 1.111.0
+
                      Contact us
                      
+
+
                      mps-questions@ravenbrook.com
                      
+        
                      
+      
                      
+      
                      
+    
                      
+    
                      
+      
                      Navigation
                      
+      
+    
                      
+    
                      
+        © Copyright 2013, Ravenbrook Limited.
+      Created using Sphinx 1.1.3.
+    
                      
+  
+
\ No newline at end of file
diff --git a/mps/manual/html/design/lock.html b/mps/manual/html/design/lock.html
index 5ca8687c8aa..59b77ecf36b 100644
--- a/mps/manual/html/design/lock.html
+++ b/mps/manual/html/design/lock.html
@@ -8,7 +8,7 @@
   
     
     
-    9. The lock module — Memory Pool System 1.111.0 documentation
+    15. The lock module — Memory Pool System 1.111.0 documentation
     
     
     
@@ -28,8 +28,8 @@
     
     
     
-    
-     
+    
+     
   
   
     
                      
@@ -39,10 +39,10 @@ 
                      Navigation
                      
           index
         
                    • 
-          next |
                      • 
         
                    • 
-          previous |
                      • 
         
                    • Memory Pool System 1.111.0 documentation »
                      • 
           
                    • Old design »
                      •  
@@ -54,10 +54,10 @@ 
                      Navigation
                      
         
                      
           
                      
             
-  
                      
-
                      9. The lock module
                      
+  
                      
+
                      15. The lock module
                      
 
                      
-
                      9.1. Purpose
                      
+
                      15.1. Purpose
                      
 
                      .purpose: Support the locking needs of the thread-safe design. In
 particular:
                      
 
                        
@@ -77,7 +77,7 @@ 
                        Navigation
                        
 be necessary anyway for the global recursive lock.
                        
 
                      
 
                      
-
                      9.2. Background
                      
+
                      15.2. Background
                      
 
                      .need: In an environment where multiple threads are accessing
 shared data. The threads which access data which is shared with other
 threads need to cooperate with those threads to maintain consistency.
@@ -95,7 +95,7 @@ 
                      9.2. Background
-
                      9.3. Overview
                      
+
                      15.3. Overview
                      
 
                      .adt: There is an abstract datatype Lock which points to a
 locking structure LockStruct. This structure is opaque to any
 client, although an interface is provided to supply the size of the
@@ -123,7 +123,7 @@ 
                      9.3. Overview
-
                      9.4. Detailed design
                      
+
                      15.4. Detailed design
                      
 
                      .interface: The interface comprises the following functions:
                      
 
                      
 
                      
@@ -247,21 +247,21 @@ 
                      9.4. Detailed designTable Of Contents
                      
   
                        
-
                      • 9. The lock module
 
   
                        Previous topic
                        
-  
                        8. The generic fix function
                        
+  
                        14. Library interface
                        
   
                        Next topic
                        
-  
                        10. Client message protocol
                        Downloads
                        
+  
                        16. MPS Configuration
                        Downloads
                        
 
 
                        
 MPS Kit release 1.111.0
                        
@@ -287,10 +287,10 @@ 
                        Navigation
                        
           index
                        • 
         
                      • 
-          next |
                        • 
         
                      • 
-          previous |
                        • 
         
                      • Memory Pool System 1.111.0 documentation »
                        • 
           
                      • Old design »
                        •  
diff --git a/mps/manual/html/design/locus.html b/mps/manual/html/design/locus.html
new file mode 100644
index 00000000000..5ee7f2337e4
--- /dev/null
+++ b/mps/manual/html/design/locus.html
@@ -0,0 +1,715 @@
+
+
+
+
+
+
+  
+    
+    
+    16. MPS Configuration — Memory Pool System 1.111.0 documentation
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+     
+  
+  
+    
                        
+      
                        Navigation
                        
+      
+    
                          
+
+    
                        
+      
                        
+        
                        
+          
                        
+            
+  
                        
+
                        16. MPS Configuration
                        
+
                        
+
                        16.1. Introduction
                        
+
                        .intro: The locus manager coordinates between the pools and takes
+the burden of having to be clever about tract/group placement away
+from the pools, preserving trace differentiability and contiguity
+where appropriate.
                        
+
                        .source: mail.gavinm.1998-02-05.17-52(0), mail.ptw.1998-02-05.19-53(0),
+mail.pekka.1998-02-09.13-58(0), and mail.gavinm.1998-02-09.14-05(0).
                        
+
                        .readership: Any MPS developer.
                        
+
                        
+
                        
+
                        16.2. Overview
                        
+
                        The MPS manages three main resources:
                        
+
                          
+
                        1. storage;
                          2. 
+
                        2. address space;
                          3. 
+
                        3. time.
                          4. 
+
                        
+
                        The locus manager manages address space at the arena level.
                        
+
                        When a pool wants some address space, it expresses some preferences to
+the locus manager. The locus manager and the arena (working together)
+try to honour these preferences, and decide what address space the
+pool gets.
                        
+
                        Preferences are expressed by the SegPref argument to
+SegAlloc(). Note that, when they call SegAlloc(), pools are
+asking for address space and writeable storage simultaneously, in a
+single call. There is currently no way for pools to reserve address
+space without requesting storage.
                        
+
                        
+
                        16.2.1. Why is it important to manage address space?
                        
+
                          
+
                        1. Trace differentiability
                          
+
                          Carefully chosen addresses are used by reference tracing systems
+(ie. automatic pools), to categorise objects into clumps; and to
+summarise and cheaply find references between clumps.
                          
+
                          Different clumps will become worth collecting at different times
+(the classic example, of course, is generations in a generational
+collector). For these partial collections to be efficient, it must
+be cheap to keep these clumps differentiable, cheap to condemn
+(Whiten) a particular clump, and cheap to find a good conservative
+approximation to all inward references to a clump (both initially
+to construct the Grey set, and to make scanning the Grey set
+efficient).
                          
+
                          This is what the MPS zone mechanism is all about.
                          
+
                          The locus manager manages the mapping from clumps to zones.
                          
+
                          To specify a clump, pools use the SegPrefGen argument to
+SegPrefExpress().
                          
+
                          
+
                          Note
                          
+
                          The name is misleading: generations are only one sort of clump.
+Richard Kistruck, 2007-04-24.
                          
+
                          
+
                          2. 
+
                        2. Prevent address space fragmentation (within the arena)
                          
+
                          Address space is not infinite.
                          
+
                          In some use cases, the MPS is required to remain efficient when
+using very nearly all available address space and storage. For
+example, with the client-arena class, where the only address space
+available is that of the storage available.
                          
+
                          Even with the VM arena class, typical storage sizes (as of 2007)
+can make 32-bit address space constrained: the client may need
+several gigabytes, which leaves little spare address space.
                          
+
                          Address space fragmentation incurs failure when there is no way to
+allocate a big block of address space. The big block may be
+requested via the MPS (by the client), or by something else in the
+same process, such as a third-party graphics library, image
+library, etc.
                          
+
                          Address space fragmentation incurs cost when:
                          
+
                            
+
                          • desired large-block requests (such as for buffering) are denied,
+causing them to be re-requested as a smaller block, or as several
+smaller blocks;
                            • 
+
                          • possible operating-system costs in maintaining a fragmented
+mapping?
                            • 
+
                          
+
                          3. 
+
                        3. Prevent storage fragmentation (within tracts and segments)
                          
+
                          
+
                          Storage is not infinite: it is allocated in multiples of a
+fixed-size tract. Small lonely objects, each retaining a whole
+tract, cause storage fragmentation.
                          
+
                          Non-moving pools manage this fragmentation with placement
+strategies that use:
                          
+
                            
+
                          • co-located death (in space and time);
                            • 
+
                          • segment merging and splitting.
                            • 
+
                          
+
                          These pool-level strategies always care about contiguity of object
+storage. They also often care about the ordering of addresses,
+because pool code uses an address-ordered search when choosing
+where to place a new object. For these two reasons, the address
+chosen (by the locus manager and arena) for new tracts is
+important.
                          
+
                          Certain specialised pools, and/or some client programs that use
+them, have carefully tuned segment sizes, positioning, and search
+order. Be careful: seemingly inconsequential changes can
+catastrophically break this tuning.
                          
+
                          Pools can specify a preference for High and Low ends of address
+space, which implies a search-order. Pools could also specify
+clumping, using either SegPrefGen or SegPrefZoneSet.
                          
+
                          
+
                          4. 
+
                        
+
                        
+
                        
+
                        16.2.2. Discovering the layout
                        
+
                        The locus manager is not given advance notice of how much address
+space will be required with what preferences. Instead, the locus
+manager starts with an empty layout, and adapts it as more requests
+come in over time. It is attempting to discover a suitable layout by
+successive refinement. This is ambitious.
                        
+
                        
+
                        
+
                        
+
                        16.3. Definitions
                        
+
                        .note.cohort: We use the word “cohort” in its usual sense here, but
+we’re particularly interested in cohorts that have properties relevant
+to tract placement. It is such cohorts that the pools will try to
+organize using the services of the locus manager. Typical properties
+would be trace differentiability or (en masse) death-time
+predictability. Typical cohorts would be instances of a
+non-generational pool, or generations of a collection strategy.
                        
+
                        .def.trace.differentiability: Objects (and hence tracts) that are
+collected, may or may not have “trace differentiability” from each
+other, depending on their placement in the different zones. Objects
+(or pointers to them) can also have trace differentiability (or not)
+from non-pointers in ambiguous references; in practice, we will be
+worried about low integers, that may appear to be in zones 0 or -1.
                        
+
                        
+
                        
+
                        16.4. Requirements
                        
+
                        .req.cohort: Tract allocations must specify the cohort they
+allocate in. These kind of cohorts will be called loci, and they will
+have such attributes as are implied by the other requirements.
+Critical.
                        
+
                        .req.counter.objects: As a counter-requirement, pools are expected
+to manage objects. Objects the size of a tract allocation request
+(segment-sized) are exceptional. Critical.
+.req.counter.objects.just: This means the locus manager is not
+meant to solve the problems of allocating large objects, and it isn’t
+required to know what goes on in pools.
                        
+
                        .req.contiguity: Must support a high level of contiguity within
+cohorts when requested. This means minimizing the number of times a
+cohort is made aware of discontiguity. Essential (as we’ve effectively
+renegotiated this in SW, down to a vague hope that certain critical
+cohorts are not too badly fragmented). .req.contiguity.just: TSBA.
                        
+
                        .req.contiguity.specific: It should be possible to request another
+allocation next to a specific tract on either side (or an extension in
+that direction, as the case may be). Such a request can fail, if
+there’s no space there. Nice. It would also be nice to have one for
+“next to the largest free block”.
                        
+
                        .req.differentiable: Must support the trace differentiability of
+segments that may be condemned separately. Due to the limited number
+of zones, it must be possible to place several cohorts into the same
+zone. Essential.
                        
+
                        .req.differentiable.integer: It must be possible to place
+collectable allocations so that they are trace-differentiable from
+small integers. Essential.
                        
+
                        .req.disjoint: Must support the disjointness of pages that have
+different VM properties (such as mutable/immutable,
+read-only/read-write, and different lifetimes). Optional.
                        
+
                        
+
                        Note
                        
+
                        I expect the implementation will simply work at page or larger
+granularity, so the problem will not arise, but Tucker insisted on
+stating this as a requirement. Pekka P. Pirinen, 1998-10-28.
                        
+
                        
+
                        .req.low-memory: The architecture of the locus manager must not
+prevent the design of efficient applications that often use all
+available memory. Critical. .req.low-memory.expl: This basically
+says it must be designed to perform well in low-memory conditions, but
+that there can be configurations where it doesn’t do as well, as long
+as this is documented for the application programmer. Note that it
+doesn’t say all applications are efficient, only that if you manage to
+design an otherwise efficient application, the locus manager will not
+sink it.
                        
+
                        .req.address: Must conserve address space in VM arenas to a
+reasonable extent. Critical.
                        
+
                        .req.inter-pool: Must support the association of sets of tracts in
+different pools into one cohort. Nice.
                        
+
                        .req.ep-style: Must support the existing EP-style of allocation
+whereby allocation is from one end of address space either upwards or
+downwards (or a close approximation thereto with the same behavior).
+.req.ep-style.just: We cannot risk disrupting a policy with
+well-known properties when this technology is introduced.
                        
+
                        .req.attributes: There should be a way to inform the locus manager
+about various attributes of cohorts that might be useful for
+placement: deathtime, expected total size, and so on. Optional. It’s a
+given that the cohorts must then have these attributes, within the
+limits set in the contract of the appropriate interface.
+.req.attributes.action: The locus manager should use the attributes
+to guide its placement decisions. Nice.
                        
+
                        .req.blacklisting: There should be a way of maintaining at least
+one blacklist for pages (or some other small unit), that can
+not/should not be allocated to collectable pools. Optional.
                        
+
                        
+
                        Note
                        
+
                        How to do blacklist breaking for ambiguous refs?
                        
+
                        
+
                        .req.hysteresis: There should be a way to indicate which cohorts
+fluctuate in size and by how much, to guide the arena hysteresis to
+hold on to suitable pages. Optional.
                        
+
                        
+
                        
+
                        16.5. Analysis
                        
+
                        .anal.sw: Almost any placement policy would be an improvement on
+the current SW one.
                        
+
                        .anal.cause-and-effect: The locus manager doesn’t usually need to
+know why things need to be differentiable, disjoint, contiguous, and
+so on. Abstracting the reason away from the interface makes it more
+generic, more likely to have serendipitous new uses. Attributes
+described by a quantity (deathtime, size, etc.) are an exception to
+this, because we can’t devise a common measure.
                        
+
                        .anal.stable: The strategy must be stable: it must avoid repeated
+recomputation, especially the kind that switches between alternatives
+with a short period (repeated “bites” out the same region or
+flip-flopping between two regions).
                        
+
                        .anal.fragmentation: There’s some call to avoid fragmentation in
+cohorts that don’t need strict contiguity, but this is not a separate
+requirement, since fragmentation is a global condition, and can only
+be ameliorated if there’s a global strategy that clumps allocations
+together.
                        
+
                        .anal.deathtime: Cohorts with good death-time clumping of their
+objects could use some locality of tract allocation, because it
+increases the chances of creating large holes in the address space
+(for other allocation to use). OTOH. many cohorts will not do multiple
+frees in short succession, or at least cannot reasonably be predicted
+to do so. This locality is not contiguity, nor is it low
+fragmentation, it’s just the requirement to place the new tracts next
+to the tract where the last object was allocated in the cohort. Note
+that the placement of objects is under the control of the pool, and
+the locus manager will not know it, therefore this requirement should
+be pursued by requesting allocation next to a particular tract (which
+we already have a requirement for).
                        
+
                        .anal.asymmetrical: The strategy has to be asymmetrical with
+respect to cohorts growing and shrinking. The reason of this asymmetry
+is that it can choose where to grow, but it cannot choose where to
+shrink (except in a small way by growing with good locality).
                        
+
                        
+
                        
+
                        16.6. Interface
                        
+
                        .interface.locus: A cohort will typically reside on multiple tracts
+(and the pools will avoid putting objects of other cohorts on them),
+so there should be an interface to describe the properties of the
+cohort, and associate each allocation request with the cohort. We
+shall call such an object, created to represent a cohort, a locus (pl.
+loci).
                        
+
                        .interface.locus.pool: Loci will usually be created by the pool
+that uses it. Some of the locus attributes will be inherited from
+client-specified pool attributes [this means there will be additional
+pool attributes].
                        
+
                        .interface.detail: This describes interface in overview; for
+details, see implementation section and code, or user doc.
                        
+
                        
+
                        16.6.1. Loci
                        
+
                        
+
                        
+Res LocusCreate(Locus *locusReturn, LocusAttrs attrs, ZoneGroup zg, LocusAllocDesc adesc)
                        
+
                        
+
+
                        .function.create: A function to create a locus: adesc contains
+the information about the allocation sequences in the locus, zg is
+used for zone differentiability, and attrs encodes the following:
                        
+
                          
+
                        • .locus.contiguity: A locus can be contiguous. This means
+performing as required in .req.contiguity, non-contiguous
+allocations can be freely placed anywhere (but efficiency dictates
+that similar allocations are placed close together and apart from
+others).
                          • 
+
                        • .locus.blacklist: Allocations in the locus will avoid blacklisted
+pages (for collectable segments).
                          • 
+
                        • .locus.zero: Allocations in the locus are zero-filled.
                          • 
+
                        
+
                        
+
                        Note
                        
+
                        Other attributes will be added, I’m sure.
                        
+
                        
+
                        .interface.zone-group: The locus can be made a member of a zone
+group. Passing ZoneGroupNONE means it’s not a member of any group
+(allocations will be placed without regard to zone, except to keep
+them out of stripes likely to be needed for some group).
                        
+
                        
+
                        Note
                        
+
                        I propose no mechanism for managing zone groups at this time,
+since it’s only used internally for one purpose. Pekka P. Pirinen,
+2000-01-17.
                        
+
                        
+
                        .interface.size: An allocation descriptor (LocusAllocDesc)
+contains various descriptions of how the locus will develop over time
+(inconsistent specifications are forbidden, of course):
                        
+
                          
+
                        • .interface.size.typical-alloc: Size of a typical allocation in
+this locus, in bytes. This will mainly affect the grouping of
+non-contiguous loci.
                          
+
                          • 
+
                        • .interface.size.large-alloc: Typical large allocation that the
+manager should try to allow for (this allows some relief from
+.req.counter.objects), in bytes. This will mainly affect the size
+of gaps that will be allotted adjoining this locus.
                          
+
                          • 
+
                        • 
+
                          .interface.size.direction: Direction of growth: up/down/none.
                          
+
                          Only useful if the locus is contiguous.
                          
+
                          
+
                          
+
                          • 
+
                        • .interface.size.lifetime: Some measure of the lifetime of tracts
+(not objects) in the cohort.
                          
+
                          
+
                          Note
                          
+
                          Don’t know the details yet, probably only useful for placing
+similar cohorts next to each other, so the details don’t
+actually matter. Pekka P. Pirinen, 2000-01-17.
                          
+
                          
+
                          • 
+
                        • .interface.size.deathtime: Some measure of the deathtime of
+tracts (not objects) in the cohort.
                          
+
                          
+
                          Note
                          
+
                          Ditto. Pekka P. Pirinen, 2000-01-17.
                          
+
                          
+
                          • 
+
                        
+
                        .function.init: LocusInit() is like LocusCreate(), but
+without the allocation. This is the usual interface, since most loci
+are embedded in a pool or something.
                        
+
                        .function.alloc: ArenaAlloc() to take a locus argument.
+ArenaAllocHere() is like it, plus it takes a tract and a
+specification to place the new allocation immediately above/below a
+given tract; if that is not possible, it returns ResFAIL (this
+will make it useful for reallocation functionality).
                        
+
                        
+
                        
+ArenaSetTotalLoci(Arena arena, Size nLoci, Size nZoneGroups)
                        
+
                        
+
+
                        .function.set-total: A function to tell the arena the expected
+number of (non-miscible client) loci, and of zone groups.
                        
+
                        
+
                        
+
                        16.6.2. Peaks
                        
+
                        
+
                        
+mps_res_t mps_peak_create(mps_peak_t*, mps_arena_t)
                        
+
                        
+
+
                        .function.peak.create: A function to create a peak. A newly-created
+peak is open, and will not be used to guide the strategy of the locus
+manager.
                        
+
                        
+
                        
+mps_res_t mps_peak_describe_pool(mps_peak_t, mps_pool_t, mps_size_desc_t)
                        
+
                        
+
+
                        .function.peak.add: A function to add a description of the state of
+one pool into the peak. Calling this function again for the same peak and pool instance will replace
+the earlier description.
                        
+
                        .function.peak.add.size: The size descriptor contains a total size
+in bytes or percent of arena size.
                        
+
                        
+
                        Note
                        
+
                        Is this right? Pekka P. Pirinen, 2000-01-17.
                        
+
                        
+
                        .function.peak.add.remove: Specifying a NULL size will remove
+the pool from the peak. The client is not allowed to destroy a pool
+that is mentioned in any peak; it must be first removed from the peak,
+or the peak must be destroyed. This is to ensure that the client
+adjusts the peaks in a manner that makes sense to the application; the
+locus manager can’t know how to do that.
                        
+
                        
+
                        
+mps_res_t mps_peak_close(mps_peak_t)
                        
+
                        
+
+
                        .function.peak.close: A function to indicate that all the
+significant pools have been added to the peak, and it can now be used
+to guide the locus manager. For any pool not described in the peak,
+the locus manager will take its current size at any given moment as
+the best prediction of its size at the peak.
                        
+
                        .function.peak.close.after: It is legal to add more descriptions to
+the peak after closing, but this will reopen the peak, and it will
+have to be closed before the locus manager will use it again. The
+locus manager uses the previous closed state of the peak, while this
+is going on.
                        
+
                        
+
                        
+void mps_peak_destroy(mps_peak_t)
                        
+
                        
+
+
                        .function.peak.destroy: A function to destroy a peak.
                        
+
                        .interface.ep-style: This satisfies .req.ep-style by allowing SW
+to specify zero size for most pools (which will cause them to be place
+next to other loci with the same growth direction).
                        
+
                        
+
                        Note
                        
+
                        Not sure this is good enough, but we’ll try it first. Pekka P.
+Pirinen, 2000-01-17.
                        
+
                        
+
                        
+
                        
+
                        
+
                        16.7. Architecture
                        
+
                        
+
                        16.7.1. Data objects
                        
+
                        .arch.locus: To represent the cohorts, we have locus objects.
+Usually a locus is embedded in a pool instance, but generations are
+separate loci.
                        
+
                        .arch.locus.attr: contiguity, blacklist, zg, current region, @@@@
                        
+
                        .arch.locus.attr.exceptional: The client can define a typical large
+allocation for the locus. Requests substantially larger than that are
+deemed exceptional.
                        
+
                        .arch.zone-group: To satisfy .req.condemn, we offer zone groups.
+Each locus can be a member of a zone group, and the locus manager will
+attempt to place allocations in this locus in different zones from all
+the other zone groups. A zone-group is represented as @@@@.
                        
+
                        .arch.page-table: A page table is maintained by the arena, as usual
+to track association between tracts, pools and segments, and mapping
+status for VM arenas.
                        
+
                        .arch.region: All of the address space is divided into disjoint
+regions, represented by region objects. These objects store their
+current limits, and high and low watermarks of currently allocated
+tracts (we hope there’s usually a gap of empty space between regions).
+The limits are actually quite porous and flexible.
                        
+
                        .arch.region.assoc: Each region is associated with one contiguous
+locus or any number of non-contiguous loci (or none). We call the
+first kind of region “contiguous”. .arch.locus.assoc: Each locus
+remembers all regions where it has tracts currently, excepting the
+badly-placed allocations (see below). It is not our intention that any
+locus would have very many, or that loci that share regions would have
+any reason to stop doing do.
                        
+
                        .arch.region.more: Various quantities used by the placement
+computation are also stored in the regions and the loci. Regions are
+created (and destroyed) by the placement recomputation. Regions are
+located in stripes (if it’s a zoned region), but they can extend into
+neighboring stripes if an exceptionally large tract allocation is
+requested (to allow for large objects).
                        
+
                        .arch.chunk: Arenas may allocate more address space in additional
+chunks, which may be disjoint from the existing chunks. Inter-chunk
+space will be represented by dummy regions. There are also sentinel
+regions at both ends of the address space.
                        
+
                        
+
                        
+
                        16.7.2. Overview of strategy
                        
+
                        .arch.strategy.delay: The general strategy is to delay placement
+decisions until they have to be made, but no later.
                        
+
                        .arch.strategy.delay.until: Hence, the locus manager only makes
+placement decisions when an allocation is requested (frees and other
+operations might set a flag to cause the next allocation to redecide).
+This also allows the client to change the peak and pool configuration
+in complicated ways without causing a lot of recomputation, by doing
+all the changes without allocating in the middle (unless the control
+pool needs more space because of the changes).
                        
+
                        .arch.strategy.normal: While we want the placement to be
+sophisticated, we do not believe it is worth the effort to consider
+all the data at each allocation. Hence, allocations are usually just
+placed in one of the regions used previously (see .arch.alloc)
+without reconsidering the issues.
                        
+
                        .arch.strategy.normal.limit: However, the manager sets
+precautionary limits on the regions to ensure that the placement
+decisions are revisited when an irrevocable placement is about to be
+made.
                        
+
                        .arch.strategy.create: The manager doesn’t create new regions until
+they are needed for allocation (but it might compute where they could
+be placed to accommodate a peak).
                        
+
                        
+
                        
+
                        16.7.3. Allocation
                        
+
                        .arch.alloc: Normally, each allocation to a locus is placed in its
+current region. New regions are only sought when necessary to fulfill
+an allocation request or when there is reason to think the situation
+has changed significantly (see .arch.significant).
                        
+
                        .arch.alloc.same: An allocation is first attempted next to the
+previous allocation in the same locus, respecting growth direction. If
+that is not possible, a good place in the current region is sought.
+.arch.alloc.same.hole: At the moment, for finding a good place
+within a region, we just use the current algorithm, limited to the
+region. In future, the placement within regions will be more clever.
                        
+
                        .arch.alloc.extend: If there’s no adequate hole in the current
+region and the request is not exceptional, the neighboring regions are
+examined to see if the region could be extended at one border. (This
+will basically only be done if the neighbor has shrunk since the last
+placement recomputation, because the limit was set on sophisticated
+criteria, and should not be changed without justification.)
+.arch.alloc.extend.here: When an allocation is requested next to a
+specific tract (ArenaAllocHere()), we try to extend a little
+harder (at least for change_size, perhaps not for locality).
                        
+
                        .arch.alloc.other: If no way can be found to allocate in the
+current region, other regions used for this locus are considered in
+the same way, to see if space can be found there. [Or probably look at
+other regions before trying to extend anything?]
                        
+
                        .arch.alloc.recompute: When no region of this locus has enough
+space for the request, or when otherwise required, region placement is
+recomputed to find a new region for the request (which might be the
+same region, after extension).
                        
+
                        .arch.alloc.current: This region where the allocation was placed
+then becomes the current region for this locus, except when the
+request was exceptional, or when the region chosen was “bad” (see
+@@@@).
                        
+
                        .arch.significant: Significant changes to the parameters affecting
+placement are deemed to have happened at certain client calls and when
+the total allocation has changed substantially since the last
+recomputation. Such conditions set a flag that causes the next
+allocation to recompute even if its current region is not full
+(possibly second-guess the decision to recompute after some
+investigation of the current state?).
                        
+
                        
+
                        
+
                        16.7.4. Deallocation
                        
+
                        .arch.free: Deallocation simply updates the counters in the region
+and the locus. For some loci, it will make the region of the
+deallocation the current region. .arch.free.remove: If a region
+becomes entirely empty, it is deleted (and the neighbors limits might
+be adjusted).
                        
+
                        
+
                        Note
                        
+
                        This is quite tricky to get right.
                        
+
                        
+
                        
+
                        
+
                        16.7.5. Region placement recomputation
                        
+
                        .arch.gap: When doing placement computations, we view the arena as
+a sequence of alternating region cores and gaps (which can be small,
+even zero-sized). Initially, we’ll take the core of a region to be the
+area between the high and low watermark, but in the future we might be
+more flexible about that.
                        
+
                        
+
                        Note
                        
+
                        Edge determination is actually a worthwhile direction to explore.
                        
+
                        
+
                        .arch.reach: The gap between two cores could potentially end up
+being allocated to either region, if they grow in that direction, or
+one or neither, if they don’t. The set of states that the region
+assignment could reach by assigning the gaps to their neighbors is
+called the reach of the current configuration.
                        
+
                        .arch.placement.object: The object of the recomputation is to find
+a configuration of regions that is not too far from the current
+configuration and that keeps all the peaks inside its reach; if that
+is not possible, keep the nearest ones in the reach and then minimize
+the total distance from the rest.
                        
+
                        .arch.placement.hypothetical: The configurations that are
+considered will include hypothetical placements for new regions for
+loci that cannot fit in their existing regions at the peak. This is
+necessary to avoid choosing a bad alternative.
                        
+
                        .arch.placement.interesting: The computation will only consider new
+regions of loci that are deemed interesting, that is, far from their
+peak state. This will reduce the computational burden and avoid
+jittering near a peak.
                        
+
                        
+
                        Note
                        
+
                        Details missing.
                        
+
                        
+
                        
+
                        
+
                        
+
                        16.8. Implementation
                        
+
                        [missing]
                        
+
                        
+
                        
+
                        16.9. Notes
                        
+
                        .idea.change: Even after the first segment, be prepared to change
+your mind, if by the second segment a lot of new loci have been
+created.
                        
+
                        .distance: If the current state is far from a peak, there’s time to
+reassign regions and for free space to appear (in fact, under the
+steady arena assumption, enough free space will appear).
                        
+
                        .clear-pool: Need to have a function to deallocate all objects in a
+pool, so that PoolDestroy() won’t have to be used for that
+purpose.
                        
+
                        
+
                        
+
+
+          
                        
+        
                        
+      
                        
+      
                        
+        
                        
+            
+  
                        Table Of Contents
                        
+  
+
+  
                        Previous topic
                        
+  
                        15. The lock module
                        
+  
                        Next topic
                        
+  
                        17. Client message protocol
                        Downloads
                        
+
+
                        
+MPS Kit release 1.111.0
                        
+All MPS Kit releases
+
                        
+
+
                        Issues
                        
+
+
                        
+Known issues
                        
+Issues fixed in release 1.111.0
+
                        Contact us
                        
+
+
                        mps-questions@ravenbrook.com
                        
+        
                        
+      
                        
+      
                        
+    
                        
+    
                        
+      
                        Navigation
                        
+      
+    
                        
+    
                        
+        © Copyright 2013, Ravenbrook Limited.
+      Created using Sphinx 1.1.3.
+    
                        
+  
+
\ No newline at end of file
diff --git a/mps/manual/html/design/message-gc.html b/mps/manual/html/design/message-gc.html
new file mode 100644
index 00000000000..ddcf09f3e98
--- /dev/null
+++ b/mps/manual/html/design/message-gc.html
@@ -0,0 +1,387 @@
+
+
+
+
+
+
+  
+    
+    
+    18. GC messages — Memory Pool System 1.111.0 documentation
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+     
+  
+  
+    
                        
+      
                        Navigation
                        
+      
+    
                          
+
+    
                        
+      
                        
+        
                        
+          
                        
+            
+  
                        
+
                        18. GC messages
                        
+
                        
+
                        18.1. Introduction
                        
+
                        .intro: This document describes the design of the MPS garbage
+collection messages. For a guide to the MPS message system in general,
+see design.mps.message.
                        
+
                        .readership: Any MPS developer.
                        
+
                        
+
                        
+
                        18.2. Overview
                        
+
                        The MPS provides two types of GC messages:
                        
+
+
                        They are called “trace start” and “trace end” messages in this
+document and in most MPS source code.
                        
+
                        
+
                        
+
                        18.3. Introduction
                        
+
                        The MPS posts a trace start message (mps_message_type_gc_start())
+near the start of every trace (but after calculating the condemned
+set, so we can report how large it is).
                        
+
                        The MPS posts a trace end message (mps_message_type_gc()) near the
+end of every trace.
                        
+
                        These messages are extremely flexible: they can hold arbitrary
+additional data simply by writing new accessor functions. If there is
+more data to report at either of these two events, then there is a
+good argument for adding it into these existing messages.
                        
+
                        
+
                        Note
                        
+
                        In previous versions of this design document, there was a partial
+unimplemented design for an mps_message_type_gc_generation()
+message. This would not have been a good design, because managing
+and collating multiple messages is much more complex for both MPS
+and client than using a single message. Richard Kistruck,
+2008-12-19.
                        
+
                        
+
                        
+
                        
+
                        18.4. Purpose
                        
+
                        .purpose: The purpose of these messages is to allow the client
+program to be aware of GC activity, in order to:
                        
+
                          
+
                        • adjust its own behaviour programmatically;
                          • 
+
                        • show or report GC activity in a custom way, such as an in-client
+display, in a log file, etc.
                          • 
+
                        
+
                        The main message content should be intelligible and helpful to
+client-developers (with help from MPS staff if necessary). There may
+be extra content that is only meaningful to MPS staff, to help us
+diagnose client problems.
                        
+
                        While there is some overlap with the Diagnostic Feedback system
+(design.mps.diag), the main contrasts are that these GC messages are
+present in release builds, are stable from release to release, and are
+designed to be parsed by the client program.
                        
+
                        
+
                        
+
                        18.5. Names and parts
                        
+
                        Here’s a helpful list of the names used in the GC message system:
                        
+
                        Implementation is mostly in the source file traceanc.c (trace
+ancillary).
                        
+
+++++
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                        




                        Internal name“trace start”“trace end”
                        Internal typeTraceStartMessageTraceMessage
                        ArenaStruct membertsMessage[]tMessage
                        Message typeMessageTypeGCSTARTMessageTypeGC
                        External namemps_message_type_gc_startmps_message_type_gc
                        
+
                        
+
                        Note
                        
+
                        The names of these messages are unconventional; they should
+properly be called “gc (or trace) begin” and “gc (or trace)
+end”. But it’s much too late to change them now. Richard
+Kistruck, 2008-12-15.
                        
+
                        
+
                        Collectively, the trace-start and trace-end messages are called the
+“trace id messages”, and they are managed by the functions
+TraceIdMessagesCheck(), TraceIdMessagesCreate(), and TraceIdMessagesDestroy().
                        
+
                        The currently supported message-field accessor methods are:
+mps_message_gc_start_why(), mps_message_gc_live_size(),
+mps_message_gc_condemned_size(), and
+mps_message_gc_not_condemned_size(). These are documented in the
+Reference Manual.
                        
+
                        
+
                        
+
                        18.6. Lifecycle
                        
+
                        .lifecycle: for each trace id, pre-allocate a pair of start/end
+messages by calling ControlAlloc(). Then, when a trace runs using
+that trace id, fill in and post these messages. As soon as the trace
+has posted both messages, immediately pre-allocate a new pair of
+messages, which wait in readiness for the next trace to use that
+trace id.
                        
+
                        
+
                        18.6.1. Requirements
                        
+
                        .req.no-start-alloc: Should avoid attempting to allocate memory at
+trace start time. .req.no-start-alloc.why: There may be no free
+memory at trace start time. Client would still like to hear about
+collections in those circumstances.
                        
+
                        .req.queue: Must support a client that enables, but does not
+promptly retrieve, GC messages. Messages that have not yet been
+retrived must remain queued, and the client must be able to retrieve
+them later without loss. It is not acceptable to stop issuing GC
+messages for subsequent collections merely because messages from
+previous collections have not yet been retrieved. .req.queue.why:
+This is because there is simply no reasonable way for a client to
+guarantee that it always promptly collects GC messages.
                        
+
                        .req.match: Start and end messages should always match up: never
+post one of the messages but fail to post the matching one.
                        
+
                        .req.match.why: This makes client code much simpler – it does not
+have to handle mismatching messages.
                        
+
                        .req.errors-not-direct: Errors (such as a ControlAlloc()
+failure) cannot be reported directly to the client, because
+collections often happen automatically, without an explicit client
+call to the MPS interface.
                        
+
                        .req.multi-trace: Up to TraceLIMIT traces may be running, and
+emitting start/end messages, simultaneously.
                        
+
                        .req.early: Nice to tell client as much as possible about the
+collection in the start message, if we can.
                        
+
                        .req.similar: Start and end messages are conceptually similar – it
+is quite okay, and may be helpful to the client, for the same datum
+(for example: the reason why the collection occurred) to be present in
+both the start and end message.
                        
+
                        
+
                        
+
                        18.6.2. Storage
                        
+
                        For each trace-id (.req.multi-trace) a pair (.req.match) of
+start/end messages is dynamically allocated (.req.queue) in advance
+(.req.no-start-alloc). Messages are allocated in the control pool
+using ControlAlloc().
                        
+
                        
+
                        Note
                        
+
                        Previous implementations of the trace start message used static
+allocation. This does not satisfy .req.queue. See also
+job001570. Richard Kistruck, 2008-12-15.
                        
+
                        
+
                        Poiters to these messages are stored in tsMessage[ti] and
+tMessage[ti] arrays in the ArenaStruct.
                        
+
                        
+
                        Note
                        
+
                        We must not> keep the pre-allocated messages, or pointers to them,
+in TraceStruct: the memory for these structures is statically
+allocated, but the values in them are re-initialised by
+TraceCreate() each time the trace id is used, so the
+TraceStruct() is invalid (that is: to be treated as random
+uninitialised memory) when not being used by a trace. See also
+job001989. Richard Kistruck, 2008-12-15.
                        
+
                        
+
                        
+
                        
+
                        18.6.3. Creating and Posting
                        
+
                        In ArenaCreate() we use TRACE_SET_ITER to initialise the
+tsMessage[ti] and tMessage[ti] pointers to NULL, and then
+(when the control pool is ready) TRACE_SET_ITER calling
+TraceIdMessagesCreate(). This performs the initial pre-allocation
+of the trace start/end messages for each trace id. Allocation failure
+is not tolerated here: it makes ArenaCreate() fail with an error
+code, because the arena is deemed to be unreasonably small.
                        
+
                        When a trace is running using trace id ti, it finds a
+pre-allocated message via tsMessage[ti] or tMessage[ti] in the
+ArenaStruct(), fills in and posts the message, and nulls-out the
+pointer. (If the pointer was null, no message is sent; see below.) The
+message is now reachable only from the arena message queue (but the
+control pool also knows about it).
                        
+
                        When the trace completes, it calls TraceIdMessagesCreate() for its
+trace id. This performs the ongoing pre-allocation of the trace
+start/end messages for the next use of this trace id. The expectation
+is that, after a trace has completed, some memory will have been
+reclaimed, and the ControlAlloc() will succeed.
                        
+
                        But allocation failure here is permitted: if it happens, both the
+start and the end messages are freed (if present). This means that,
+for the next collection using this trace id, neither a start nor an
+end message will be sent (.req.match). There is no direct way to
+report this failure to the client (.req.errors-not-direct), so we
+just increment the droppedMessages counter in the ArenaStruct.
+Currently this counter is never reported to the client (except in
+diagnostic varieties).
                        
+
                        
+
                        
+
                        18.6.4. Getting and discarding
                        
+
                        If the client has not enabled that message type, the message is
+discarded immediately when posted, calling ControlFree() and
+reclaiming the memory.
                        
+
                        If the client has enabled but never gets the message, it remains on
+the message queue until ArenaDestroy(). Theoretically these
+messages could accumulate forever until they exhaust memory. This is
+intentional: the client should not enable a message type and then
+never get it!
                        
+
                        Otherwise, when the client gets a message, it is dropped from the
+arena message queue: now only the client (and the control pool) hold
+references to it. The client must call mps_message_discard() once
+it has finished using the message. This calls ControlFree() and
+reclaims the memory.
                        
+
                        If the client simply drops its reference, the memory will not be
+reclaimed until ArenaDestroy(). This is intentional: the control
+pool is not garbage-collected.
                        
+
                        
+
                        
+
                        18.6.5. Final clearup
                        
+
                        Final clearup is performed at ArenaDestroy(), as follows:
                        
+
                          
+
                        • Unused and unsent pre-allocated messages (one per trace id) are
+freed with TRACE_SET_ITER calling TraceIdMessagesDestroy()
+which calls the message Delete functions (and thereby
+ControlFree()) on anything left in tsMessage[ti] and
+tMessage[ti].
                          • 
+
                        • Unretrieved messages are freed by emptying the arena message queue
+with MessageEmpty().
                          • 
+
                        • Retrieved but undiscarded messages are freed by destroying the
+control pool.
                          • 
+
                        
+
                        
+
                        
+
                        
+
                        18.7. Testing
                        
+
                        The main test is “zmess.c”. See notes there.
                        
+
                        Various other tests, including amcss.c, also collect and report
+mps_message_type_gc() and mps_message_type_gc_start().
                        
+
                        
+
                        18.7.1. Coverage
                        
+
                        Current tests do not check:
                        
+
                          
+
                        • The less common why-codes (reasons why a trace starts). These should
+be added to zmess.c.
                          • 
+
                        
+
                        
+
                        
+
                        
+
+
+          
                        
+        
                        
+      
                        
+      
                        
+        
                        
+            
+  
                        Table Of Contents
                        
+  
+
+  
                        Previous topic
                        
+  
                        17. Client message protocol
                        
+  
                        Next topic
                        
+  
                        19. Debugging features for client objects
                        Downloads
                        
+
+
                        
+MPS Kit release 1.111.0
                        
+All MPS Kit releases
+
                        
+
+
                        Issues
                        
+
+
                        
+Known issues
                        
+Issues fixed in release 1.111.0
+
                        Contact us
                        
+
+
                        mps-questions@ravenbrook.com
                        
+        
                        
+      
                        
+      
                        
+    
                        
+    
                        
+      
                        Navigation
                        
+      
+    
                        
+    
                        
+        © Copyright 2013, Ravenbrook Limited.
+      Created using Sphinx 1.1.3.
+    
                        
+  
+
\ No newline at end of file
diff --git a/mps/manual/html/design/message.html b/mps/manual/html/design/message.html
index 637fb5bc0cb..5223019b610 100644
--- a/mps/manual/html/design/message.html
+++ b/mps/manual/html/design/message.html
@@ -8,7 +8,7 @@
   
     
     
-    10. Client message protocol — Memory Pool System 1.111.0 documentation
+    17. Client message protocol — Memory Pool System 1.111.0 documentation
     
     
     
@@ -28,8 +28,8 @@
     
     
     
-    
-     
+    
+     
   
   
     
                        
@@ -39,10 +39,10 @@ 
                        Navigation
                        
           index
         
                      • 
-          next |
                        • 
         
                      • 
-          previous |
                        • 
         
                      • Memory Pool System 1.111.0 documentation »
                        • 
           
                      • Old design »
                        •  
@@ -54,10 +54,10 @@ 
                        Navigation
                        
         
                        
           
                        
             
-  
                        
-
                        10. Client message protocol
                        
+  
                        
+
                        17. Client message protocol
                        
 
                        
-
                        10.1. Introduction
                        
+
                        17.1. Introduction
                        
 
                        .intro: The client message protocol provides a means by which
 clients can receive messages from the MPS asynchronously. Typical
 messages may be low memory notification (or in general low utility),
@@ -66,8 +66,12 @@ 
                        Navigation
                        
 to ignore messages, but that it is probably in the clients best
 interest to not ignore messages. The justification for this is that
 the MPS cannot force the MPS client to read and act on messages, so no
-message should be critical [bogus, since we cannot force clients to
-check error codes either - Pekka 1997-09-17].
                        
+message should be critical.
                        
+
                        
+
                        Note
                        
+
                        Bogus, since we cannot force clients to check error codes either.
+Pekka P. Pirinen, 1997-09-17.
                        
+
                        
 
                        .contents: This document describes the design of the external and
 internal interfaces and concludes with a sketch of an example design
 of an internal client. The example is that of implementing
@@ -75,19 +79,19 @@ 
                        Navigation
                        
 
                        .readership: Any MPS developer.
                        
 
                        
 
                        
-
                        10.2. Requirements
                        
+
                        17.2. Requirements
                        
 
                        .req: The client message protocol will be used for implementing
 finalization (see design.mps.finalize and req.dylan.fun.final). It
 will also be used for implementing the notification of various
 conditions (possibly req.dylan.prot.consult is relevant here).
                        
 
                        
 
                        
-
                        10.3. External interface
                        
+
                        17.3. External interface
                        
 
                        .if.queue: Messages are presented as a single queue per arena.
 Various functions are provided to inspect the queue and inspect
 messages in it (see below).
                        
 
                        
-
                        10.3.1. Functions
                        
+
                        17.3.1. Functions
                        
 
                        .if.fun: The following functions are provided:
                        
 
                        .if.fun.poll: mps_message_poll() sees whether there are any
 messages pending. Returns 1 only if there is a message on the queue of
@@ -136,7 +140,7 @@ 
                        10.3.1. Functionsmps_message_get().
                        
 
                        
 
                        
-
                        10.3.2. Types of messages
                        
+
                        17.3.2. Types of messages
                        
 
                        .type: The type governs the “shape” and meaning of the message.
                        
 
                        .type.int: Types themselves will just be a scalar quantity, an
 integer.
                        
@@ -159,7 +163,7 @@ 
                        10.3.2. Types of messages
 
                        
 
                        
-
                        10.3.3. Compatibility issues
                        
+
                        17.3.3. Compatibility issues
                        
 
                        .compatibility: The following issues affect future compatibility of
 the interface:
                        
 
                        .compatibility.future.type-new: Notice that message of a type that
@@ -175,9 +179,9 @@ 
                        10.3.3. Compatibility issues
-
                        10.4. Internal interface
                        
+
                        17.4. Internal interface
                        
 
                        
-
                        10.4.1. Types
                        
+
                        17.4.1. Types
                        
 
                        
 
                        
 struct MessageStruct *Message
                        
@@ -291,7 +295,7 @@ 
                        10.4.1. Types
-
                        10.4.2. Functions
                        
+
                        17.4.2. Functions
                        
 
                        
 
                        
 void MessageInit(Arena arena, Message message, MessageClass class)
                        
@@ -334,7 +338,7 @@ 
                        10.4.2. Functions
-
                        10.5. Message life cycle
                        
+
                        17.5. Message life cycle
                        
 
                        .life: A message will be allocated by a client of the message
 module, it will be initialised by calling MessageInit(). The
 client will eventually post the message on the external queue (in fact
@@ -344,11 +348,14 @@ 
                        10.5. Message life cycledelete method to it.
                        
 
                        
 
                        
-
                        10.6. Examples
                        
+
                        17.6. Examples
                        
 
                        
-
                        10.6.1. Finalization
                        
-
                        [possibly out of date, see design.mps.finalize and design.mps.poolmrg
-instead – drj 1997-08-28]
                        
+
                        17.6.1. Finalization
                        
+
                        
+
                        Note
                        
+
                        Possibly out of date, see design.mps.finalize and
+design.mps.poolmrg instead. David Jones, 1997-08-28.
                        
+
                        
 
                        This subsection is a sketch of how PoolMRG will use Messages for
 finalization (see design.mps.poolmrg).
                        
 
                        PoolMRG has guardians (see design.mps.poolmrg.guardian). Guardians are
@@ -379,23 +386,23 @@ 
                        10.6.1. FinalizationTable Of Contents
                        
   
                          
-
                        • 10. Client message protocol
                            
-
                          • 10.1. Introduction
                            • 
-
                          • 10.2. Requirements
                            • 
-
                          • 10.3. External interface
                              
-
                            • 10.3.1. Functions
                              • 
-
                            • 10.3.2. Types of messages
                              • 
-
                            • 10.3.3. Compatibility issues
                              • 
+
                            • 17. Client message protocol
                                
+
                              • 17.1. Introduction
                                • 
+
                              • 17.2. Requirements
                                • 
+
                              • 17.3. External interface
 
                                • 
-
                              • 10.4. Internal interface
 
   
                                Previous topic
                                
-  
                                9. The lock module
                                
+  
                                16. MPS Configuration
                                
   
                                Next topic
                                
-  
                                11. Debugging features for client objects
                                Downloads
                                
+  
                                18. GC messages
                                Downloads
                                
 
 
                                
 MPS Kit release 1.111.0
                                
@@ -433,10 +440,10 @@ 
                                Navigation
                                
           index
                                • 
         
                              • 
-          next |
                                • 
         
                              • 
-          previous |
                                • 
         
                              • Memory Pool System 1.111.0 documentation »
                                • 
           
                              • Old design »
                                •  
diff --git a/mps/manual/html/design/object-debug.html b/mps/manual/html/design/object-debug.html
index d18235fde55..d684197a658 100644
--- a/mps/manual/html/design/object-debug.html
+++ b/mps/manual/html/design/object-debug.html
@@ -8,7 +8,7 @@
   
     
     
-    11. Debugging features for client objects — Memory Pool System 1.111.0 documentation
+    19. Debugging features for client objects — Memory Pool System 1.111.0 documentation
     
     
     
@@ -28,8 +28,8 @@
     
     
     
-    
-     
+    
+     
   
   
     
                                
@@ -39,10 +39,10 @@ 
                                Navigation
                                
           index
         
                              • 
-          next |
                                • 
         
                              • 
-          previous |
                                • 
         
                              • Memory Pool System 1.111.0 documentation »
                                • 
           
                              • Old design »
                                •  
@@ -54,25 +54,29 @@ 
                                Navigation
                                
         
                                
           
                                
             
-  
                                
-
                                11. Debugging features for client objects
                                
+  
                                
+
                                19. Debugging features for client objects
                                
 
                                
-
                                11.1. Introduction
                                
+
                                19.1. Introduction
                                
 
                                .intro: This is the design for all the various debugging features
 that MPS clients (and sometimes MPS developers) can use to discover
 what is happening to their objects and the memory space.
                                
 
                                .readership: MPS developers.
                                
 
                                
 
                                
-
                                11.2. Overview
                                
+
                                19.2. Overview
                                
 
                                .over.fenceposts: In its current state, this document mostly talks
 about fenceposts, straying a little into tagging where theses features
-have an effect on each other. [There exist other documents that list
-other required features, and propose interfaces and implementations.
-These will eventually be folded into this one. pekka 1998-09-10]
                                
+have an effect on each other.
                                
+
                                
+
                                Note
                                
+
                                There exist other documents that list other required features, and
+propose interfaces and implementations. These will eventually be
+folded into this one. Pekka P. Pirinen, 1998-09-10.
                                
+
                                
 
                                
 
                                
-
                                11.3. Requirements
                                
+
                                19.3. Requirements
                                
 
                                .req.fencepost: Try to detect overwrites and underwrites of
 allocated blocks by adding fenceposts (source req.product.??? VC++,
 req.epcore.fun.debug.support).
                                
@@ -93,14 +97,17 @@ 
                                11.3. Requirements.req.tag.walk: The walking function (as required by .req.walk)
 should have access to this data (source req.epcore.fun.debug.support).
                                
 
                                .req.dump.aver: It must be possible to perform a memory dump after
-an AVER() has fired (naturally, if the information required for the
-dump has been corrupted, it will fail, as softly as possible). (source
-@@@@)
                                
-
                                [There are more, especially about memory dumps and allocation
-locations. pekka 1998-09-10]
                                
+an AVER() has fired. Naturally, if the information required for
+the dump has been corrupted, it will fail, as softly as possible
+(source @@@@).
                                
+
                                
+
                                Note
                                
+
                                There are more requirements, especially about memory dumps and
+allocation locations. Pekka P. Pirinen, 1998-09-10.
                                
+
                                
 
                                
 
                                
-
                                11.4. Solution ideas
                                
+
                                19.4. Solution ideas
                                
 
                                .note.assumptions: I’ve tried not to assume anything about the
 coincidence of manual/automatic, formatted/unformatted, and
 ap/mps_alloc. I think those questions deserve to be decided on their
@@ -121,7 +128,7 @@ 
                                11.4. Solution ideas.fence.ap: AP’s could support fenceposting transparently by having
 a mode where mps_reserve() always goes out-of-line and fills in the
-fenceposts (the pool’s BufferFill() method isn’t involved). This
+fenceposts (the pool’s BufferFill() method isn’t involved). This
 would leave the MPS with more freedom of implementation, especially
 when combined with some of the other ideas. We think doing a function
 call for every allocation is not too bad for debugging.
                                
@@ -199,9 +206,12 @@ 
                                11.4. Solution ideas.fence.wrapper.alloc.size: We could just communicate the size of
 the fenceposts between the format and the allocation routines, but
-then you couldn’t use variable fenceposts (.fence.wrapper.variable).
-[All this applies to copying and reclaim in a straight-forward manner,
-I think.]
                                
+then you couldn’t use variable fenceposts (.fence.wrapper.variable).
                                
+
                                
+
                                Note
                                
+
                                All this applies to copying and reclaim in a straight-forward
+manner, I think.
                                
+
                                
 
                                .fence.pool.wrapper: Pools can be wrapped as well. This could be a
 natural way to represent/implement the fenceposting changes to the
 Alloc and Free methods. [@@@@alignment]
                                
@@ -223,7 +233,7 @@ 
                                11.4. Solution ideas
-
                                11.5. Architecture
                                
+
                                19.5. Architecture
                                
 
                                .pool: The implementation is at the pool level, because pools
 manage allocated objects. A lot of the code will be generic,
 naturally, but the data structures and the control interfaces attach
@@ -244,7 +254,12 @@ 
                                11.5. Architecture
+
                                Note
                                
+
                                This part has not been implemented yet Pekka P. Pirinen,
+1998-09-10.
                                
+
                                
 
                                .init: It simplifies the implementation of both tagging and
 fenceposting if they are always on, so that we don’t have to keep
 track of which objects have been fenceposted and which have not, and
@@ -256,29 +271,42 @@ 
                                11.5. Architecture.modularity: While a combined generic implementation of tags and
 fenceposts is provided, it is structured so that each part of it could
 be implemented by a pool-specific mechanism with a minimum of new
-protocol. [This will be improved, when we figure out formatted pools
-– they don’t need tags for fenceposting.]
                                
+protocol.
                                
+
                                
+
                                Note
                                
+
                                This will be improved, when we figure out formatted pools – they
+don’t need tags for fenceposting.
                                
+
                                
 
                                .out-of-space: If there’s no room for tags, we will not dip into
 the reservoir, just fail to allocate the tag. If the alloc call had a
 reservoir permit, we let it succeed even without a tag, and just make
 sure the free method will not complain if it can’t find a tag. If the
 call didn’t have a reservoir permit, we free the block allocated for
 the object and fail the allocation, so that the client gets a chance
-to do whatever low-memory actions they might want to do. [Should this
-depend on whether there is anything in the reservoir?] This breaks the
-one-to-one relationship between tags and objects, so some checks
-cannot be made, but we do count the “lost” tags.
                                
-
                                [need to hash out how to do fenceposting in formatted pools]
                                
+to do whatever low-memory actions they might want to do.
                                
+
                                
+
                                Note
                                
+
                                Should this depend on whether there is anything in the reservoir?
                                
+
                                
+
                                This breaks the one-to-one relationship between tags and objects, so
+some checks cannot be made, but we do count the “lost” tags.
                                
+
                                
+
                                Note
                                
+
                                Need to hash out how to do fenceposting in formatted pools.
                                
+
                                
 
                                
 
                                
-
                                11.6. Client interface
                                
+
                                19.6. Client interface
                                
 
                                .interface.fenceposting.check:
 mps_pool_check_fenceposts() is a function to check all
 fenceposts in a pool (AVER() if a problem is found)
                                
-
                                [from here on, these are tentative and incomplete]
                                
+
                                
+
                                Note
                                
+
                                From here on, these are tentative and incomplete.
                                
+
                                
 
                                
 
                                
-mps_res_t mps_fmt_fencepost_wrap(mps_fmt_t *format_return, mps_arena_t arena, mps_fmt_t format, [fp parameters])
                                
+mps_res_t mps_fmt_fencepost_wrap(mps_fmt_t *format_return, mps_arena_t arena, mps_fmt_t format, ...)
                      
 
                      
 
 
                      .interface.fenceposting.format: A function to wrap a format
@@ -296,15 +324,15 @@ 
                      11.6. Client interface.interface.fenceposting.add: A format method to add a fencepost
-around a block about to be allocated [the NULL method adds a tail
-fencepost]
                      
+around a block about to be allocated. The NULL method adds a tail
+fencepost.
                      
 
                      
 
                      
 mps_bool_t (*mps_fmt_check_fenceposts_t)(mps_addr_t)
                      
 
                      
 
 
                      .interface.fenceposting.checker: A format method to check the
-fenceposts around an object [the NULL method checks tails].
                      
+fenceposts around an object. The NULL method checks tails.
                      
 
                      
 
                      
 mps_class_t mps_debug_class(mps_class_t class)
                      
@@ -339,7 +367,7 @@ 
                      11.6. Client interface
-
                      11.7. Examples
                      
+
                      19.7. Examples
                      
 
                      .example.debug-alloc:
                      
 
                      #define MPS_ALLOC_DBG(res_io, addr_io, pool, size)
   MPS_BEGIN
@@ -351,13 +379,17 @@ 
                      11.7. Examples
-
                      11.8. Implementation
                      
+
                      19.8. Implementation
                      
 
                      .new-pool: The client interface to control fenceposting
 consists of the new classes mps_pool_class_mv_debug(),
 mps_pool_class_epdl_debug(), and
 mps_pool_class_epdr_debug(), and their new init parameter of
-type mps_pool_debug_option_s. [This is a temporary solution,
-to get it out without writing lots of new interface. pekka 1998-09-10]
                      
+type mps_pool_debug_option_s.
                      
+
                      
+
                      Note
                      
+
                      This is a temporary solution, to get it out without writing lots
+of new interface. Pekka P. Pirinen, 1998-09-10.
                      
+
                      
 
                      .new-pool.impl: The debug pools are implemented using the “class
 wrapper” EnsureDebugClass(), which produces a subclass with
 modified init, finish, alloc, and free methods. These
@@ -374,7 +406,11 @@ 
                      11.8. Implementation
+
                      Note
                      
+
                      Lots more should be said, eventually. Pekka P. Pirinen,
+1998-09-10.
                      
+
                      
 
                      
 
                      
 
@@ -389,25 +425,25 @@ 
                      11.8. ImplementationTable Of Contents
                      
   
@@ -64,388 +64,714 @@ 
                      Navigation
                      
 
                      
 
                      
 
                        
-
                      • 1. Arena
                          
-
                        • 1.1. Introduction
                          • 
-
                        • 1.2. Overview
                          • 
-
                        • 1.3. Definitions
                          • 
-
                        • 1.4. Requirements
                            
-
                          • 1.4.1. Block management
                            • 
-
                          • 1.4.2. Address translation
                            • 
-
                          • 1.4.3. Iteration protocol
                            • 
-
                          • 1.4.4. Arena partition
                            • 
-
                          • 1.4.5. Constraints
                            • 
+
                          • 1. Allocation frame protocol
                              
+
                            • 1.1. Introduction
                              • 
+
                            • 1.2. Definitions
                              • 
+
                            • 1.3. Purpose
                              • 
+
                            • 1.4. Requirements
 
                              • 
-
                            • 1.5. Architecture
                                
-
                              • 1.5.1. Statics
                                • 
-
                              • 1.5.2. Arena classes
                                • 
-
                              • 1.5.3. Tracts
                                • 
-
                              • 1.5.4. Control pool
                                • 
-
                              • 1.5.5. Polling
                                • 
-
                              • 1.5.6. Commit limit
                                • 
-
                              • 1.5.7. Spare committed (aka “hysteresis”)
                                • 
-
                              • 1.5.8. Locks
                                • 
-
                              • 1.5.9. Location dependencies
                                • 
-
                              • 1.5.10. Finalization
                                • 
+
                              • 1.5. Overview
                                • 
+
                              • 1.6. Operations
                                • 
+
                              • 1.7. Interface
 
                                • 
-
                              • 1.6. Implementation
 
                                • 
-
                              • 2. Bit tables
                                  
-
                                • 2.1. Introduction
                                  • 
-
                                • 2.2. Definitions
                                  • 
-
                                • 2.3. Requirements
                                  • 
-
                                • 2.4. Non requirements
                                  • 
-
                                • 2.5. Background
                                  • 
-
                                • 2.6. Clients
                                  • 
-
                                • 2.7. Overview
                                  • 
-
                                • 2.8. Interface
                                  • 
-
                                • 2.9. Detailed design
                                    
-
                                  • 2.9.1. Data structures
                                    • 
-
                                  • 2.9.2. Functions
                                    • 
+
                                  • 2. Arena
                                      
+
                                    • 2.1. Introduction
                                      • 
+
                                    • 2.2. Overview
                                      • 
+
                                    • 2.3. Definitions
                                      • 
+
                                    • 2.4. Requirements
 
                                      • 
-
                                    • 2.10. Testing
                                      • 
+
                                    • 2.5. Architecture
 
                                      • 
-
                                    • 3. Coalescing block structure
-
                                      • 
-
                                    • 4. Checking
-
                                      • 
-
                                    • 5. Pool class interface
-
                                      • 
-
                                    • 6. Collection framework
                                        
-
                                      • 6.1. Introduction
                                        • 
-
                                      • 6.2. Overview
                                        • 
-
                                      • 6.3. Collection abstractions
-
                                        • 
-
                                      • 6.4. The tracer
-
                                        • 
-
                                      • 6.5. Barriers
 
                                        • 
-
                                      • 7. Finalization
                                          
-
                                        • 7.1. Overview
                                          • 
-
                                        • 7.2. Requirements
                                          • 
-
                                        • 7.3. Architecture
                                            
-
                                          • 7.3.1. External interface
                                            • 
+
                                          • 3. Virtual Memory Arena
 
                                            • 
-
                                          • 8. The generic fix function
                                              
-
                                            • 8.1. Introduction
                                              • 
-
                                            • 8.2. Architecture
                                              • 
-
                                            • 8.3. Implementation
                                              • 
+
                                            • 4. Bit tables
                                                
+
                                              • 4.1. Introduction
                                                • 
+
                                              • 4.2. Definitions
                                                • 
+
                                              • 4.3. Requirements
                                                • 
+
                                              • 4.4. Non requirements
                                                • 
+
                                              • 4.5. Background
                                                • 
+
                                              • 4.6. Clients
                                                • 
+
                                              • 4.7. Overview
                                                • 
+
                                              • 4.8. Interface
                                                • 
+
                                              • 4.9. Detailed design
 
                                                • 
-
                                              • 9. The lock module
 
                                                • 
-
                                              • 10. Client message protocol
                                                  
-
                                                • 10.1. Introduction
                                                  • 
-
                                                • 10.2. Requirements
                                                  • 
-
                                                • 10.3. External interface
                                                    
-
                                                  • 10.3.1. Functions
                                                    • 
-
                                                  • 10.3.2. Types of messages
                                                    • 
-
                                                  • 10.3.3. Compatibility issues
                                                    • 
+
                                                  • 5. Allocation buffers and allocation points
 
                                                    • 
-
                                                  • 10.4. Internal interface
                                                      
-
                                                    • 10.4.1. Types
                                                      • 
-
                                                    • 10.4.2. Functions
                                                      • 
+
                                                    • 6. Checking
 
                                                      • 
-
                                                    • 10.5. Message life cycle
                                                      • 
-
                                                    • 10.6. Examples
                                                        
-
                                                      • 10.6.1. Finalization
                                                        • 
+
                                                      • 7. Pool class interface
+
                                                        • 
+
                                                      • 8. Collection framework
 
                                                        • 
-
                                                      • 11. Debugging features for client objects
                                                          
-
                                                        • 11.1. Introduction
                                                          • 
-
                                                        • 11.2. Overview
                                                          • 
-
                                                        • 11.3. Requirements
                                                          • 
-
                                                        • 11.4. Solution ideas
                                                          • 
-
                                                        • 11.5. Architecture
                                                          • 
-
                                                        • 11.6. Client interface
                                                          • 
-
                                                        • 11.7. Examples
                                                          • 
-
                                                        • 11.8. Implementation
                                                          • 
+
                                                        • 9. Diagnostic feedback
                                                            
+
                                                          • 9.1. Introduction
                                                            • 
+
                                                          • 9.2. Overview
                                                            • 
+
                                                          • 9.3. Requirements
                                                            • 
+
                                                          • 9.4. Usage
 
                                                            • 
-
                                                          • 12. Pool and pool class mechanisms
                                                              
-
                                                            • 12.1. Definitions
                                                              • 
-
                                                            • 12.2. Defaults
                                                              • 
-
                                                            • 12.3. Requirements
                                                              • 
-
                                                            • 12.4. Other
                                                              • 
+
                                                            • 9.5. How to write a diagnostic
 
                                                              • 
-
                                                            • 13. AMC pool class
                                                                
-
                                                              • 13.1. Introduction
                                                                • 
-
                                                              • 13.2. Guide
                                                                  
-
                                                                • 13.2.1. Segment states
                                                                  • 
-
                                                                • 13.2.2. Pads
                                                                  • 
-
                                                                • 13.2.3. Placement pads are okay
                                                                  • 
-
                                                                • 13.2.4. Retained pads could be a problem
                                                                  • 
-
                                                                • 13.2.5. Small, medium, and large segments
                                                                  • 
-
                                                                • 13.2.6. The LSP payoff calculation
                                                                  • 
-
                                                                • 13.2.7. Retained pages
                                                                  • 
-
                                                                • 13.2.8. Feedback about retained pages
                                                                  • 
+
                                                                • 9.6. How the MPS diagnostic system works
 
                                                                  • 
-
                                                                • 13.3. Initial design
+
                                                                  • 
+
                                                                • 10. Finalization
+
                                                                  • 
+
                                                                • 11. The generic fix function
+
                                                                  • 
+
                                                                • 12. C interface design
+
                                                                  • 
+
                                                                • 13. I/O subsystem
+
                                                                  • 
+
                                                                • 14. Library interface
+
                                                                  • 
+
                                                                • 15. The lock module
+
                                                                  • 
+
                                                                • 16. MPS Configuration
+
                                                                  • 
+
                                                                • 17. Client message protocol
 
                                                                  • 
-
                                                                • 14. Manually-Managed Variable-Size First-Fit Pool
                                                                    
-
                                                                  • 14.1. Introduction
                                                                    • 
-
                                                                  • 14.2. Overview
                                                                    • 
-
                                                                  • 14.3. Methods
                                                                    • 
-
                                                                  • 14.4. External Functions
                                                                    • 
-
                                                                  • 14.5. Implementation
                                                                    • 
-
                                                                  • 14.6. Details
                                                                    • 
+
                                                                  • 18. GC messages
                                                                      
+
                                                                    • 18.1. Introduction
                                                                      • 
+
                                                                    • 18.2. Overview
                                                                      • 
+
                                                                    • 18.3. Introduction
                                                                      • 
+
                                                                    • 18.4. Purpose
                                                                      • 
+
                                                                    • 18.5. Names and parts
                                                                      • 
+
                                                                    • 18.6. Lifecycle
 
                                                                      • 
-
                                                                    • 15. The protection module
-
                                                                      • 
-
                                                                    • 16. Protocol inheritance
-
                                                                      • 
-
                                                                    • 17. The low-memory reservoir
-
                                                                      • 
-
                                                                    • 18. Root manager
                                                                        
-
                                                                      • 18.1. Basics
                                                                        • 
-
                                                                      • 18.2. Details
 
                                                                        • 
-
                                                                      • 19. The generic scanner
                                                                          
-
                                                                        • 19.1. Summaries
                                                                            
-
                                                                          • 19.1.1. Scanned summary
                                                                            • 
-
                                                                          • 19.1.2. Partial scans
                                                                            • 
+
                                                                          • 19. Debugging features for client objects
+
                                                                            • 
+
                                                                          • 20. Pool and pool class mechanisms
+
                                                                            • 
+
                                                                          • 21. AMC pool class
 
                                                                            • 
-
                                                                          • 20. Segment data structure
                                                                              
-
                                                                            • 20.1. Introduction
                                                                              • 
-
                                                                            • 20.2. Overview
                                                                              • 
-
                                                                            • 20.3. Data Structure
                                                                              • 
-
                                                                            • 20.4. Interface
                                                                                
-
                                                                              • 20.4.1. Splitting and merging
                                                                                • 
+
                                                                              • 22. AMS pool class
                                                                                  
+
                                                                                • 22.1. Introduction
                                                                                  • 
+
                                                                                • 22.2. Overview
                                                                                  • 
+
                                                                                • 22.3. Requirements
                                                                                  • 
+
                                                                                • 22.4. Architecture
 
                                                                                  • 
-
                                                                                • 20.5. Extensibility
+
                                                                                  • 
+
                                                                                • 23. AWL pool class
+
                                                                                  • 
+
                                                                                • 24. LO pool class
+
                                                                                  • 
+
                                                                                • 25. MFS pool class
+
                                                                                  • 
+
                                                                                • 26. MRG pool class
+
                                                                                  • 
+
                                                                                • 27. MVFF pool class
+
                                                                                  • 
+
                                                                                • 28. The protection module
+
                                                                                  • 
+
                                                                                • 29. ANSI implementation of protection module
+
                                                                                  • 
+
                                                                                • 30. Linux implementation of protection module
+
                                                                                  • 
+
                                                                                • 31. SunOS 4 protection module
+
                                                                                  • 
+
                                                                                • 32. Protocol inheritance
+
                                                                                  • 
+
                                                                                • 33. POSIX thread extensions
+
                                                                                  • 
+
                                                                                • 34. The low-memory reservoir
+
                                                                                  • 
+
                                                                                • 35. Root manager
 
                                                                                  • 
-
                                                                                • 21. Splay trees
-
                                                                                  • 
-
                                                                                • 22. Telemetry
                                                                                    
-
                                                                                  • 22.1. Introduction
                                                                                    • 
-
                                                                                  • 22.2. Overview
                                                                                    • 
-
                                                                                  • 22.3. Requirements
                                                                                    • 
-
                                                                                  • 22.4. Architecture
                                                                                    • 
-
                                                                                  • 22.5. Analysis
                                                                                    • 
-
                                                                                  • 22.6. Ideas
                                                                                    • 
-
                                                                                  • 22.7. Implementation
                                                                                      
-
                                                                                    • 22.7.1. Annotation
                                                                                      • 
-
                                                                                    • 22.7.2. Registration
                                                                                      • 
-
                                                                                    • 22.7.3. Control
                                                                                      • 
-
                                                                                    • 22.7.4. Debugging
                                                                                      • 
-
                                                                                    • 22.7.5. Dumper tool
                                                                                      • 
-
                                                                                    • 22.7.6. Allocation replayer tool
                                                                                      • 
+
                                                                                    • 36. The generic scanner
 
                                                                                      • 
-
                                                                                    • 23. Thread safety in the MPS
                                                                                        
-
                                                                                      • 23.1. Introduction
                                                                                        • 
-
                                                                                      • 23.2. Overview
                                                                                        • 
-
                                                                                      • 23.3. Requirements
                                                                                        • 
-
                                                                                      • 23.4. Architecture
                                                                                        • 
-
                                                                                      • 23.5. Analysis
                                                                                          
-
                                                                                        • 23.5.1. Performance cost of locking
                                                                                          • 
-
                                                                                        • 23.5.2. Recursive vs binary locks
                                                                                          • 
+
                                                                                        • 37. Segment data structure
                                                                                            
+
                                                                                          • 37.1. Introduction
                                                                                            • 
+
                                                                                          • 37.2. Overview
                                                                                            • 
+
                                                                                          • 37.3. Data Structure
                                                                                            • 
+
                                                                                          • 37.4. Interface
 
                                                                                            • 
-
                                                                                          • 23.6. Ideas
                                                                                            • 
-
                                                                                          • 23.7. Implementation
 
                                                                                            • 
-
                                                                                          • 24. Tracer
                                                                                              
-
                                                                                            • 24.1. Introduction
                                                                                              • 
-
                                                                                            • 24.2. Architecture
                                                                                              • 
-
                                                                                            • 24.3. Analysis
                                                                                              • 
-
                                                                                            • 24.4. Ideas
                                                                                              • 
-
                                                                                            • 24.5. Implementation
                                                                                                
-
                                                                                              • 24.5.1. Speed
                                                                                                • 
+
                                                                                              • 38. Shield
 
                                                                                                • 
-
                                                                                              • 24.6. Life cycle of a trace object
                                                                                                  
-
                                                                                                • 24.6.1. Making progress: scanning grey segments
                                                                                                  • 
+
                                                                                                • 39. Splay trees
 
                                                                                                  • 
-
                                                                                                • 25. General MPS types
                                                                                                    
-
                                                                                                  • 25.1. Introduction
                                                                                                    • 
-
                                                                                                  • 25.2. Rationale
                                                                                                    • 
-
                                                                                                  • 25.3. Concrete types
                                                                                                    • 
-
                                                                                                  • 25.4. Abstract types
                                                                                                    • 
+
                                                                                                  • 40. Stack scanner for Digital Unix on Alpha
                                                                                                      
+
                                                                                                    • 40.1. Introduction
                                                                                                      • 
+
                                                                                                    • 40.2. Definitions
                                                                                                      • 
+
                                                                                                    • 40.3. Overview
                                                                                                      • 
+
                                                                                                    • 40.4. Detail Design
 
                                                                                                      • 
-
                                                                                                    • 26. Library version mechanism
 
                                                                                                      • 
-
                                                                                                    • 27. Software versions
                                                                                                        
-
                                                                                                      • 27.1. Introduction
                                                                                                        • 
-
                                                                                                      • 27.2. Overview
                                                                                                        • 
+
                                                                                                      • 41. Telemetry
diff --git a/mps/manual/html/design/pool.html b/mps/manual/html/design/pool.html
index d84304a319c..849d883626b 100644
--- a/mps/manual/html/design/pool.html
+++ b/mps/manual/html/design/pool.html
@@ -8,7 +8,7 @@
   
     
     
-    12. Pool and pool class mechanisms — Memory Pool System 1.111.0 documentation
+    20. Pool and pool class mechanisms — Memory Pool System 1.111.0 documentation
     
     
     
@@ -28,8 +28,8 @@
     
     
     
-    
-     
+    
+     
   
   
     
                                                                                                        
@@ -39,10 +39,10 @@ 
                                                                                                        Navigation
                                                                                                        
           index
                                                                                                        • 
         
                                                                                                      • 
-          next |
                                                                                                        • 
         
                                                                                                      • 
-          previous |
                                                                                                        • 
         
                                                                                                      • Memory Pool System 1.111.0 documentation »
                                                                                                        • 
           
                                                                                                      • Old design »
                                                                                                        •  
@@ -54,10 +54,10 @@ 
                                                                                                        Navigation
                                                                                                        
         
                                                                                                        
           
                                                                                                        
             
-  
                                                                                                        
-
                                                                                                        12. Pool and pool class mechanisms
                                                                                                        
+  
                                                                                                        
+
                                                                                                        20. Pool and pool class mechanisms
                                                                                                        
 
                                                                                                        
-
                                                                                                        12.1. Definitions
                                                                                                        
+
                                                                                                        20.1. Definitions
                                                                                                        
 
                                                                                                        .def.outer-structure: The “outer structure” (of a pool) is a C
 object of type PoolXXXStruct or the type struct PoolXXXStruct
 itself.
                                                                                                        
@@ -66,7 +66,7 @@ 
                                                                                                        Navigation
                                                                                                        
 type struct PoolStruct itself.
                                                                                                        
 
                                                                                                        
 
                                                                                                        
-
                                                                                                        12.2. Defaults
                                                                                                        
+
                                                                                                        20.2. Defaults
                                                                                                        
 
                                                                                                        .align: When initialised, the pool gets the default alignment
 (ARCH_ALIGN).
                                                                                                        
 
                                                                                                        .no: If a pool class doesn’t implement a method, and doesn’t expect
@@ -81,12 +81,15 @@ 
                                                                                                        12.2. Defaults
-
                                                                                                        12.3. Requirements
                                                                                                        
-
                                                                                                        [Placeholder: must derive the requirements from the architecture.]
                                                                                                        
+
                                                                                                        20.3. Requirements
                                                                                                        
+
                                                                                                        
+
                                                                                                        Note
                                                                                                        
+
                                                                                                        Placeholder: must derive the requirements from the architecture.
                                                                                                        
+
                                                                                                        
 
                                                                                                        .req.fix: PoolFix() must be fast.
                                                                                                        
 
                                                                                                        
 
                                                                                                        
-
                                                                                                        12.4. Other
                                                                                                        
+
                                                                                                        20.4. Other
                                                                                                        
 
                                                                                                        Interface in mpm.h
 Types in mpmst.h
 See also design.mps.poolclass
                                                                                                        
@@ -104,21 +107,21 @@ 
                                                                                                        12.4. OtherTable Of Contents
                                                                                                        
   
                                                                                                          
-
                                                                                                        • 12. Pool and pool class mechanisms
 
   
                                                                                                          Previous topic
                                                                                                          
   
                                                                                                          11. Debugging features for client objects
                                                                                                          
+                        title="previous chapter">19. Debugging features for client objects
                                                                                                          
   
                                                                                                          Next topic
                                                                                                          
   
                                                                                                          13. AMC pool class
                                                                                                          Downloads
                                                                                                          
+                        title="next chapter">21. AMC pool class
                                                                                                          Downloads
                                                                                                          
 
 
                                                                                                          
 MPS Kit release 1.111.0
                                                                                                          
@@ -144,10 +147,10 @@ 
                                                                                                          Navigation
                                                                                                          
           index
                                                                                                          • 
         
                                                                                                        • 
-          next |
                                                                                                          • 
         
                                                                                                        • 
-          previous |
                                                                                                          • 
         
                                                                                                        • Memory Pool System 1.111.0 documentation »
                                                                                                          • 
           
                                                                                                        • Old design »
                                                                                                          •  
diff --git a/mps/manual/html/design/poolamc.html b/mps/manual/html/design/poolamc.html
index 16d0927455e..e5cab47e75f 100644
--- a/mps/manual/html/design/poolamc.html
+++ b/mps/manual/html/design/poolamc.html
@@ -8,7 +8,7 @@
   
     
     
-    13. AMC pool class — Memory Pool System 1.111.0 documentation
+    21. AMC pool class — Memory Pool System 1.111.0 documentation
     
     
     
@@ -28,8 +28,8 @@
     
     
     
-    
-     
+    
+     
   
   
     
                                                                                                          
@@ -39,10 +39,10 @@ 
                                                                                                          Navigation
                                                                                                          
           index
         
                                                                                                        • 
-          next |
                                                                                                          • 
         
                                                                                                        • 
-          previous |
                                                                                                          • 
         
                                                                                                        • Memory Pool System 1.111.0 documentation »
                                                                                                          • 
           
                                                                                                        • Old design »
                                                                                                          •  
@@ -54,17 +54,17 @@ 
                                                                                                          Navigation
                                                                                                          
         
                                                                                                          
           
                                                                                                          
             
-  
                                                                                                          
-
                                                                                                          13. AMC pool class
                                                                                                          
+  
                                                                                                          
+
                                                                                                          21. AMC pool class
                                                                                                          
 
                                                                                                          
-
                                                                                                          13.1. Introduction
                                                                                                          
+
                                                                                                          21.1. Introduction
                                                                                                          
 
                                                                                                          .intro: This document contains a guide (.guide) to the MPS AMC
 pool class, followed by the historical initial design
 (.initial-design).
                                                                                                          
 
                                                                                                          .readership: Any MPS developer.
                                                                                                          
 
                                                                                                          
 
                                                                                                          
-
                                                                                                          13.2. Guide
                                                                                                          
+
                                                                                                          21.2. Guide
                                                                                                          
 
                                                                                                          .guide: The AMC pool class is a general-purpose automatic
 (collecting) pool class. It is intended for most client objects. AMC
 is “Automatic, Mostly Copying”: it preserves objects by copying,
@@ -74,7 +74,7 @@ 
                                                                                                          13.2. Guide
-
                                                                                                          13.2.1. Segment states
                                                                                                          
+
                                                                                                          21.2.1. Segment states
                                                                                                          
 
                                                                                                          .seg.state: AMC segments are in one of three states: “mobile”,
 “boarded”, or “stuck”.
                                                                                                          
 
                                                                                                          .seg.state.mobile: Segments are normally mobile: all objects on
@@ -88,7 +88,7 @@ 
                                                                                                          13.2.1. Segment states
-
                                                                                                          13.2.2. Pads
                                                                                                          
+
                                                                                                          21.2.2. Pads
                                                                                                          
 
                                                                                                          (See job001809 and job001811, and mps/branch/2009-03-31/padding.)
                                                                                                          
 
                                                                                                          .pad: A pad is logically a trivial client object. Pads are created
 by the MPS asking the client’s format code to create them, to fill up
@@ -140,7 +140,7 @@ 
                                                                                                          13.2.2. PadsSegFree() (new with job001809).
                                                                                                          
 
                                                                                                          
 
                                                                                                          
-
                                                                                                          13.2.3. Placement pads are okay
                                                                                                          
+
                                                                                                          21.2.3. Placement pads are okay
                                                                                                          
 
                                                                                                          Placement pads are the BEF and LSP pads created in “to-space” when
 placing objects into segments. This wasted space is an expected
 space-cost of AMC’s naive (but time-efficient) approach to placement
@@ -149,7 +149,7 @@ 
                                                                                                          13.2.3. Placement pads are okay
-
                                                                                                          13.2.4. Retained pads could be a problem
                                                                                                          
+
                                                                                                          21.2.4. Retained pads could be a problem
                                                                                                          
 
                                                                                                          Retained pads are the NMR pads stuck in “from-space”: non-mobile
 segments that were condemned but have preserved-in-place objects
 cannot be freed by amcReclaimNailed(). The space around the
@@ -166,7 +166,7 @@ 
                                                                                                          13.2.4. Retained pads could be a problem
-
                                                                                                          13.2.5. Small, medium, and large segments
                                                                                                          
+
                                                                                                          21.2.5. Small, medium, and large segments
                                                                                                          
 
                                                                                                          AMC categorises segments as small (one page), medium
 (several pages), or large (AMCLargeSegPAGES or more):
                                                                                                          
 
                                                                                                          pages = SegSize(seg) / ArenaAlign(arena);
@@ -224,7 +224,7 @@ 
                                                                                                          13.2.5. Small, medium, and large segments
-
                                                                                                          13.2.6. The LSP payoff calculation
                                                                                                          
+
                                                                                                          21.2.6. The LSP payoff calculation
                                                                                                          
 
                                                                                                          The LSP fix for job001811 treats large segments differently. Without
 it, after allocating a very large object (in a new very large
 multi-page segment), MPS would happily place subsequent small objects
@@ -264,7 +264,7 @@ 
                                                                                                          13.2.6. The LSP payoff calculationAMCLargeSegPAGES could be made a client-tunable parameter.
                                                                                                          
 
                                                                                                          
 
                                                                                                          
-
                                                                                                          13.2.7. Retained pages
                                                                                                          
+
                                                                                                          21.2.7. Retained pages
                                                                                                          
 
                                                                                                          The reasons why a segment and its pages might be retained are:
                                                                                                          
 
                                                                                                            
 
                                                                                                          1. ambiguous reference to first-obj: unavoidable page retention (only
@@ -286,7 +286,7 @@ 
                                                                                                            13.2.7. Retained pages
-
                                                                                                            13.2.8. Feedback about retained pages
                                                                                                            
+
                                                                                                            21.2.8. Feedback about retained pages
                                                                                                            
 
                                                                                                            (New with job001811). AMC now accumulates counts of pages condemned
 and retained during a trace, in categories according to size and
 reason for retention, and emits diagnostic at trace-end via the
@@ -299,32 +299,35 @@ 
                                                                                                            13.2.8. Feedback about retained pages
-
                                                                                                            13.3. Initial design
                                                                                                            
+
                                                                                                            21.3. Initial design
                                                                                                            
 
                                                                                                            
-
                                                                                                            13.3.1. Introduction
                                                                                                            
+
                                                                                                            21.3.1. Introduction
                                                                                                            
 
                                                                                                            .intro: This is the design of the AMC Pool Class. AMC stands for
 Automatic Mostly-Copying. This design is highly fragmentory and some
 may even be sufficiently old to be misleading.
                                                                                                            
 
                                                                                                            .readership: The intended readership is any MPS developer.
                                                                                                            
 
                                                                                                            
 
                                                                                                            
-
                                                                                                            13.3.2. Overview
                                                                                                            
+
                                                                                                            21.3.2. Overview
                                                                                                            
 
                                                                                                            .overview: This class is intended to be the main pool class used by
 Harlequin Dylan. It provides garbage collection of objects (hence
 “automatic”). It uses generational copying algorithms, but with some
 facility for handling small numbers of ambiguous references. Ambiguous
 references prevent the pool from copying objects (hence “mostly
 copying”). It provides incremental collection.
                                                                                                            
-
                                                                                                            [ lot of this design is awesomely old – drj 1998-02-04]
                                                                                                            
+
                                                                                                            
+
                                                                                                            Note
                                                                                                            
+
                                                                                                            A lot of this design is awesomely old. David Jones, 1998-02-04.
                                                                                                            
+
                                                                                                            
 
                                                                                                            
 
                                                                                                            
-
                                                                                                            13.3.3. Definitions
                                                                                                            
+
                                                                                                            21.3.3. Definitions
                                                                                                            
 
                                                                                                            .def.grain: Grain. An quantity of memory which is both aligned to
 the pool’s alignment and equal to the pool’s alignment in size. That
 is, the smallest amount of memory worth talking about.
                                                                                                            
 
                                                                                                            
 
                                                                                                            
-
                                                                                                            13.3.4. Segments
                                                                                                            
+
                                                                                                            21.3.4. Segments
                                                                                                            
 
                                                                                                            .seg.class: AMC allocates segments of class AMCSegClass, which
 is a subclass of GCSegClass. Instances contain a segTypeP
 field, which is of type int*.
                                                                                                            
@@ -342,9 +345,12 @@ 
                                                                                                            13.3.4. SegmentsAMCSegGen() which deals with all this.
                                                                                                            
 
                                                                                                            
 
                                                                                                            
-
                                                                                                            13.3.5. Fixing and nailing
                                                                                                            
-
                                                                                                            .fix.nail: [.fix.nail.* are placeholders for design rather than
-design really – drj 1998-02-04]
                                                                                                            
+
                                                                                                            21.3.5. Fixing and nailing
                                                                                                            
+
                                                                                                            
+
                                                                                                            Note
                                                                                                            
+
                                                                                                            This section contains placeholders for design rather than design
+really. David Jones, 1998-02-04.
                                                                                                            
+
                                                                                                            
 
                                                                                                            .nailboard: AMC uses a nail board structure for recording ambiguous
 references to segments. A nail board is a bit table with one bit per
 grain in the segment.
                                                                                                            
@@ -408,7 +414,7 @@ 
                                                                                                            13.3.5. Fixing and nailing
 
                                                                                                            
 
                                                                                                            
-
                                                                                                            13.3.6. Emergency tracing
                                                                                                            
+
                                                                                                            21.3.6. Emergency tracing
                                                                                                            
 
                                                                                                            .emergency.fix: AMCFixEmergency() is at the core of AMC’s
 emergency tracing policy (unsurprisingly). AMCFixEmergency()
 chooses exactly one of three options:
                                                                                                            
@@ -429,7 +435,7 @@ 
                                                                                                            13.3.6. Emergency tracing
 
                                                                                                            
 
                                                                                                            
-
                                                                                                            13.3.7. Buffers
                                                                                                            
+
                                                                                                            21.3.7. Buffers
                                                                                                            
 
                                                                                                            .buffer.class: AMC uses buffer of class AMCBufClass (a subclass
 of SegBufClass).
                                                                                                            
 
                                                                                                            .buffer.gen: Each buffer allocates into exactly one generation.
                                                                                                            
@@ -441,34 +447,45 @@ 
                                                                                                            13.3.7. Buffers.buffer.condemn: We condemn buffered segments, but not the contents
 of the buffers themselves, because we can’t reclaim uncommitted
 buffers (see design.mps.buffer for details). If the segment has a
-forwarding buffer on it, we detach it [why? @@@@ forwarding buffers
-are detached because they used to cause objects on the same segment to
-not get condemned, hence caused retention of garbage. Now that we
-condemn the non-buffered portion of buffered segments this is probably
-unnecessary – drj 1998-06-01 But it’s probably more efficient than
-keeping the buffer on the segment, because then the other stuff gets
-nailed – pekka 1998-07-10]. If the segment has a mutator buffer on
-it, we nail the buffer. If the buffer cannot be nailed, we give up
-condemning, since nailing the whole segment would make it survive
-anyway. The scan methods skip over buffers and fix methods don’t do
-anything to things that have already been nailed, so the buffer is
-effectively black.
                                                                                                            
+forwarding buffer on it, we detach it.
                                                                                                            
+
                                                                                                            
+
                                                                                                            Note
                                                                                                            
+
                                                                                                            Why? Forwarding buffers are detached because they used to cause
+objects on the same segment to not get condemned, hence caused
+retention of garbage. Now that we condemn the non-buffered portion
+of buffered segments this is probably unnecessary. David Jones,
+1998-06-01.
                                                                                                            
+
                                                                                                            But it’s probably more efficient than keeping the buffer on the
+segment, because then the other stuff gets nailed – Pekka P.
+Pirinen, 1998-07-10.
                                                                                                            
+
                                                                                                            
+
                                                                                                            If the segment has a mutator buffer on it, we nail the buffer. If the
+buffer cannot be nailed, we give up condemning, since nailing the
+whole segment would make it survive anyway. The scan methods skip over
+buffers and fix methods don’t do anything to things that have already
+been nailed, so the buffer is effectively black.
                                                                                                            
 
                                                                                                            
 
                                                                                                            
-
                                                                                                            13.3.8. Types
                                                                                                            
+
                                                                                                            21.3.8. Types
                                                                                                            
 
                                                                                                            .struct: AMCStruct is the pool class AMC instance structure.
                                                                                                            
 
                                                                                                            .struct.pool: Like other pool class instances, it contains a
 PoolStruct containing the generic pool fields.
                                                                                                            
 
                                                                                                            .struct.format: The format field points to a Format
 structure describing the object format of objects allocated in the
 pool. The field is intialized by AMCInit() from a parameter, and
-thereafter it is not changed until the pool is destroyed. [actually
-the format field is in the generic PoolStruct these days. drj
-1998-09-21]
                                                                                                            
-
                                                                                                            [lots more fields here]
                                                                                                            
+thereafter it is not changed until the pool is destroyed.
                                                                                                            
+
                                                                                                            
+
                                                                                                            Note
                                                                                                            
+
                                                                                                            Actually the format field is in the generic PoolStruct these
+days. David Jones, 1998-09-21.
                                                                                                            
+
                                                                                                            
+
                                                                                                            
+
                                                                                                            Note
                                                                                                            
+
                                                                                                            There are lots more fields here.
                                                                                                            
+
                                                                                                            
 
                                                                                                            
 
                                                                                                            
-
                                                                                                            13.3.9. Generations
                                                                                                            
+
                                                                                                            21.3.9. Generations
                                                                                                            
 
                                                                                                            .gen: Generations partition the segments that a pool manages (see
 .seg.gen.map above).
                                                                                                            
 
                                                                                                            .gen.collect: Generations are more or less the units of
@@ -486,8 +503,12 @@ 
                                                                                                            13.3.9. Generations.gen.manage.array: They are also kept in an array which is
 allocated when the pool is created and attached to the AMCStruct
 (the gens field holds the number of generations, the gen field
-points to an array of AMCGen). [it seems to me that we could
-probably get rid of the ring – drj 1998-09-22]
                                                                                                            
+points to an array of AMCGen).
                                                                                                            
+
                                                                                                            
+
                                                                                                            Note
                                                                                                            
+
                                                                                                            it seems to me that we could probably get rid of the ring. David
+Jones, 1998-09-22.
                                                                                                            
+
                                                                                                            
 
                                                                                                            .gen.number: There are AMCTopGen + 2 generations in total.
 “normal” generations numbered from 0 to AMCTopGen inclusive and an
 extra “ramp” generation (see .gen.ramp below).
                                                                                                            
@@ -504,7 +525,7 @@ 
                                                                                                            13.3.9. GenerationsAMCInitComm()).
                                                                                                            
 
                                                                                                            
 
                                                                                                            
-
                                                                                                            13.3.10. Ramps
                                                                                                            
+
                                                                                                            21.3.10. Ramps
                                                                                                            
 
                                                                                                            .ramp: Ramps usefully implement the begin/end
 mps_alloc_pattern_ramp() interface.
                                                                                                            
 
                                                                                                            .gen.ramp: To implement ramping (request.dylan.170423), AMC uses a
@@ -587,7 +608,7 @@ 
                                                                                                            13.3.10. RampsAMCRampBegin(), but ignored there).
                                                                                                            
 
                                                                                                            
 
                                                                                                            
-
                                                                                                            13.3.11. Headers
                                                                                                            
+
                                                                                                            21.3.11. Headers
                                                                                                            
 
                                                                                                            .header: AMC supports a fixed-size header on objects, with the
 client pointers pointing after the header, rather than the base of the
 memory block. See format documentation for details of the interface.
                                                                                                            
@@ -604,7 +625,7 @@ 
                                                                                                            13.3.11. Headers
-
                                                                                                            13.3.12. Old and aging notes below here
                                                                                                            
+
                                                                                                            21.3.12. Old and aging notes below here
                                                                                                            
 
                                                                                                            
 
                                                                                                            
 void AMCFinish(Pool pool)
                                                                                                            
@@ -698,32 +719,32 @@ 
                                                                                                            13.3.12. Old and aging notes below hereTable Of Contents
                                                                                                            
   
                                                                                                              
-
                                                                                                            • 13. AMC pool class
                                                                                                                
-
                                                                                                              • 13.1. Introduction
                                                                                                                • 
-
                                                                                                              • 13.2. Guide
                                                                                                                  
-
                                                                                                                • 13.2.1. Segment states
                                                                                                                  • 
-
                                                                                                                • 13.2.2. Pads
                                                                                                                  • 
-
                                                                                                                • 13.2.3. Placement pads are okay
                                                                                                                  • 
-
                                                                                                                • 13.2.4. Retained pads could be a problem
                                                                                                                  • 
-
                                                                                                                • 13.2.5. Small, medium, and large segments
                                                                                                                  • 
-
                                                                                                                • 13.2.6. The LSP payoff calculation
                                                                                                                  • 
-
                                                                                                                • 13.2.7. Retained pages
                                                                                                                  • 
-
                                                                                                                • 13.2.8. Feedback about retained pages
                                                                                                                  • 
+
                                                                                                                • 21. AMC pool class
                                                                                                                    
+
                                                                                                                  • 21.1. Introduction
                                                                                                                    • 
+
                                                                                                                  • 21.2. Guide
 
                                                                                                                    • 
-
                                                                                                                  • 13.3. Initial design
@@ -732,10 +753,10 @@ 
                                                                                                                    Table Of Contents
                                                                                                                    
 
   
                                                                                                                    Previous topic
                                                                                                                    
   
                                                                                                                    12. Pool and pool class mechanisms
                                                                                                                    
+                        title="previous chapter">20. Pool and pool class mechanisms
                                                                                                                    
   
                                                                                                                    Next topic
                                                                                                                    
-  
                                                                                                                    14. Manually-Managed Variable-Size First-Fit Pool
                                                                                                                    Downloads
                                                                                                                    
+  
                                                                                                                    22. AMS pool class
                                                                                                                    Downloads
                                                                                                                    
 
 
                                                                                                                    
 MPS Kit release 1.111.0
                                                                                                                    
@@ -761,10 +782,10 @@ 
                                                                                                                    Navigation
                                                                                                                    
           index
                                                                                                                    • 
         
                                                                                                                  • 
-          next |
                                                                                                                    • 
         
                                                                                                                  • 
-          previous |
                                                                                                                    • 
         
                                                                                                                  • Memory Pool System 1.111.0 documentation »
                                                                                                                    • 
           
                                                                                                                  • Old design »
                                                                                                                    •  
diff --git a/mps/manual/html/design/poolams.html b/mps/manual/html/design/poolams.html
new file mode 100644
index 00000000000..4413379c251
--- /dev/null
+++ b/mps/manual/html/design/poolams.html
@@ -0,0 +1,509 @@
+
+
+
+
+
+
+  
+    
+    
+    22. AMS pool class — Memory Pool System 1.111.0 documentation
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+     
+  
+  
+    
                                                                                                                    
+      
                                                                                                                    Navigation
                                                                                                                    
+      
+    
                                                                                                                      
+
+    
                                                                                                                    
+      
                                                                                                                    
+        
                                                                                                                    
+          
                                                                                                                    
+            
+  
                                                                                                                    
+
                                                                                                                    22. AMS pool class
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.1. Introduction
                                                                                                                    
+
                                                                                                                    .intro: This is the design of the AMS pool class.
                                                                                                                    
+
                                                                                                                    .readership: MM developers.
                                                                                                                    
+
                                                                                                                    .source: design.mps.buffer, design.mps.trace, design.mps.scan,
+design.mps.action and design.mps.class-interface [none of these were
+actually used – pekka 1998-04-21].  No requirements doc [we need a
+req.mps that captures the commonalities between the products – pekka
+1998-01-27].
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.2. Overview
                                                                                                                    
+
                                                                                                                    .overview: This document describes the design of the AMS (Automatic
+Mark-and-Sweep) pool class. The AMS pool is a proof-of-concept design
+for a mark-sweep pool in the MPS. It’s not meant to be efficient, but
+it could serve as a model for an implementation of a more advanced
+pool (such as EPVM).
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.3. Requirements
                                                                                                                    
+
                                                                                                                    .req.mark-sweep: The pool must use a mark-and-sweep GC algorithm.
                                                                                                                    
+
                                                                                                                    .req.colour: The colour representation should be as efficient as
+possible.
                                                                                                                    
+
                                                                                                                    .req.incremental: The pool must support incremental GC.
                                                                                                                    
+
                                                                                                                    .req.ambiguous: The pool must support ambiguous references to
+objects in it (but ambiguous references into the middle of an object
+do not preserve the object).
                                                                                                                    
+
                                                                                                                    .req.format: The pool must be formatted, for generality.
                                                                                                                    
+
                                                                                                                    .req.correct: The design and the implementation should be simple
+enough to be seen to be correct.
                                                                                                                    
+
                                                                                                                    .req.simple: Features not related to mark-and-sweep GC should
+initially be implemented as simply as possible, in order to save
+development effort.
                                                                                                                    
+
                                                                                                                    .not-req.grey: We haven’t figured out how buffers ought to work
+with a grey mutator, so we use .req.correct to allow us to design a
+pool that doesn’t work in that phase. This is acceptable as long as we
+haven’t actually implemented grey mutator collection.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.4. Architecture
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.4.1. Subclassing
                                                                                                                    
+
                                                                                                                    .subclass: Since we expect to have many mark-and-sweep pools, we
+build in some protocol for subclasses to modify various aspects of the
+behaviour. Notably there’s a subclassable segment class, and a
+protocol for performing iteration.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.4.2. Allocation
                                                                                                                    
+
                                                                                                                    .align: We divide the segments in grains, each the size of the
+format alignment. .alloc-bit-table: We keep track of allocated
+grains using a bit table. This allows a simple implementation of
+allocation and freeing using the bit table operators, satisfying
+.req.simple, and can simplify the GC routines. Eventually, this
+should use some sophisticated allocation technique suitable for
+non-moving automatic pools.
                                                                                                                    
+
                                                                                                                    .buffer: We use buffered allocation, satisfying
+.req.incremental. The AMC buffer technique is reused, although it
+is not suitable for non-moving pools, but req.simple allows us to do
+that for now.
                                                                                                                    
+
                                                                                                                    .extend: If there’s no space in any existing segment, a new segment
+is allocated. The actual class is allowed to decide the size of the
+new segment.
                                                                                                                    
+
                                                                                                                    .no-alloc: Do not support PoolAlloc(), because we can’t support
+one-phase allocation for a scannable pool (unless we disallow
+incremental collection). For exact details, see design.mps.buffer.
                                                                                                                    
+
                                                                                                                    .no-free: Do not support PoolFree(), because automatic pools
+don’t need explicit free and having it encourages clients to use it
+(and therefore to have dangling pointers, double frees, and other
+memory management errors.)
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.4.3. Colours
                                                                                                                    
+
                                                                                                                    .colour: Objects in a segment which is not condemned (for some
+trace) take their colour (for this trace) from the segment.
                                                                                                                    
+
                                                                                                                    .colour.object: Since we need to implement a non-copying GC, we
+keep track of the colour of each object in a condemned segment
+separately. For this, we use bit tables with a bit for each grain.
+This format is fast to access, has better locality than mark bits in
+the objects themselves, and allows cheap interoperation with the
+allocation bit table.
                                                                                                                    
+
                                                                                                                    .colour.encoding: As to the details, we follow
+analysis.non-moving-colour(3), implementing both the alloc-white
+sharing option described in
+analysis.non-moving-colour.constraint.reclaim.white-free-bit and the
+vanilla three-table option, because the former cannot work with
+interior pointers. However, the colour encoding in both is the same.
                                                                                                                    
+
                                                                                                                    .ambiguous.middle: We will allow ambiguous references into the
+middle of an object (as required by .req.ambiguous), using the
+trick in analysis.non-moving-colour.interior.ambiguous-only to speed
+up scanning.
                                                                                                                    
+
                                                                                                                    .interior-pointer: Note that non-ambiguous interior pointers are
+outlawed.
                                                                                                                    
+
                                                                                                                    .colour.alloc: Objects are allocated black. This is the most
+efficient alternative for traces in the black mutator phase, and
+.not-req.grey means that’s sufficient.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    Note
                                                                                                                    
+
                                                                                                                    Some day, we need to think about allocating grey or white during
+the grey mutator phase.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.4.4. Scanning
                                                                                                                    
+
                                                                                                                    .scan.segment: The tracer protocol requires (for segment barrier
+hits) that there is a method for scanning a segment and turning all
+grey objects on it black. This cannot be achieved with a single
+sequential sweep over the segment, since objects that the sweep has
+already passed may become grey as later objects are scanned.
                                                                                                                    
+
                                                                                                                    .scan.graph: For a non-moving GC, it is more efficient to trace
+along the reference graph than segment by segment. It also allows
+passing type information from fix to scan. Currently, the tracer
+doesn’t offer this option when it’s polling for work.
                                                                                                                    
+
                                                                                                                    .scan.stack: Tracing along the reference graph cannot be done by
+recursive descent, because we can’t guarantee that the stack won’t
+overflow. We can, however, maintain an explicit stack of things to
+trace, and fall back on iterative methods (.scan.iter) when it
+overflows and can’t be extended.
                                                                                                                    
+
                                                                                                                    .scan.iter: As discussed in .scan.segment, when scanning a
+segment, we need to ensure that there are no grey objects in the
+segment when the scan method returns. We can do this by iterating a
+sequential scan over the segment until nothing is grey (see
+.marked.scan for details).
                                                                                                                    
+
                                                                                                                    .scan.iter.only: Some iterative method is needed as a fallback for
+the more advanced methods, and as this is the simplest way of
+implementing the current tracer protocol, we will start by
+implementing it as the only scanning method.
                                                                                                                    
+
                                                                                                                    .scan.buffer: We do not scan between ScanLimit and Limit of a
+buffer (see .iteration.buffer), as usual.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    Note
                                                                                                                    
+
                                                                                                                    design.mps.buffer should explain why this works, but doesn’t.
+Pekka P. Pirinen, 1998-02-11.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    .fix.to-black: When fixing a reference to a white object, if the
+segment does not refer to the white set, the object cannot refer to
+the white set, and can therefore be marked as black immediately
+(rather than grey).
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.5. Implementation
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.5.1. Colour
                                                                                                                    
+
                                                                                                                    .colour.determine: Following the plan in .colour, if
+SegWhite(seg) includes the trace, the colour of an object is given
+by the bit tables. Otherwise if SegGrey(seg) includes the trace,
+all the objects are grey. Otherwise all the objects are black.
                                                                                                                    
+
                                                                                                                    .colour.bits: As we only have searches for runs of zero bits, we use
+two bit tables, the non-grey and non-white tables, but this is hidden
+beneath a layer of macros talking about grey and white in positive
+terms.
                                                                                                                    
+
                                                                                                                    .colour.single: We have only implemented a single set of mark and
+scan tables, so we can only condemn a segment for one trace at a time.
+This is checked for in condemnation. If we want to do overlapping
+white sets, each trace needs its own set of tables.
                                                                                                                    
+
                                                                                                                    .colour.check: The grey-and-non-white state is illegal, and free
+objects must be white as explained in
+analysis.non-moving-colour.contraint.reclaim.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.5.2. Iteration
                                                                                                                    
+
                                                                                                                    .iteration: Scan, reclaim and other operations need to iterate over
+all objects in a segment. We abstract this into a single iteration
+function, even though we no longer use it for reclaiming and rarely
+for scanning.
                                                                                                                    
+
                                                                                                                    .iteration.buffer: Iteration skips directly from ScanLimit to Limit
+of a buffer. This is because this area may contain
+partially-initialized and uninitialized data, which cannot be
+processed. Since the iteration skips the buffer, callers need to take
+the appropriate action, if any, on it.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    Note
                                                                                                                    
+
                                                                                                                    ScanLimit is used for reasons which are not documented in
+design.mps.buffer.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.5.3. Scanning Algorithm
                                                                                                                    
+
                                                                                                                    .marked: Each segment has a marksChanged flag, indicating
+whether anything in it has been made grey since the last scan
+iteration (.scan.iter) started. This flag only concerns the colour
+of objects with respect to the trace for which the segment is
+condemned, as this is the only trace for which objects in the segment
+are being made grey by fixing. Note that this flag doesn’t imply that
+there are grey objects in the segment, because the grey objects might
+have been subsequently scanned and blackened.
                                                                                                                    
+
                                                                                                                    .marked.fix: The marksChanged flag is set TRUE by
+AMSFix() when an object is made grey.
                                                                                                                    
+
                                                                                                                    .marked.scan: AMSScan() must blacken all grey objects on the
+segment, so it must iterate over the segment until all grey objects
+have been seen. Scanning an object in the segment might grey another
+one (.marked.fix), so the scanner iterates until this flag is
+FALSE, setting it to FALSE before each scan. It is safe to
+scan the segment even if it contains nothing grey.
                                                                                                                    
+
                                                                                                                    .marked.scan.fail: If the format scanner returns failure (see
+protocol.mps.scanning), we abort the scan in the middle of a segment.
+So in this case the marksChanged flag is set back to TRUE, because we
+may not have blackened all grey objects.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    Note
                                                                                                                    
+
                                                                                                                    Is that the best reference for the format scanner?
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    .marked.unused: The marksChanged flag is meaningless unless the
+segment is condemned. We make it FALSE in these circumstances.
                                                                                                                    
+
                                                                                                                    .marked.condemn: Condemnation makes all objects in a segment either
+black or white, leaving nothing grey, so it doesn’t need to set the
+marksChanged flag which must already be FALSE.
                                                                                                                    
+
                                                                                                                    .marked.reclaim: When a segment is reclaimed, it can contain
+nothing marked as grey, so the marksChanged flag must already be
+FALSE.
                                                                                                                    
+
                                                                                                                    .marked.blacken: When the tracer decides not to scan, but to call
+PoolBlacken(), we know that any greyness can be removed.
+AMSBlacken() does this and resets the marksChanged flag, if it
+finds that the segment has been condemned.
                                                                                                                    
+
                                                                                                                    .marked.clever: AMS could be clever about not setting the
+marksChanged flag, if the fixed object is ahead of the current
+scan pointer. It could also keep low- and high-water marks of grey
+objects, but we don’t need to implement these improvements at first.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.5.4. Allocation
                                                                                                                    
+
                                                                                                                    .buffer-init: We take one init arg to set the Rank on the buffer,
+just to see how it’s done.
                                                                                                                    
+
                                                                                                                    .no-bit: As an optimization, we won’t use the alloc bit table until
+the first reclaim on the segment. Before that, we just keep a
+high-water mark.
                                                                                                                    
+
                                                                                                                    .fill: AMSBufferFill() takes the simplest approach: it iterates
+over the segments in the pool, looking for one which can be used to
+refill the buffer.
                                                                                                                    
+
                                                                                                                    .fill.colour: The objects allocated from the new buffer must be
+black for all traces (.colour.alloc), so putting it on a black
+segment (meaning one where neither SegWhite(seg) nor
+SegGrey(seg) include the trace, see .colour.determine) is
+obviously OK. White segments (where SegWhite(seg) includes the
+trace) are also fine, as we can use the colour tables to make it
+black. At first glance, it seems we can’t put it on a segment that is
+grey but not white for some trace (one where SegWhite(seg) doesn’t
+include the trace, but SegGrey(seg) does), because the new objects
+would become grey as the buffer’s ScanLimit advanced. However, in many
+configurations, the mutator would hit a barrier as soon as it started
+initializing the object, which would flip the buffer. In fact, the
+current (2002-01) implementation of buffers assumes buffers are black,
+so they’d better.
                                                                                                                    
+
                                                                                                                    .fill.colour.reclaim: In fact, putting a buffer on a condemned
+segment will screw up the accounting in AMCReclaim(), so it’s
+disallowed.
                                                                                                                    
+
                                                                                                                    .fill.slow: AMSBufferFill() gets progressively slower as more
+segments fill up, as it laboriously checks whether the buffer can be
+refilled from each segment, by inspecting the allocation bit map. This
+is helped a bit by keeping count of free grains in each segment, but
+it still spends a lot of time iterating over all the full segments
+checking the free size. Obviously, this can be much improved (we could
+keep track of the largest free block in the segment and in the pool,
+or we could keep the segments in some more efficient structure, or we
+could have a real free list structure).
                                                                                                                    
+
                                                                                                                    .fill.extend: If there’s no space in any existing segment, the
+segSize method is called to decide the size of the new segment to
+allocate. If that fails, the code tries to allocate a segment that’s
+just large enough to satisfy the request.
                                                                                                                    
+
                                                                                                                    .empty: AMSBufferEmpty() makes the unused space free, since
+there’s no reason not to. We have to adjust the colour tables as well,
+since these grains were black and now they need to be white (or at
+least encoded -G and W).
                                                                                                                    
+
                                                                                                                    .reclaim.empty.buffer: Segments which after reclaim only contain a
+buffer could be destroyed by trapping the buffer, but there’s no point
+to this.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.5.5. Initialization
                                                                                                                    
+
                                                                                                                    .init: The initialization method AMSInit() takes three
+additional arguments: the format of objects allocated in the pool, the
+chain that controls GC timing, and a flag for supporting ambiguous
+references.
                                                                                                                    
+
                                                                                                                    .init.share: If support for ambiguity is required, the
+shareAllocTable flag is reset to indicate the pool uses three
+separate bit tables, otherwise it is set and the pool shares a table
+for non-white and alloc (see .colour.encoding).
                                                                                                                    
+
                                                                                                                    .init.align: The pool alignment is set equal to the format
+alignment (see design.mps.align).
                                                                                                                    
+
                                                                                                                    .init.internal: Subclasses call AMSInitInternal() to avoid the
+problems of sharing va_list and emitting a superfluous
+PoolInitAMS event.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.5.6. Condemnation
                                                                                                                    
+
                                                                                                                    .condemn.buffer: Buffers are not condemned, instead they are
+coloured black, to make sure that the objects allocated will be black,
+following .colour.alloc (or, if you wish, because buffers are
+ignored like free space, so need the same encoding).
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.5.7. Reclaim
                                                                                                                    
+
                                                                                                                    .reclaim: Reclaim uses either of analysis.non-moving-colour
+.constraint.reclaim.white-free-bit (just reuse the non-white table as
+the alloc table) or
+analysis.non-moving-colour.constraint.reclaim.free-bit (copy it),
+depending on the shareAllocTable flag (as set by .init.share).
+However, bit table still has to be iterated over to count the free
+grains. Also, in a debug pool, each white block has to be splatted.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.5.8. Segment merging and splitting
                                                                                                                    
+
                                                                                                                    .split-merge: We provide methods for splitting and merging AMS
+segments. The pool implementation doesn’t cause segments to be split
+or merged – but a subclass might want to do this (see
+.stress.split-merge). The methods serve as an example of how to
+implement this facility.
                                                                                                                    
+
                                                                                                                    .split-merge.constrain: There are some additional constraints on
+what segments may be split or merged:
                                                                                                                    
+
                                                                                                                      
+
                                                                                                                    • .split-merge.constrain.align: Segments may only be split or
+merged at an address which is aligned to the pool alignment as well
+as to the arena alignment.
                                                                                                                      
+
                                                                                                                      .split-merge.constrain.align.justify: This constraint is implied
+by the design of allocation and colour tables, which cannot
+represent segments starting at unaligned addresses. The constraint
+only arises if the pool alignment is larger than the arena
+alignment. There’s no requirement to split segments at unaligned
+addresses.
                                                                                                                      
+
                                                                                                                      • 
+
                                                                                                                    • .split-merge.constrain.empty: The higher segment must be empty.
+That is, the higher segment passed to SegMerge() must be empty,
+and the higher segment returned by SegSplit() must be empty.
                                                                                                                      
+
                                                                                                                      .split-merge.constrain.empty.justify: This constraint makes the
+code significantly simpler. There’s no requirement for a more
+complex solution at the moment (as the purpose is primarily
+pedagogic).
                                                                                                                      
+
                                                                                                                      • 
+
                                                                                                                    
+
                                                                                                                    .split-merge.fail: The split and merge methods are not proper
+anti-methods for each other (see
+design.mps.seg.split-merge.fail.anti.no). Methods will not reverse the
+side-effects of their counterparts if the allocation of the colour and
+allocation bit tables should fail. Client methods which over-ride
+split and merge should not be written in such a way that they might
+detect failure after calling the next method, unless they have reason
+to know that the bit table allocations will not fail.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.6. Testing
                                                                                                                    
+
                                                                                                                    .stress: There’s a stress test, MMsrc!amsss.c, that does 800 kB of
+allocation, enough for about three GCs. It uses a modified Dylan
+format, and checks for corruption by the GC. Both ambiguous and exact
+roots are tested.
                                                                                                                    
+
                                                                                                                    .stress.split-merge: There’s also a stress test for segment
+splitting and merging, MMsrc!segsmss.c. This is similar to amsss.c –
+but it defines a subclass of AMS, and causes segments to be split and
+merged. Both buffered and non-buffered segments are split / merged.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    22.7. Notes
                                                                                                                    
+
                                                                                                                    .addr-index.slow: Translating from an address to and from a grain
+index in a segment uses macros such as AMS_INDEX and
+AMS_INDEX_ADDR. These are slow because they call SegBase() on
+every translation – we could cache that.
                                                                                                                    
+
                                                                                                                    .grey-mutator: To enforce the restriction set in .not-req.grey
+we check that all the traces are flipped in AMSScan(). It would be
+good to check in AMSFix() as well, but we can’t do that, because
+it’s called during the flip, and we can’t tell the difference between
+the flip and the grey mutator phases with the current tracer
+interface.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
+
+          
                                                                                                                    
+        
                                                                                                                    
+      
                                                                                                                    
+      
                                                                                                                    
+        
                                                                                                                    
+            
+  
                                                                                                                    Table Of Contents
                                                                                                                    
+  
+
+  
                                                                                                                    Previous topic
                                                                                                                    
+  
                                                                                                                    21. AMC pool class
                                                                                                                    
+  
                                                                                                                    Next topic
                                                                                                                    
+  
                                                                                                                    23. AWL pool class
                                                                                                                    Downloads
                                                                                                                    
+
+
                                                                                                                    
+MPS Kit release 1.111.0
                                                                                                                    
+All MPS Kit releases
+
                                                                                                                    
+
+
                                                                                                                    Issues
                                                                                                                    
+
+
                                                                                                                    
+Known issues
                                                                                                                    
+Issues fixed in release 1.111.0
+
                                                                                                                    Contact us
                                                                                                                    
+
+
                                                                                                                    mps-questions@ravenbrook.com
                                                                                                                    
+        
                                                                                                                    
+      
                                                                                                                    
+      
                                                                                                                    
+    
                                                                                                                    
+    
                                                                                                                    
+      
                                                                                                                    Navigation
                                                                                                                    
+      
+    
                                                                                                                    
+    
                                                                                                                    
+        © Copyright 2013, Ravenbrook Limited.
+      Created using Sphinx 1.1.3.
+    
                                                                                                                    
+  
+
\ No newline at end of file
diff --git a/mps/manual/html/design/poolawl.html b/mps/manual/html/design/poolawl.html
new file mode 100644
index 00000000000..802b1b8910e
--- /dev/null
+++ b/mps/manual/html/design/poolawl.html
@@ -0,0 +1,608 @@
+
+
+
+
+
+
+  
+    
+    
+    23. AWL pool class — Memory Pool System 1.111.0 documentation
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+     
+  
+  
+    
                                                                                                                    
+      
                                                                                                                    Navigation
                                                                                                                    
+      
+    
                                                                                                                      
+
+    
                                                                                                                    
+      
                                                                                                                    
+        
                                                                                                                    
+          
                                                                                                                    
+            
+  
                                                                                                                    
+
                                                                                                                    23. AWL pool class
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    23.1. Introduction
                                                                                                                    
+
                                                                                                                    .readership: Any MPS developer.
                                                                                                                    
+
                                                                                                                    .intro: The AWL (Automatic Weak Linked) pool is used to manage
+Dylan Weak Tables (see req.dylan.fun.weak). Currently the design is
+specialised for Dylan Weak Tables, but it could be generalised in the
+future.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    23.2. Requirements
                                                                                                                    
+
                                                                                                                    See req.dylan.fun.weak.
                                                                                                                    
+
                                                                                                                    See meeting.dylan.1997-02-27(0) where many of the requirements for
+this pool were first sorted out.
                                                                                                                    
+
                                                                                                                    Must satisfy request.dylan.170123.
                                                                                                                    
+
                                                                                                                    .req.obj-format: Only objects of a certain format need be
+supported. This format is a subset of the Dylan Object Format. The
+pool uses the first slot in the fixed part of an object to store an
+association. See mail.drj.1997-03-11.12-05
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    23.3. Definitions
                                                                                                                    
+
                                                                                                                    .def.grain: alignment grain, grain. A grain is a range of addresses
+where both the base and the limit of the range are aligned and the
+size of range is equal to the (same) alignment. In this context the
+alignment is the pool’s alignment (pool->alignment). The grain is
+the unit of allocation, marking, scanning, etc.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    23.4. Overview
                                                                                                                    
+
                                                                                                                    .overview:
                                                                                                                    
+
                                                                                                                    .overview.ms: The pool is mark and sweep. .overview.ms.justify:
+Mark-sweep pools are slightly easier to write (than moving pools), and
+there are no requirements (yet) that this pool be high performance or
+moving or anything like that.
                                                                                                                    
+
                                                                                                                    .overview.alloc: It is possible to allocate weak or exact objects
+using the normal reserve/commit AP protocol.
+.overview.alloc.justify: Allocation of both weak and exact objects
+is required to implement Dylan Weak Tables. Objects are formatted; the
+pool uses format A.
                                                                                                                    
+
                                                                                                                    .overview.scan: The pool handles the scanning of weak objects
+specially so that when a weak reference is deleted the corresponding
+reference in an associated object is deleted. The associated object is
+determined by using information stored in the object itself (see
+.req.obj-format).
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    23.5. Interface
                                                                                                                    
+
                                                                                                                    .if.init: The init method takes one extra parameter in the vararg
+list. This parameter should have type Format and be a format
+object that describes the format of the objects to be allocated in
+this pool. The format should support scan and skip methods. There is
+an additional restriction on the layout of objects, see
+.req.obj-format.
                                                                                                                    
+
                                                                                                                    .if.buffer: The BufferInit() method takes one extra parameter
+in the vararg list. This parameter should be either RankEXACT or
+RankWEAK. It determines the rank of the objects allocated using
+that buffer.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    23.6. Data structures
                                                                                                                    
+
                                                                                                                    .sig: This signature for this pool will be 0x519bla3l (SIGPooLAWL).
                                                                                                                    
+
                                                                                                                    .poolstruct: The class specific pool structure is:
                                                                                                                    
+
                                                                                                                    struct AWLStruct {
+  PoolStruct poolStruct;
+  Format format;
+  Shift alignShift;
+  ActionStruct actionStruct;
+  double lastCollected;
+  Serial gen;
+  Sig sig;
+}
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    .poolstruct.format: The format field is used to refer to the object
+format. The object format is passed to the pool during pool creation.
                                                                                                                    
+
                                                                                                                    .poolstruct.alignshift: The alignShift field is the
+SizeLog2 of the pool’s alignment. It is computed and initialised
+when a pool is created. It is used to compute the number of alignment
+grains in a segment which is the number of bits need in the segment’s
+mark and alloc bit table (see .awlseg.bt, .awlseg.mark, and
+.awlseg.alloc below).
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    Note
                                                                                                                    
+
                                                                                                                    Clarify this.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    .poolstruct.actionStruct: Contains an Action which is used to
+participate in the collection benefit protocol. See AWLBenefit()
+below for a description of the algorithm used for determining when to
+collect.
                                                                                                                    
+
                                                                                                                    .poolstruct.lastCollected: Records the time (using the mutator
+total allocation clock, ie that returned by
+ArenaMutatorAllocSize()) of the most recent call to either
+AWLInit() or AWLTraceBegin() for this pool. So this is the
+time of the beginning of the last collection of this pool. Actually
+this isn’t true because the pool can be collected without
+AWLTraceBegin() being called (I think) as it will get collected by
+being in the same zone as another pool/generation that is being
+collected (which it does arrange to be, see the use of the gen field
+in .poolstruct.gen below and .fun.awlsegcreate.where below).
                                                                                                                    
+
                                                                                                                    .poolstruct.gen: This part of the mechanism by which the pool
+arranges to be in a particular zone and arranges to be collected
+simultaneously with other cohorts in the system. gen is the
+generation that is used in expressing a generation preference when
+allocating a segment. The intention is that this pool will get
+collected simultaneously with any other segments that are also
+allocated using this generation preference (when using the VM arena,
+generation preferences get mapped more or less to zones, each
+generation to a unique set of zones in the ideal case). Whilst AWL is
+not generational it is expected that this mechanism will arrange for
+it to be collected simultaneously with some particular generation of
+AMC.
                                                                                                                    
+
                                                                                                                    .poolstruct.gen.1: At the moment the gen field is set for all
+AWL pools to be 1.
                                                                                                                    
+
                                                                                                                    .awlseg: The pool defines a segment class AWLSegClass, which is
+a subclass of GCSegClass (see
+design.mps.seg.over.hierarchy.gcseg). All segments allocated by the
+pool are instances of this class, and are of type AWLSeg, for
+which the structure is:
                                                                                                                    
+
                                                                                                                    struct AWLSegStruct {
+  GCSegStruct gcSegStruct;
+  BT mark;
+  BT scanned;
+  BT alloc;
+  Count grains;
+  Count free;
+  Count singleAccesses;
+  AWLStatSegStruct stats;
+  Sig sig;
+}
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    .awlseg.bt: The mark, alloc, and scanned fields are bit-tables (see
+design.mps.bt). Each bit in the table corresponds to a a single
+alignment grain in the pool.
                                                                                                                    
+
                                                                                                                    .awlseg.mark: The mark bit table is used to record mark bits during
+a trace. AWLCondemn() (see .fun.condemn below) sets all the
+bits of this table to zero. Fix will read and set bits in this table.
+Currently there is only one mark bit table. This means that the pool
+can only be condemned for one trace.
                                                                                                                    
+
                                                                                                                    .awlseg.mark.justify: This is simple, and can be improved later
+when we want to run more than one trace.
                                                                                                                    
+
                                                                                                                    .awlseg.scanned: The scanned bit-table is used to note which
+objects have been scanned. Scanning (see .fun.scan below) a segment
+will find objects that are marked but not scanned, scan each object
+found and set the corresponding bits in the scanned table.
                                                                                                                    
+
                                                                                                                    .awlseg.alloc: The alloc bit table is used to record which portions
+of a segment have been allocated. Ranges of bits in this table are set
+when a buffer is attached to the segment. When a buffer is flushed (ie
+AWLBufferEmpty() is called) from the segment, the bits
+corresponding to the unused portion at the end of the buffer are
+reset.
                                                                                                                    
+
                                                                                                                    .awlseg.alloc.invariant: A bit is set in the alloc table if and
+only if the corresponding address is currently being buffered, or the
+corresponding address lies within the range of an allocated object.
                                                                                                                    
+
                                                                                                                    .awlseg.grains: The grains field is the number of grains that fit
+in the segment. Strictly speaking this is not necessary as it can be
+computed from SegSize and AWL’s alignment, however, precalculating
+it and storing it in the segment makes the code simpler by avoiding
+lots of repeated calculations.
                                                                                                                    
+
                                                                                                                    .awlseg.free: A conservative estimate of the number of free grains
+in the segment. It is always guaranteed to be greater than or equal to
+the number of free grains in the segment, hence can be used during
+allocation to quickly pass over a segment.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    Note
                                                                                                                    
+
                                                                                                                    Maintained by blah and blah. Unfinished obviously.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    23.7. Functions
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    Note
                                                                                                                    
+
                                                                                                                    How will pool collect? It needs an action structure.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    23.7.1. External
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Res AWLInit(Pool pool, va_list arg)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.init: AWLStruct has four fields, each one needs initializing.
                                                                                                                    
+
                                                                                                                    .fun.init.poolstruct: The poolStruct field has already been
+initialized by generic code (impl.c.pool).
                                                                                                                    
+
                                                                                                                    .fun.init.format: The format will be copied from the argument list,
+checked, and written into this field.
                                                                                                                    
+
                                                                                                                    .fun.init.alignshift: The alignShift will be computed from the
+pool alignment and written into this field.
                                                                                                                    
+
                                                                                                                    .fun.init.sig: The sig field will be initialized with the
+signature for this pool.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Res AWLFinish(Pool pool)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.finish: Iterates over all segments in the pool and destroys
+each segment (by calling SegFree()). Overwrites the sig field in
+the AWLStruct. Finishing the generic pool structure is done by the
+generic pool code (impl.c.pool).
                                                                                                                    
+
                                                                                                                    .fun.alloc: PoolNoAlloc() will be used, as this class does not
+implement alloc.
                                                                                                                    
+
                                                                                                                    .fun.free: PoolNoFree() will be used, as this class does not
+implement free.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Res AWLBufferFill(Seg *segReturn, Addr *baseReturn, Pool pool, Buffer buffer, Size size)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.fill: This zips round all the the segments applying
+AWLSegAlloc() to each segment that has the same rank as the
+buffer. AWLSegAlloc() attempts to find a free range, if it finds a
+range then it may be bigger than the actual request, in which case the
+remainder can be used to “fill” the rest of the buffer. If no free
+range can be found in an existing segment then a new segment will be
+created (which is at least large enough). The range of buffered
+addresses is marked as allocated in the segment’s alloc table.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+void AWLBufferEmpty(Pool pool, Buffer buffer)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.empty: Locates the free portion of the buffer, that is the
+memory between the init and the limit of the buffer and records these
+locations as being free in the relevant alloc table. The segment that
+the buffer is pointing at (which contains the alloc table that needs
+to be dinked with) is available via BufferSeg().
                                                                                                                    
+
                                                                                                                    .fun.benefit: The benefit returned is the total amount of mutator
+allocation minus the lastRembemberedSize minus 10 MiB, so the pool
+becomes an increasingly good candidate for collection at a constant
+(mutator allocation) rate, crossing the 0 line when there has been
+10 MiB of allocation since the (beginning of the) last collection. So
+it gets collected approximately every 10 MiB of allocation. Note that
+it will also get collected by virtue of being in the same zone as some
+AMC generation (assuming there are instantiated AMC pools), see
+.poolstruct.gen above.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Res AWLCondemn(Pool pool, Trace trace, Seg seg)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.condemn: The current design only permits each segment to be
+condemned for one trace (see .awlseg.mark). This function checks
+that the segment is not condemned for any trace (seg->white ==
+TraceSetEMPTY). The segment’s mark bit-table is reset, and the
+whiteness of the seg (seg->white) has the current trace added to
+it.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+void AWLGrey(Pool pool, Trace trace, Seg seg)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.grey: If the segment is not condemned for this trace the
+segment’s mark table is set to all 1s and the segment is recorded as
+being grey.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Res AWLScan(ScanState ss, Pool pool, Seg seg)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.scan:
                                                                                                                    
+
                                                                                                                    .fun.scan.overview: The scanner performs a number of passes over
+the segment, scanning each marked and unscanned (grey) object that is
+finds.
                                                                                                                    
+
                                                                                                                    .fun.scan.overview.finish: It keeps perform a pass over the segment
+until it is finished.
                                                                                                                    
+
                                                                                                                    .fun.scan.overview.finish.condition: A condition for finishing is
+that no new marks got placed on objects in this segment during the
+pass.
                                                                                                                    
+
                                                                                                                    .fun.scan.overview.finish.approximation: We use an even stronger
+condition for finishing that assumes that scanning any object may
+introduce marks onto this segment. It is finished when a pass results
+in scanning no objects (that is, all objects were either unmarked or
+both marked and scanned).
                                                                                                                    
+
                                                                                                                    .fun.scan.overview.finished-flag: There is a flag called
+finished which keeps track of whether we should finish or not. We
+only ever finish at the end of a pass. At the beginning of a pass the
+flag is set. During a pass if any objects are scanned then the
+finished flag is reset. At the end of a pass if the finished
+flag is still set then we are finished. No more passes take place and
+the function returns.
                                                                                                                    
+
                                                                                                                    .fun.scan.pass: A pass consists of a setup phase and a repeated
+phase.
                                                                                                                    
+
                                                                                                                    .fun.scan.pass.buffer: The following assumes that in the general
+case the segment is buffered; if the segment is not buffered then the
+actions that mention buffers are not taken (they are unimportant if
+the segment is not buffered).
                                                                                                                    
+
                                                                                                                    .fun.scan.pass.p: The pass uses a cursor called p to progress
+over the segment. During a pass p will increase from the base
+address of the segment to the limit address of the segment. When p
+reaches the limit address of the segment, the pass in complete.
                                                                                                                    
+
                                                                                                                    .fun.scan.pass.setup: p initially points to the base address of
+the segment.
                                                                                                                    
+
                                                                                                                    .fun.scan.pass.repeat: The following comprises the repeated phase.
+The repeated phase is repeated until the pass completion condition is
+true (that is, p has reached the limit of the segment, see
+.fun.scan.pass.p above and .fun.scan.pass.repeat.complete
+below).
                                                                                                                    
+
                                                                                                                    .fun.scan.pass.repeat.complete: If p is equal to the segment’s
+limit then we are done. We proceed to check whether any further passes
+need to be performed (see .fun.scan.pass.more below).
                                                                                                                    
+
                                                                                                                    .fun.scan.pass.repeat.free: If !alloc(p) (the grain is free)
+then increment p and return to the beginning of the loop.
                                                                                                                    
+
                                                                                                                    .fun.scan.pass.repeat.buffer: If p is equal to the buffer’s
+ScanLimit, as returned by BufferScanLimit(), then set p equal
+to the buffer’s Limit, as returned by BufferLimit() and return to
+the beginning of the loop.
                                                                                                                    
+
                                                                                                                    .fun.scan.pass.repeat.object-end: The end of the object is located
+using the format->skip method.
                                                                                                                    
+
                                                                                                                    .fun.scan.pass.repeat.object: if mark(p) && !scanned(p) then
+the object pointed at is marked but not scanned, which means we must
+scan it, otherwise we must skip it.
                                                                                                                    
+
                                                                                                                    .fun.scan.pass.repeat.object.dependent: To scan the object the
+object we first have to determine if the object has a dependent object (see
+.req.obj-format).
                                                                                                                    
+
                                                                                                                    .fun.scan.pass.repeat.object.dependent.expose: If it has a
+dependent object then we must expose the segment that the dependent
+object is on (only if the dependent object actually points to MPS
+managed memory) prior to scanning and cover the segment subsequent to
+scanning.
                                                                                                                    
+
                                                                                                                    .fun.scan.pass.repeat.object.dependent.summary: The summary of the
+dependent segment must be set to RefSetUNIV to reflect the fact
+that we are allowing it to be written to (and we don’t know what gets
+written to the segment).
                                                                                                                    
+
                                                                                                                    .fun.scan.pass.repeat.object.scan: The object is then scanned by
+calling the format’s scan method with base and limit set to the
+beginning and end of the object (.fun.scan.scan.improve.single: A
+scan1 format method would make it slightly simpler here). Then the
+finished flag is cleared and the bit in the segment’s scanned table is
+set.
                                                                                                                    
+
                                                                                                                    .fun.scan.pass.repeat.advance: p is advanced past the object
+and we return to the beginning of the loop.
                                                                                                                    
+
                                                                                                                    .fun.scan.pass.more: At the end of a pass the finished flag is
+examined.
                                                                                                                    
+
                                                                                                                    .fun.scan.pass.more.not: If the finished flag is set then we are
+done (see .fun.scan.overview.finished-flag above), AWLScan()
+returns.
                                                                                                                    
+
                                                                                                                    .fun.scan.pass.more.so: Otherwise (the finished flag is reset) we
+perform another pass (see .fun.scan.pass above).
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Res AWLFix(Pool pool, ScanState ss, Seg seg, Ref *refIO)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.fix: ss->wasMarked is set to TRUE (clear compliance
+with design.mps.fix.protocol.was-marked.conservative).
                                                                                                                    
+
                                                                                                                    If the rank (ss->rank) is RankAMBIG then fix returns
+immediately unless the reference is aligned to the pool alignment.
                                                                                                                    
+
                                                                                                                    If the rank (ss->rank) is RankAMBIG then fix returns
+immediately unless the referenced grain is allocated.
                                                                                                                    
+
                                                                                                                    The bit in the marked table corresponding to the referenced grain will
+be read. If it is already marked then fix returns. Otherwise (the
+grain is unmarked), ss->wasMarked is set to FALSE, the
+remaining actions depend on whether the rank (ss->rank) is
+RankWEAK or not. If the rank is weak then the reference is
+adjusted to 0 (see design.mps.weakness) and fix returns. If the rank
+is something else then the mark bit corresponding to the referenced
+grain is set, and the segment is greyed using TraceSegGreyen().
                                                                                                                    
+
                                                                                                                    Fix returns.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+void AWLReclaim(Pool pool, Trace trace, Seg seg)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.reclaim: This iterates over all allocated objects in the
+segment and frees objects that are not marked. When this iteration is
+complete the marked array is completely reset.
                                                                                                                    
+
                                                                                                                    p points to base of segment. Then:
                                                                                                                    
+
                                                                                                                    while(p < SegLimit(seg) {
+  if(!alloc(p)) { ++p;continue; }
+  q = skip(p) /* q points to just past the object pointed at by p */
+  if !marked(p) free(p, q); /* reset the bits in the alloc table from p to q-1 inclusive. */
+  p = q
+}
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    Finally, reset the entire marked array using BTResRange().
                                                                                                                    
+
                                                                                                                    .fun.reclaim.improve.pad: Consider filling free ranges with padding
+objects. Now reclaim doesn’t need to check that the objects are
+allocated before skipping them. There may be a corresponding change
+for scan as well.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Res AWLDescribe(Pool pool, mps_lib_FILE *stream)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.describe:
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    23.7.2. Internal
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Res AWLSegCreate(AWLSeg *awlsegReturn, Size size)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.awlsegcreate: Creates a segment of class AWLSegClass of size at least size.
                                                                                                                    
+
                                                                                                                    .fun.awlsegcreate.size.round: size is rounded up to an
+ArenaAlign before requesting the segment.
+.fun.awlsegcreate.size.round.justify: The arena requires that all
+segment sizes are aligned to the ArenaAlign.
                                                                                                                    
+
                                                                                                                    .fun.awlsegcreate.where: The segment is allocated using a
+generation preference, using the generation number stored in the
+AWLStruct (the gen field), see .poolstruct.gen above.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Res awlSegInit(Seg seg, Pool pool, Addr base, Size size, Bool reservoirPermit, va_list args)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.awlseginit: Init method for AWLSegClass, called for
+SegAlloc() whenever an AWLSeg is created (see
+.fun.awlsegcreate above).
                                                                                                                    
+
                                                                                                                    .fun.awlseginit.tables: The segment’s mark scanned and alloc tables
+(see .awlseg.bt above) are allocated and initialised. The segment’s
+grains field is computed and stored.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+void awlSegFinish(Seg seg)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.awlsegfinish: Finish method for AWLSegClass, called from
+SegFree(). Will free the segment’s tables (see .awlseg.bt).
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Bool AWLSegAlloc(Addr *baseReturn, Addr *limitReturn, AWLSeg awlseg, AWL awl, Size size)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.awlsegalloc: Will search for a free block in the segment that
+is at least size bytes long. The base address of the block is returned
+in *baseReturn, the limit of the entire free block (which must be
+at least as large size and may be bigger) is returned in
+*limitReturn. The requested size is converted to a number of
+grains, BTFindResRange() is called to find a run of this length in
+the alloc bit-table (.awlseg.alloc). The return results (if it is
+successful) from BTFindResRange() are in terms of grains, they are
+converted back to addresses before returning the relevant values from
+this function.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Bool AWLDependentObject(Addr *objReturn, Addr parent)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.dependent-object: This function abstracts the association
+between an object and its linked dependent (see .req.obj-format).
+It currently assumes that objects are Dylan Object formatted according
+to design.dylan.container (see analysis.mps.poolawl.dependent.abstract
+for suggested improvements). An object has a dependent object iff the
+second word of the object, that is, ((Word *)parent)[1], is
+non-NULL. The dependent object is the object referenced by the
+second word and must be a valid object.
                                                                                                                    
+
                                                                                                                    This function assumes objects are in Dylan Object Format (see
+design.dylan.container). It will check that the first word looks like
+a Dylan wrapper pointer. It will check that the wrapper indicates that
+the wrapper has a reasonable format (namely at least one fixed field).
+If the second word is NULL it will return FALSE. If the second
+word is non-NULL then the contents of it will be assigned to
+*objReturn, and it will return TRUE.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    23.8. Test
                                                                                                                    
+
                                                                                                                      
+
                                                                                                                    • must create Dylan objects.
                                                                                                                      • 
+
                                                                                                                    • must create Dylan vectors with at least one fixed field.
                                                                                                                      • 
+
                                                                                                                    • must allocate weak thingies.
                                                                                                                      • 
+
                                                                                                                    • must allocate exact tables.
                                                                                                                      • 
+
                                                                                                                    • must link tables together.
                                                                                                                      • 
+
                                                                                                                    • must populate tables with junk.
                                                                                                                      • 
+
                                                                                                                    • some junk must die.
                                                                                                                      • 
+
                                                                                                                    
+
                                                                                                                    Use an LO pool and an AWL pool. Three buffers. One buffer for the LO
+pool, one exact buffer for the AWL pool, one weak buffer for the AWL
+pool.
                                                                                                                    
+
                                                                                                                    Initial test will allocate one object from each buffer and then
+destroy all buffers and pools and exit
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
+
+          
                                                                                                                    
+        
                                                                                                                    
+      
                                                                                                                    
+      
                                                                                                                    
+        
                                                                                                                    
+            
+  
                                                                                                                    Table Of Contents
                                                                                                                    
+  
+
+  
                                                                                                                    Previous topic
                                                                                                                    
+  
                                                                                                                    22. AMS pool class
                                                                                                                    
+  
                                                                                                                    Next topic
                                                                                                                    
+  
                                                                                                                    24. LO pool class
                                                                                                                    Downloads
                                                                                                                    
+
+
                                                                                                                    
+MPS Kit release 1.111.0
                                                                                                                    
+All MPS Kit releases
+
                                                                                                                    
+
+
                                                                                                                    Issues
                                                                                                                    
+
+
                                                                                                                    
+Known issues
                                                                                                                    
+Issues fixed in release 1.111.0
+
                                                                                                                    Contact us
                                                                                                                    
+
+
                                                                                                                    mps-questions@ravenbrook.com
                                                                                                                    
+        
                                                                                                                    
+      
                                                                                                                    
+      
                                                                                                                    
+    
                                                                                                                    
+    
                                                                                                                    
+      
                                                                                                                    Navigation
                                                                                                                    
+      
+    
                                                                                                                    
+    
                                                                                                                    
+        © Copyright 2013, Ravenbrook Limited.
+      Created using Sphinx 1.1.3.
+    
                                                                                                                    
+  
+
\ No newline at end of file
diff --git a/mps/manual/html/design/poollo.html b/mps/manual/html/design/poollo.html
new file mode 100644
index 00000000000..3c67da42568
--- /dev/null
+++ b/mps/manual/html/design/poollo.html
@@ -0,0 +1,328 @@
+
+
+
+
+
+
+  
+    
+    
+    24. LO pool class — Memory Pool System 1.111.0 documentation
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+     
+  
+  
+    
                                                                                                                    
+      
                                                                                                                    Navigation
                                                                                                                    
+      
+    
                                                                                                                      
+
+    
                                                                                                                    
+      
                                                                                                                    
+        
                                                                                                                    
+          
                                                                                                                    
+            
+  
                                                                                                                    
+
                                                                                                                    24. LO pool class
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    24.1. Introduction
                                                                                                                    
+
                                                                                                                    .readership: Any MPS developer.
                                                                                                                    
+
                                                                                                                    .intro: The LO (Leaf Object) pool class is a pool class developed
+for DylanWorks. It is designed to manage objects that have no
+references (leaf objects) such as strings, bit tables, etc. It is a
+garbage collected pool (in that objects allocated in the pool are
+automatically reclaimed when they are discovered to be unreachable.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    Note
                                                                                                                    
+
                                                                                                                    Need to sort out issue of alignment. Currently lo grabs alignment
+from format, almost certainly “ought” to use the greater of the
+format alignment and the MPS_ALIGN value. David Jones,
+1997-07-02.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    24.2. Definitions
                                                                                                                    
+
                                                                                                                    .def.leaf: A “leaf” object is an object that contains no
+references, or an object all of whose references refer to roots. That
+is, any references that the object has must refer to a priori alive
+objects that are guaranteed not to move, hence the references do not
+need fixing.
                                                                                                                    
+
                                                                                                                    .def.grain: A grain (of some alignment) is a contiguous aligned
+area of memory of the smallest size possible (which is the same size
+as the alignment).
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    24.3. Requirements
                                                                                                                    
+
                                                                                                                    .req.source: See req.dylan.fun.obj.alloc and
+req.dylan.prot.ffi.access.
                                                                                                                    
+
                                                                                                                    .req.leaf: The pool must manage formatted leaf objects (see
+.def.leaf above for a definition). This is intended to encompass
+Dylan and C leaf objects. Dylan leaf objects have a reference to their
+wrapper, but are still leaf objects (in the sense of .def.leaf)
+because the wrapper will be a root.
                                                                                                                    
+
                                                                                                                    .req.nofault: The memory containing objects managed by the pool
+must not be protected. The client must be allowed to access these
+objects without using the MPS trampoline (the exception mechanism,
+q.v.).
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    24.4. Overview
                                                                                                                    
+
                                                                                                                    .overview:
                                                                                                                    
+
                                                                                                                    .overview.ms: The LO Pool is a non-moving mark-and-sweep collector.
                                                                                                                    
+
                                                                                                                    .overview.ms.justify: Mark-and-sweep pools are simpler than moving
+pools.
                                                                                                                    
+
                                                                                                                    .overview.alloc: Objects are allocated in the pool using the
+reserve/commit protocol on allocation points.
                                                                                                                    
+
                                                                                                                    .overview.format: The pool is formatted. The format of the objects
+in the pool is specified at instantiation time, using an format object
+derived from a variant A format (using variant A is overkill, see
+.if.init below) (see design.mps.format for excuse about calling the
+variant ‘A’).
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    24.5. Interface
                                                                                                                    
+
                                                                                                                    .if.init:
                                                                                                                    
+
                                                                                                                    .if.init.args: The init method for this class takes one extra
+parameter in the vararg parameter list.
                                                                                                                    
+
                                                                                                                    .if.init.format: The extra parameter should be an object of type
+Format and should describe the format of the objects that are to be
+allocated in the pool.
                                                                                                                    
+
                                                                                                                    .if.init.format.use: The pool uses the skip and alignment slots of
+the format. The skip method is used to determine the length of objects
+(during reclaim). The alignment field is used to determine the
+granularity at which memory should be managed.
                                                                                                                    
+
                                                                                                                    .if.init.format.a: Currently only format variant A is supported
+though clearly that is overkill as only skip and alignment are used.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    24.6. Data structures
                                                                                                                    
+
                                                                                                                    .sig: The signature for the LO Pool Class is 0x51970b07
+(SIGLOPOoL).
                                                                                                                    
+
                                                                                                                    .poolstruct: The class specific pool structure is:
                                                                                                                    
+
                                                                                                                    typedef struct LOStruct {
+  PoolStruct poolStruct;        /* generic pool structure */
+  Format format;                /* format for allocated objects */
+  Shift alignShift;
+  Sig sig;                      /* impl.h.misc.sig */
+} LOStruct;
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    .poolstruct.format: This is the format of the objects that are
+allocated in the pool.
                                                                                                                    
+
                                                                                                                    .poolstruct.alignShift: This is shift used in alignment
+computations. It is SizeLog2(pool->alignment). It can be used on
+the right of a shift operator (<< or >>) to convert between a
+number of bytes and a number of grains.
                                                                                                                    
+
                                                                                                                    .loseg: Every segment is an instance of segment class LOSegClass, a
+subclass of GCSegClass, and is an object of type LOSegStruct.
                                                                                                                    
+
                                                                                                                    .loseg.purpose: The purpose of the LOSeg structure is to
+associate the bit tables used for recording allocation and mark
+information with the segment.
                                                                                                                    
+
                                                                                                                    .loseg.decl: The declaration of the structure is as follows:
                                                                                                                    
+
                                                                                                                    typedef struct LOSegStruct {
+  GCSegStruct gcSegStruct;  /* superclass fields must come first */
+  LO lo;                    /* owning LO */
+  BT mark;                  /* mark bit table */
+  BT alloc;                 /* alloc bit table */
+  Count free;               /* number of free grains */
+  Sig sig;                  /* impl.h.misc.sig */
+} LOSegStruct;
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    .loseg.sig: The signature for a loseg is 0x519705E9 (SIGLOSEG).
                                                                                                                    
+
                                                                                                                    .loseg.lo: The lo field points to the LO structure that owns this
+segment.
                                                                                                                    
+
                                                                                                                    .loseg.bit: Bit Tables (see design.mps.bt) are used to record
+allocation and mark information. This is relatively straightforward,
+but might be inefficient in terms of space in some circumstances.
                                                                                                                    
+
                                                                                                                    .loseg.mark: This is a Bit Table that is used to mark objects
+during a trace. Each grain in the segment is associated with 1 bit in
+this table. When LOFix() (see .fun.fix below) is called the
+address is converted to a grain within the segment and the
+corresponding bit in this table is set.
                                                                                                                    
+
                                                                                                                    .loseg.alloc: This is a Bit Table that is used to record which
+addresses are allocated. Addresses that are allocated and are not
+buffered have their corresponding bit in this table set. If a bit in
+this table is reset then either the address is free or is being
+buffered.
                                                                                                                    
+
                                                                                                                    .loseg.diagram: The following diagram is now obsolete. It’s also
+not very interesting - but I’ve left the sources in case anyone ever
+gets around to updating it. tony 1999-12-16
                                                                                                                    
+
                                                                                                                    [missing diagram]
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    24.7. Functions
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    24.7.1. External
                                                                                                                    
+
                                                                                                                    .fun.init:
                                                                                                                    
+
                                                                                                                    .fun.destroy:
                                                                                                                    
+
                                                                                                                    .fun.buffer-fill:
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    Note
                                                                                                                    
+
                                                                                                                    Explain way in which buffers interact with the alloc table and how
+it could be improved.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    .fun.buffer-empty:
                                                                                                                    
+
                                                                                                                    .fun.condemn:
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Res LOFix(Pool pool, ScanState ss, Seg seg, Ref *refIO)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.fix: Fix treats references of most ranks much the same. There
+is one mark table that records all marks. A reference of rank
+RankAMBIG is first checked to see if it is aligned to the pool
+alignment and discarded if not. The reference is converted to a grain
+number within the segment (by subtracting the segments’ base from the
+reference and then dividing by the grain size). The bit (the one
+corresponding to the grain number) is set in the mark table.
+Exception, for a weak reference (rank is RankWEAK) the mark table
+is checked and the reference is fixed to 0 if this address has not
+been marked otherwise nothing happens. Note that there is no check
+that the reference refers to a valid object boundary (which wouldn’t
+be a valid check in the case of ambiguous references anyway).
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+void LOReclaim(Pool pool, Trace trace, Seg seg)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.reclaim: Derives the loseg from the seg, and calls
+loSegReclaim() (see .fun.segreclaim below).
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    24.7.2. Internal
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+void loSegReclaim(LOSeg loseg, Trace trace)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .fun.segreclaim: For all the contiguous allocated regions in the
+segment it locates the boundaries of all the objects in that region by
+repeatedly skipping (by calling format->skip) from the beginning
+of the region (the beginning of the region is guaranteed to coincide
+with the beginning of an object). For each object it examines the bit
+in the mark bit table that corresponds to the beginning of the object.
+If that bit is set then the object has been marked as a result of a
+previous call to LOFix(), the object is preserved by doing
+nothing. If that bit is not set then the object has not been marked
+and should be reclaimed; the object is reclaimed by resetting the
+appropriate range of bits in the segment’s free bit table.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    Note
                                                                                                                    
+
                                                                                                                    Special things happen for buffered segments.
                                                                                                                    
+
                                                                                                                    Explain how the marked variable is used to free segments.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    24.8. Attachment
                                                                                                                    
+
                                                                                                                    [missing attachment “LOGROUP.CWK”]
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
+
+          
                                                                                                                    
+        
                                                                                                                    
+      
                                                                                                                    
+      
                                                                                                                    
+        
                                                                                                                    
+            
+  
                                                                                                                    Table Of Contents
                                                                                                                    
+  
+
+  
                                                                                                                    Previous topic
                                                                                                                    
+  
                                                                                                                    23. AWL pool class
                                                                                                                    
+  
                                                                                                                    Next topic
                                                                                                                    
+  
                                                                                                                    25. MFS pool class
                                                                                                                    Downloads
                                                                                                                    
+
+
                                                                                                                    
+MPS Kit release 1.111.0
                                                                                                                    
+All MPS Kit releases
+
                                                                                                                    
+
+
                                                                                                                    Issues
                                                                                                                    
+
+
                                                                                                                    
+Known issues
                                                                                                                    
+Issues fixed in release 1.111.0
+
                                                                                                                    Contact us
                                                                                                                    
+
+
                                                                                                                    mps-questions@ravenbrook.com
                                                                                                                    
+        
                                                                                                                    
+      
                                                                                                                    
+      
                                                                                                                    
+    
                                                                                                                    
+    
                                                                                                                    
+      
                                                                                                                    Navigation
                                                                                                                    
+      
+    
                                                                                                                    
+    
                                                                                                                    
+        © Copyright 2013, Ravenbrook Limited.
+      Created using Sphinx 1.1.3.
+    
                                                                                                                    
+  
+
\ No newline at end of file
diff --git a/mps/manual/html/design/poolmfs.html b/mps/manual/html/design/poolmfs.html
new file mode 100644
index 00000000000..220f5fe5d44
--- /dev/null
+++ b/mps/manual/html/design/poolmfs.html
@@ -0,0 +1,134 @@
+
+
+
+
+
+
+  
+    
+    
+    25. MFS pool class — Memory Pool System 1.111.0 documentation
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+     
+  
+  
+    
                                                                                                                    
+      
                                                                                                                    Navigation
                                                                                                                    
+      
+    
                                                                                                                      
+
+    
                                                                                                                    
+      
                                                                                                                    
+        
                                                                                                                    
+          
                                                                                                                    
+            
+  
                                                                                                                    
+
                                                                                                                    25. MFS pool class
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    25.1. Overview
                                                                                                                    
+
                                                                                                                    MFS stands for “Manual Fixed Small”. The MFS pool class manages
+objects that are of a fixed size. It is intended to only manage small
+objects efficiently. Storage is recycled manually by the client
+programmer.
                                                                                                                    
+
                                                                                                                    A particular instance of an MFS Pool can manage objects only of a
+single size, but different instances can manage objects of different
+sizes. The size of object that an instance can manage is declared when
+the instance is created.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
+
+          
                                                                                                                    
+        
                                                                                                                    
+      
                                                                                                                    
+      
                                                                                                                    
+        
                                                                                                                    
+            
+  
                                                                                                                    Table Of Contents
                                                                                                                    
+  
+
+  
                                                                                                                    Previous topic
                                                                                                                    
+  
                                                                                                                    24. LO pool class
                                                                                                                    
+  
                                                                                                                    Next topic
                                                                                                                    
+  
                                                                                                                    26. MRG pool class
                                                                                                                    Downloads
                                                                                                                    
+
+
                                                                                                                    
+MPS Kit release 1.111.0
                                                                                                                    
+All MPS Kit releases
+
                                                                                                                    
+
+
                                                                                                                    Issues
                                                                                                                    
+
+
                                                                                                                    
+Known issues
                                                                                                                    
+Issues fixed in release 1.111.0
+
                                                                                                                    Contact us
                                                                                                                    
+
+
                                                                                                                    mps-questions@ravenbrook.com
                                                                                                                    
+        
                                                                                                                    
+      
                                                                                                                    
+      
                                                                                                                    
+    
                                                                                                                    
+    
                                                                                                                    
+      
                                                                                                                    Navigation
                                                                                                                    
+      
+    
                                                                                                                    
+    
                                                                                                                    
+        © Copyright 2013, Ravenbrook Limited.
+      Created using Sphinx 1.1.3.
+    
                                                                                                                    
+  
+
\ No newline at end of file
diff --git a/mps/manual/html/design/poolmrg.html b/mps/manual/html/design/poolmrg.html
new file mode 100644
index 00000000000..25172a5f9b5
--- /dev/null
+++ b/mps/manual/html/design/poolmrg.html
@@ -0,0 +1,672 @@
+
+
+
+
+
+
+  
+    
+    
+    26. MRG pool class — Memory Pool System 1.111.0 documentation
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+     
+  
+  
+    
                                                                                                                    
+      
                                                                                                                    Navigation
                                                                                                                    
+      
+    
                                                                                                                      
+
+    
                                                                                                                    
+      
                                                                                                                    
+        
                                                                                                                    
+          
                                                                                                                    
+            
+  
                                                                                                                    
+
                                                                                                                    26. MRG pool class
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.1. Introduction
                                                                                                                    
+
                                                                                                                    .readership: Any MPS developer.
                                                                                                                    
+
                                                                                                                    .intro: This is the design of the MRG (Manual Rank Guardian) pool
+class. The MRG pool class is part of the MPS. The MRG pool class is
+internal to the MPS (has no client interface) and is used to implement
+finalization.
                                                                                                                    
+
                                                                                                                    .source: Some of the techniques in paper.dbe93 (“Guardians in a
+Generation-Based Garbage Collector”) were used in this design. Some
+analysis of this design (including various improvements and some more
+in-depth justification) is in analysis.mps.poolmrg. That document
+should be understood before changing this document. It is also helpful
+to look at design.mps.finalize and design.mps.message.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.2. Goals
                                                                                                                    
+
                                                                                                                    .goal.final: The MRG pool class should support all
+requirements pertaining to finalization.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.3. Requirements
                                                                                                                    
+
                                                                                                                    .req: We have only one requirement pertaining to finalization:
                                                                                                                    
+
                                                                                                                    .req.dylan.fun.finalization: Support the Dylan language-level
+implementation of finalized objects: objects are registered, and are
+finalized in random order when they would otherwise have died. Cycles
+are broken at random places. There is no guarantee of promptness.
                                                                                                                    
+
                                                                                                                    .req.general: However, finalization is a very common piece of
+functionality that is provided by (sophisticated) memory managers, so
+we can expect other clients to request this sort of functionality.
                                                                                                                    
+
                                                                                                                    .anti-req: Is it required that the MRG pool class return
+unused segments to the arena? MFS, for example, does not do this. MRG
+will not do this in its initial implementation.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.4. Terminology
                                                                                                                    
+
                                                                                                                    .def.mrg: MRG: The MRG pool class’s identifier will be MRG.
+This stands for “Manual Rank Guardian”. The pool is manually managed
+and implements guardians for references of a particular rank
+(currently just final).
                                                                                                                    
+
                                                                                                                    .def.final.ref: final reference: A reference of rank final (see
+design.mps.type.rank).
                                                                                                                    
+
                                                                                                                    .def.final.object: finalizable object: An object is finalizable
+with respect to a final reference if, since the creation of that
+reference, there was a point in time when no references to the object
+of lower (that is, stronger) rank were reachable from a root.
                                                                                                                    
+
                                                                                                                    .def.final.object.note: Note that this means an object can be
+finalizable even if it is now reachable from the root via exact
+references.
                                                                                                                    
+
                                                                                                                    .def.finalize: finalize: To finalize an object is to notify the
+client that the object is finalizable. The client is presumed to be
+interested in this information (typically it will apply some method to
+the object).
                                                                                                                    
+
                                                                                                                    .def.guardian: guardian: An object allocated in the MRG
+Pool. A guardian contains exactly one final reference, and some fields
+for the pool’s internal use. Guardians are used to implement a
+finalization mechanism.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.5. Overview
                                                                                                                    
+
                                                                                                                    .over: The MRG pool class is a pool class in the MPS. It is
+intended to provide the functionality of “finalization”.
                                                                                                                    
+
                                                                                                                    .over.internal: The MRG pool class is internal to the MPM: it
+is not intended to have a client interface. Clients are expected to
+access the functionality provided by this pool (finalization) using a
+separate MPS finalization interface (design.mps.finalize).
                                                                                                                    
+
                                                                                                                    .over.one-size: The MRG pool class manages objects of a single
+size, each object containing a single reference of rank final.
                                                                                                                    
+
                                                                                                                    .over.one-size.justify: This is all that is necessary to meet our
+requirements for finalization. Whenever an object is registered for
+finalization, it is sufficient to create a single reference of rank
+final to it.
                                                                                                                    
+
                                                                                                                    .over.queue: A pool maintains a list of live guardian objects,
+called (for historical reasons) the “entry” list.
                                                                                                                    
+
                                                                                                                    .over.queue.free: The pool also maintains a list of free guardian
+objects called the “free” list.
                                                                                                                    
+
                                                                                                                    .over.queue.exit.not: There used to be an “exit” list, but this is
+now historical and there shouldn’t be any current references to it.
                                                                                                                    
+
                                                                                                                    .over.alloc: When guardians are allocated, they are placed on the
+entry list. Guardians on the entry list refer to objects that have not
+yet been shown to be finalizable (either the object has references of
+lower rank than final to it, or the MPS has not yet got round to
+determining that the object is finalizable).
                                                                                                                    
+
                                                                                                                    .over.message.create: When a guardian is discovered to refer to a
+finalizable object it is removed from the entry list and becomes a
+message on the arena’s messages queue.
                                                                                                                    
+
                                                                                                                    .over.message.deliver: When the MPS client receives the message the
+message system arranges for the message to be destroyed and the pool
+reclaims the storage associated with the guardian/message.
                                                                                                                    
+
                                                                                                                    .over.scan: When the pool is scanned at rank final each reference
+will be fixed. If the reference is to an unmarked object (before the
+fix), then the object must now be finalizable. In this case the
+containing guardian will be removed from the entry list and posted as
+a message.
                                                                                                                    
+
                                                                                                                    .over.scan.justify: The scanning process is a crucial step
+necessary for implementing finalization. It is the means by which the
+MPS detects that objects are finalizable.
                                                                                                                    
+
                                                                                                                    .over.message: PoolClassMRG implements a MessageClass (see
+design.mps.message). All the messages are of one MessageType. This
+type is MessageTypeFinalization. Messages are created when objects
+are discovered to be finalizable and destroyed when the MPS client has
+received the message.
                                                                                                                    
+
                                                                                                                    .over.message.justify: Messages provide a means for the MPS to
+communicate with its client. Notification of finalization is just such
+a communication. Messages allow the MPS to inform the client of
+finalization events when it is convenient for the MPS to do so (i.e.
+not in PageFault context).
                                                                                                                    
+
                                                                                                                    .over.manual: Objects in the MRG pool are manually managed.
                                                                                                                    
+
                                                                                                                    .over.manual.alloc: They are allocated by ArenaFinalize() when
+objects are registered for finalization.
                                                                                                                    
+
                                                                                                                    .over.manual.free: They are freed when the associated message is
+destroyed.
                                                                                                                    
+
                                                                                                                    .over.manual.justify: The lifetime of a guardian object is very
+easy to determine so manual memory management is appropriate.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.6. Protocols
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.6.1. Object Registration
                                                                                                                    
+
                                                                                                                    .protocol.register: There is a protocol by which objects can be
+registered for finalization. This protocol is handled by the arena
+module on behalf of finalization. see
+design.mps.finalize.int.finalize.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.6.2. Finalizer execution
                                                                                                                    
+
                                                                                                                    .protocol.finalizer: If an object is proven to be finalizable then
+a message to this effect will eventually be posted. A client can
+receive the message, determine what to do about it, and do it.
+Typically this would involve calling the finalization method for the
+object, and deleting the message. Once the message is deleted, the
+object may become recyclable.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.6.3. Setup / destroy
                                                                                                                    
+
                                                                                                                    .protocol.life: An instance of PoolClassMRG is needed in order to
+support finalization, it is called the “final” pool and is attached to
+the arena (see design.mps.finalize.int.arena.struct).
                                                                                                                    
+
                                                                                                                    .protocol.life.birth: The final pool is created lazily by
+ArenaFinalize().
                                                                                                                    
+
                                                                                                                    .protocol.life.death: The final pool is destroyed during
+ArenaDestroy().
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.7. Data structures
                                                                                                                    
+
                                                                                                                    .guardian: The guardian
                                                                                                                    
+
                                                                                                                    .guardian.over: A guardian is an object used to manage the
+references and other data structures that are used by the pool in
+order to keep track of which objects are registered for finalization,
+which ones have been finalized, and so on.
                                                                                                                    
+
                                                                                                                    .guardian.state: A guardian can be in one of four states:
                                                                                                                    
+
                                                                                                                    .guardian.state.enum: The states are Free, Prefinal, Final,
+PostFinal (referred to as MRGGuardianFree, etc. in the
+implementation).
                                                                                                                    
+
                                                                                                                      
+
                                                                                                                    1. .guardian.state.free: The guardian is free, meaning that it is
+on the free list for the pool and available for allocation.
                                                                                                                      2. 
+
                                                                                                                    2. .guardian.state.prefinal: The guardian is allocated, and refers
+to an object that has not yet been discovered to be finalizable. It
+is on the entry list for the pool.
                                                                                                                      3. 
+
                                                                                                                    3. .guardian.state.final: The guardian is allocated, and refers to
+an object that has been shown to be finalizable; this state
+corresponds to the existence of a message.
                                                                                                                      4. 
+
                                                                                                                    4. .guardian.state.postfinal: This state is only used briefly and
+is entirely internal to the pool; the guardian enters this state
+just after the associated message has been destroyed (which happens
+when the client receives the message) and will be freed immediately
+(whereupon it will enter the Free state). This state is used for
+checking only (so that MRGFree can check that only guardians in
+this state are being freed).
                                                                                                                      5. 
+
                                                                                                                    
+
                                                                                                                    .guardian.life-cycle: Guardians go through the following state life-cycle: Free ⟶ Prefinal ⟶ Final ⟶ Postfinal ⟶ Free.
                                                                                                                    
+
                                                                                                                    .guardian.two-part: A guardian is a structure consisting abstractly
+of a link part and a reference part. Concretely, the link part is a
+LinkPartStruct, and the reference part is a RefPartStruct
+(which is just a Word). The link part is used by the pool, the
+reference part forms the object visible to clients of the pool. The
+reference part is the reference of RankFINAL that refers to
+objects registered for finalization and is how the MPS detects
+finalizable objects.
                                                                                                                    
+
                                                                                                                    .guardian.two-part.union: The LinkPartStruct is a discriminated
+union of a RingStruct and a MessageStruct. The RingStruct
+is used when the guardian is either Free or Prefinal. The
+MessageStruct is used when the guardian is Final. Neither part of the
+union is used when the guardian is in the Postfinal state.
                                                                                                                    
+
                                                                                                                    .guardian.two-part.justify: This may seem a little profligate with
+space, but this is okay as we are not required to make finalization
+extremely space efficient.
                                                                                                                    
+
                                                                                                                    .guardian.parts.separate: The two parts will be stored in separate
+segments.
                                                                                                                    
+
                                                                                                                    .guardian.parts.separate.justify: This is so that the data
+structures the pool uses to manage the objects can be separated from
+the objects themselves. This avoids the pool having to manipulate data
+structures that are on shielded segments
+(analysis.mps.poolmrg.hazard.shield).
                                                                                                                    
+
                                                                                                                    .guardian.assoc: Ref part number n (from the beginning of the
+segment) in one segment will correspond with link part number n in
+another segment. The association between the two segments will be
+managed by the additional fields in pool-specific segment subclasses
+(see .mrgseg).
                                                                                                                    
+
                                                                                                                    .guardian.ref: Guardians that are either Prefinal or Final are live
+and have valid references (possibly NULL) in their ref parts.
+Guardians that are free are dead and always have NULL in their ref
+parts (see .free.overwrite and .scan.free).
                                                                                                                    
+
                                                                                                                    .guardian.ref.free: When freeing an object, it is a pointer to the
+reference part that will be passed (internally in the pool).
                                                                                                                    
+
                                                                                                                    .guardian.init: Guardians are initialized when the pool is grown
+(.alloc.grow). The initial state has the ref part NULL and the
+link part is attached to the free ring. Freeing an object returns a
+guardian to its initial state.
                                                                                                                    
+
                                                                                                                    .poolstruct: The Pool structure, MRGStruct will have:
                                                                                                                    
+
                                                                                                                      
+
                                                                                                                    • .poolstruct.entry: the head of the entry list.
                                                                                                                      
+
                                                                                                                      • 
+
                                                                                                                    • .poolstruct.free: the head of the free list.
                                                                                                                      
+
                                                                                                                      • 
+
                                                                                                                    • .poolstruct.rings: The entry list, the exit list, and the free
+list will each be implemented as a Ring. Each ring will be
+maintained using the link part of the guardian.
                                                                                                                      
+
                                                                                                                      .poolstruct.rings.justify: This is because rings are convenient to
+use and are well tested. It is possible to implement all three lists
+using a singly linked list, but the saving is certainly not worth
+making at this stage.
                                                                                                                      
+
                                                                                                                      • 
+
                                                                                                                    • .poolstruct.refring: a ring of “ref” segments in use for links or
+messages (see .mrgseg.ref.mrgring below).
                                                                                                                      
+
                                                                                                                      • 
+
                                                                                                                    • .poolstruct.extend: a precalculated extendBy field (see
+.init.extend). This value is used to determine how large a
+segment should be requested from the arena for the reference part
+segment when the pool needs to grow (see .alloc.grow.size).
                                                                                                                      
+
                                                                                                                      .poolstruct.extend.justify: Calculating a reasonable value for this
+once and remembering it simplifies the allocation (.alloc.grow).
                                                                                                                      
+
                                                                                                                      • 
+
                                                                                                                    
+
                                                                                                                    .poolstruct.init: poolstructs are initialized once for each pool
+instance by MRGInit() (.init). The initial state has all the
+rings initialized to singleton rings, and the extendBy field
+initialized to some value (see .init.extend).
                                                                                                                    
+
                                                                                                                    .mrgseg: The pool defines two segment subclasses:
+MRGRefSegClass and MRGLinkSegClass. Segments of the former
+class will be used to store the ref parts of guardians, segments of
+the latter will be used to store the link parts of guardians (see
+.guardian.two-part). Segments are always allocated in pairs, with
+one of each class, by the function MRGSegPairCreate(). Each
+segment contains a link to its pair.
                                                                                                                    
+
                                                                                                                    .mrgseg.ref: MRGRefSegClass is a subclass of GCSegClass.
+Instances are of type MRGRefSeg, and contain:
                                                                                                                    
+
+
                                                                                                                    .mrgseg.ref.init: A segment is created and initialized once every
+time the pool is grown (.alloc.grow). The initial state has the
+segment ring node initialized and attached to the pool’s segment ring,
+the linkseg field points to the relevant link segment, the grey field
+is initialized such that the segment is not grey for all traces.
                                                                                                                    
+
                                                                                                                    .mrgseg.link: MRGLinkSegClass is a subclass of SegClass.
+Instances are of type MRGLinkSeg, and contain:
                                                                                                                    
+
                                                                                                                      
+
                                                                                                                    • .mrgseg.link.refseg: a pointer to the paired ref segment. This
+may be NULL during initialization, while the pairing is being
+established.
                                                                                                                      • 
+
                                                                                                                    • .mrgseg.link.init: The initial state has the linkseg field
+pointing to the relevant ref segment.
                                                                                                                      • 
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.8. Functions
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Bool MRGCheck(MRG mrg)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .check: Check the signatures, the class, and each field of the
+MRGStruct. Each field is checked as being appropriate for its
+type.
                                                                                                                    
+
                                                                                                                    .check.justify: There are no non-trivial invariants that can
+be easily checked.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Res MRGRegister(Pool pool, Ref ref)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .alloc: Add a guardian for ref.
                                                                                                                    
+
                                                                                                                    .alloc.grow: If the free list is empty then two new segments are
+allocated and the free list filled up from them (note that the
+reference fields of the new guardians will need to be overwritten with
+NULL, see .free.overwrite)
                                                                                                                    
+
                                                                                                                    .alloc.grow.size: The size of the reference part segment will be
+the pool’s extendBy (.poolstruct.extend) value. The link part
+segment will be whatever size is necessary to accommodate N link
+parts, where N is the number of reference parts that fit in the
+reference part segment.
                                                                                                                    
+
                                                                                                                    .alloc.error: If any of the requests for more resource (there are
+two; one for each of two segments) fail then the successful requests
+will be retracted and the result code from the failing request will be
+returned.
                                                                                                                    
+
                                                                                                                    .alloc.pop: MRGRegister() pops a ring node off the free list,
+and add it to the entry list.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Res MRGDeregister(Pool pool, Ref obj)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .free: Remove the guardian from the message queue and add it to the
+free list.
                                                                                                                    
+
                                                                                                                    .free.push: The guardian will simply be added to the front of the
+free list (that is, no keeping the free list in address order or
+anything like that).
                                                                                                                    
+
                                                                                                                    .free.inadequate: No attempt will be made to return unused free
+segments to the arena (although see
+analysis.mps.poolmrg.improve.free.* for suggestions).
                                                                                                                    
+
                                                                                                                    .free.overwrite: MRGDeregister() also writes over the reference
+with NULL. .free.overwrite.justify: This is so that when the
+segment is subsequently scanned (.scan.free), the reference that
+used to be in the object is not accidentally fixed.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Res MRGInit(Pool pool, ArgList args)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .init: Initializes the entry list, the free ring, the ref ring, and
+the extendBy field.
                                                                                                                    
+
                                                                                                                    .init.extend: The extendBy field is initialized to one
+ArenaAlign() (usually a page).
                                                                                                                    
+
                                                                                                                    .init.extend.justify: This is adequate as the pool is not expected
+to grow very quickly.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+void MRGFinish(Pool pool)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .finish: Iterate over all the segments, returning all the segments
+to the arena.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Res MRGScan(Bool *totalReturn, ScanState ss, Pool pool, Seg seg)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .scan: MRGScan() scans a segment.
                                                                                                                    
+
                                                                                                                    .scan.trivial: Scan will do nothing (that is, return immediately)
+if the tracing rank is anything other than final.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    Note
                                                                                                                    
+
                                                                                                                    This optimization is missing. impl.c.trace.scan.conservative is
+not a problem because there are no faults on these segs, because
+there are no references into them. But that’s why TraceScan()
+can’t do it. Pekka P. Pirinen, 1997-09-19.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    .scan.trivial.justify: If the rank is lower than final then
+scanning is detrimental, it will only delay finalization. If the rank
+is higher than final there is nothing to do, the pool only contains
+final references.
                                                                                                                    
+
                                                                                                                    .scan.guardians: MRGScan() will iterate over all guardians in
+the segment. Every guardian’s reference will be fixed (.scan.free:
+note that guardians that are on the free list have NULL in their
+reference part).
                                                                                                                    
+
                                                                                                                    .scan.wasold: If the object referred to had not been fixed
+previously (that is, was unmarked) then the object is not referenced
+by a reference of a lower rank (than RankFINAL) and hence is
+finalizable.
                                                                                                                    
+
                                                                                                                    .scan.finalize: The guardian will be finalized. This entails moving
+the guardian from state Prefinal to Final; it is removed from the
+entry list and initialized as a message and posted on the arena’s
+message queue.
                                                                                                                    
+
                                                                                                                    .scan.finalize.idempotent: In fact this will only happen if the
+guardian has not already been finalized (which is determined by
+examining the state of the guardian).
                                                                                                                    
+
                                                                                                                    .scan.unordered: Because scanning occurs a segment at a time, the
+order in which objects are finalized is “random” (it cannot be
+predicted by considering only the references between objects
+registered for finalization). See
+analysis.mps.poolmrg.improve.semantics for how this can be improved.
                                                                                                                    
+
                                                                                                                    .scan.unordered.justify: Unordered finalization is all that is
+required.
                                                                                                                    
+
                                                                                                                    See analysis.mps.poolmrg.improve.scan.nomove for a suggested
+improvement that avoids redundant unlinking and relinking.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Res MRGDescribe(Pool pool, mps_lib_FILE *stream)
                                                                                                                    
+
                                                                                                                    
+
+
                                                                                                                    .describe: Describes an MRG pool. Iterates along each of the entry
+and exit lists and prints the guardians in each. The location of the
+guardian and the value of the reference in it will be printed out.
                                                                                                                    
+
                                                                                                                    .functions.unused: All of these will be unused: BufferInit(),
+BufferFill(), BufferEmpty(), BufferFinish(),
+TraceBegin(), TraceCondemn(), PoolFix(), PoolReclaim(), TraceEnd().
                                                                                                                    
+
                                                                                                                    .functions.trivial: The Grey method of the pool class will be
+PoolTrivGrey(), this pool has no further bookkeeping to perform
+for grey segments.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.9. Transgressions
                                                                                                                    
+
                                                                                                                    .trans.no-finish: The MRG pool does not trouble itself to tidy up
+its internal rings properly when being destroyed.
                                                                                                                    
+
                                                                                                                    .trans.free-seg: No attempt is made to release free segments to the
+arena. A suggested strategy for this is as follows:
                                                                                                                    
+
                                                                                                                      
+
                                                                                                                    • Add a count of free guardians to each segment, and maintain it in
+appropriate places.
                                                                                                                      • 
+
                                                                                                                    • Add a free segment ring to the pool.
                                                                                                                      • 
+
                                                                                                                    • In MRGRefSegScan(), if the segment is entirely free, don’t scan
+it, but instead detach its links from the free ring, and move the
+segment to the free segment ring.
                                                                                                                      • 
+
                                                                                                                    • At some appropriate point, such as the end of MRGAlloc(),
+destroy free segments.
                                                                                                                      • 
+
                                                                                                                    • In MRGAlloc(), if there are no free guardians, check the free
+segment ring before creating a new pair of segments. Note that this
+algorithm would give some slight measure of segment hysteresis. It
+is not the place of the pool to support general segment hysteresis.
                                                                                                                      • 
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.10. Future
                                                                                                                    
+
                                                                                                                    .future.array: In future, for speed or simplicity, this pool could
+be rewritten to use an array. See mail.gavinm.1997-09-04.13-08(0).
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.11. Tests
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    Note
                                                                                                                    
+
                                                                                                                    This section is utterly out of date. Pekka P. Pirinen, 1997-09-19.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    .test: The test impl.c.finalcv is similar to the weakness test (see
+design.mps.weakness, impl.c.weakcv).
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.11.1. Functionality
                                                                                                                    
+
                                                                                                                    This is the functionality to be tested:
                                                                                                                    
+
                                                                                                                      
+
                                                                                                                    • .fun.alloc: Can allocate objects.
                                                                                                                      • 
+
                                                                                                                    • .fun.free: Can free objects that were allocated.
                                                                                                                      • 
+
                                                                                                                    • .prot.write: Can write a reference into an allocated object.
                                                                                                                      • 
+
                                                                                                                    • .prot.read: Can read the reference from an allocated object.
                                                                                                                      • 
+
                                                                                                                    • .promise.faithful: A reference stored in an allocated object will
+continue to refer to the same object.
                                                                                                                      • 
+
                                                                                                                    • .promise.live: A reference stored in an allocated object will
+preserve the object referred to.
                                                                                                                      • 
+
                                                                                                                    • .promise.unreachable: Any objects referred to in finalization
+messages are not (at the time of reading the message) reachable via
+a chain of ambiguous or exact references. (we will not be able to
+test this at first as there is no messaging interface)
                                                                                                                      • 
+
                                                                                                                    • .promise.try: The pool will make a “good faith” effort to
+finalize objects that are not reachable via a chain of ambiguous or
+exact references.
                                                                                                                      • 
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.11.2. Attributes
                                                                                                                    
+
                                                                                                                    The following attributes will be tested:
                                                                                                                    
+
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.11.3. Implementation
                                                                                                                    
+
                                                                                                                    The test will simply allocate a number of objects in the AMC pool and
+finalize each one, throwing away the reference to the objects. Churn.
                                                                                                                    
+
                                                                                                                    .test.mpm: The test will use the MPM interface (impl.h.mpm).
                                                                                                                    
+
                                                                                                                    .test.mpm.justify: This is because it is not intended to provide an
+MPS interface to this pool directly, and the MPS interface to
+finalization has not been written yet (impl.h.mps).
                                                                                                                    
+
                                                                                                                    .test.mpm.change: Later on it may use the MPS interface, in which
+case, where the following text refers to allocating objects in the MRG
+pool it will need adjusting.
                                                                                                                    
+
                                                                                                                    .test.two-pools: The test will use two pools, an AMC pool, and an
+MRG pool.
                                                                                                                    
+
                                                                                                                    .test.alloc: A number of objects will be allocated in the MRG pool.
                                                                                                                    
+
                                                                                                                    .test.free: They will then be freed. This will test .fun.alloc
+and .fun.free, although not very much.
                                                                                                                    
+
                                                                                                                    .test.rw.a: An object, “A”, will be allocated in the AMC pool, a
+reference to it will be kept in a root.
                                                                                                                    
+
                                                                                                                    .test.rw.alloc: A number of objects will be allocated in the MRG
+pool.
                                                                                                                    
+
                                                                                                                    .test.rw.write: A reference to “A” will be written into each
+object.
                                                                                                                    
+
                                                                                                                    .test.rw.read: The reference in each object will be read and
+checked to see if it refers to “A”.
                                                                                                                    
+
                                                                                                                    .test.rw.free: All the objects will be freed.
                                                                                                                    
+
                                                                                                                    .test.rw.drop: The reference to “A” will be dropped. This will test
+.prot.write and .prot.read.
                                                                                                                    
+
                                                                                                                    .test.promise.fl.alloc: A number of objects will be allocated in
+the AMC pool.
                                                                                                                    
+
                                                                                                                    .test.promise.fl.tag: Each object will be tagged uniquely.
                                                                                                                    
+
                                                                                                                    .test.promise.fl.refer: a reference to it will be stored in an
+object allocated in the MRG pool.
                                                                                                                    
+
                                                                                                                    .test.promise.fl.churn: A large amount of garbage will be allocated
+in the AMC pool. Regularly, whilst this garbage is being allocated, a
+check will be performed that all the objects allocated in the MRG pool
+refer to valid objects and that they still refer to the same objects.
+All objects from the MRG pool will then be freed (thus dropping all
+references to the AMC objects). This will test .promise.faithful
+and .promise.live.
                                                                                                                    
+
                                                                                                                    .test.promise.ut.not: The following part of the test has not
+implemented. This is because the messaging system has not yet been
+implemented.
                                                                                                                    
+
                                                                                                                    .test.promise.ut.alloc: A number of objects will be allocated in
+the AMC pool.
                                                                                                                    
+
                                                                                                                    .test.promise.ut.refer: Each object will be referred to by a root
+and also referred to by an object allocated in the MRG pool.
                                                                                                                    
+
                                                                                                                    .test.promise.ut.drop: References to a random selection of the
+objects from the AMC pool will be deleted from the root.
                                                                                                                    
+
                                                                                                                    .test.promise.ut.churn: A large amount of garbage will be allocated
+in the AMC pool.
                                                                                                                    
+
                                                                                                                    .test.promise.ut.message: The message interface will be used to
+receive finalization messages.
                                                                                                                    
+
                                                                                                                    .test.promise.ut.final.check: For each finalization message
+received it will check that the object referenced in the message is
+not referred to in the root.
                                                                                                                    
+
                                                                                                                    .test.promise.ut.nofinal.check: After some amount of garbage has
+been allocated it will check to see if any objects are not in the root
+and haven’t been finalized. This will test .promise.unreachable and
+.promise.try.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    26.12. Notes
                                                                                                                    
+
                                                                                                                    .access.inadequate: PoolAccess() will scan segments at
+RankEXACT`. Really it should be scanned at whatever the minimum rank
+of all grey segments is (the trace rank phase), however there is no
+way to find this out. As a consequence we will sometimes scan pages at
+RankEXACT when the pages could have been scanned at RankFINAL.
+This means that finalization of some objects may sometimes get
+delayed.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
+
+          
                                                                                                                    
+        
                                                                                                                    
+      
                                                                                                                    
+      
                                                                                                                    
+        
                                                                                                                    
+            
+  
                                                                                                                    Table Of Contents
                                                                                                                    
+  
+
+  
                                                                                                                    Previous topic
                                                                                                                    
+  
                                                                                                                    25. MFS pool class
                                                                                                                    
+  
                                                                                                                    Next topic
                                                                                                                    
+  
                                                                                                                    27. MVFF pool class
                                                                                                                    Downloads
                                                                                                                    
+
+
                                                                                                                    
+MPS Kit release 1.111.0
                                                                                                                    
+All MPS Kit releases
+
                                                                                                                    
+
+
                                                                                                                    Issues
                                                                                                                    
+
+
                                                                                                                    
+Known issues
                                                                                                                    
+Issues fixed in release 1.111.0
+
                                                                                                                    Contact us
                                                                                                                    
+
+
                                                                                                                    mps-questions@ravenbrook.com
                                                                                                                    
+        
                                                                                                                    
+      
                                                                                                                    
+      
                                                                                                                    
+    
                                                                                                                    
+    
                                                                                                                    
+      
                                                                                                                    Navigation
                                                                                                                    
+      
+    
                                                                                                                    
+    
                                                                                                                    
+        © Copyright 2013, Ravenbrook Limited.
+      Created using Sphinx 1.1.3.
+    
                                                                                                                    
+  
+
\ No newline at end of file
diff --git a/mps/manual/html/design/poolmv.html b/mps/manual/html/design/poolmv.html
new file mode 100644
index 00000000000..71cf018caa8
--- /dev/null
+++ b/mps/manual/html/design/poolmv.html
@@ -0,0 +1,107 @@
+
+
+
+
+
+
+  
+    
+    
+    MV pool class — Memory Pool System 1.111.0 documentation
+    
+    
+    
+    
+    
+    
+    
+    
+    
+     
+  
+  
+    
                                                                                                                    
+      
                                                                                                                    Navigation
                                                                                                                    
+      
+    
                                                                                                                      
+
+    
                                                                                                                    
+      
                                                                                                                    
+        
                                                                                                                    
+          
                                                                                                                    
+            
+  
                                                                                                                    
+
                                                                                                                    MV pool class
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    Implementation
                                                                                                                    
+
                                                                                                                    .lost: It is possible for MV to “lose” memory when freeing an
+objects. This happens when an extra block descriptor is needed (ie the
+interior of a block is being freed) and the call to allocate the block
+fails.
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+
+
+          
                                                                                                                    
+        
                                                                                                                    
+      
                                                                                                                    
+      
                                                                                                                    
+        
                                                                                                                    
+            
+  
                                                                                                                    Table Of Contents
                                                                                                                    
+  
+
                                                                                                                    Downloads
                                                                                                                    
+
+
                                                                                                                    
+MPS Kit release 1.111.0
                                                                                                                    
+All MPS Kit releases
+
                                                                                                                    
+
+
                                                                                                                    Issues
                                                                                                                    
+
+
                                                                                                                    
+Known issues
                                                                                                                    
+Issues fixed in release 1.111.0
+
                                                                                                                    Contact us
                                                                                                                    
+
+
                                                                                                                    mps-questions@ravenbrook.com
                                                                                                                    
+        
                                                                                                                    
+      
                                                                                                                    
+      
                                                                                                                    
+    
                                                                                                                    
+    
                                                                                                                    
+      
                                                                                                                    Navigation
                                                                                                                    
+      
+    
                                                                                                                    
+    
                                                                                                                    
+        © Copyright 2013, Ravenbrook Limited.
+      Created using Sphinx 1.1.3.
+    
                                                                                                                    
+  
+
\ No newline at end of file
diff --git a/mps/manual/html/design/poolmvff.html b/mps/manual/html/design/poolmvff.html
index 3702d01d463..e465f776d53 100644
--- a/mps/manual/html/design/poolmvff.html
+++ b/mps/manual/html/design/poolmvff.html
@@ -8,7 +8,7 @@
   
     
     
-    14. Manually-Managed Variable-Size First-Fit Pool — Memory Pool System 1.111.0 documentation
+    27. MVFF pool class — Memory Pool System 1.111.0 documentation
     
     
     
@@ -28,8 +28,8 @@
     
     
     
-    
-     
+    
+     
   
   
     
                                                                                                                    
@@ -39,10 +39,10 @@ 
                                                                                                                    Navigation
                                                                                                                    
           index
         
                                                                                                                  • 
-          next |
                                                                                                                    • 
         
                                                                                                                  • 
-          previous |
                                                                                                                    • 
         
                                                                                                                  • Memory Pool System 1.111.0 documentation »
                                                                                                                    • 
           
                                                                                                                  • Old design »
                                                                                                                    •  
@@ -54,19 +54,20 @@ 
                                                                                                                    Navigation
                                                                                                                    
         
                                                                                                                    
           
                                                                                                                    
             
-  
                                                                                                                    
-
                                                                                                                    14. Manually-Managed Variable-Size First-Fit Pool
                                                                                                                    
+  
                                                                                                                    
+
                                                                                                                    27. MVFF pool class
                                                                                                                    
 
                                                                                                                    
-
                                                                                                                    14.1. Introduction
                                                                                                                    
-
                                                                                                                    .intro: The pool was created in a response to a belief that the
-ScriptWorks EPDL/EPDR’s first fit policy is beneficial for some classes
-of client behaviour, but the performance of a linear free list was
-unacceptable.  This pool implements a first (or last) fit policy for
+
                                                                                                                    27.1. Introduction
                                                                                                                    
+
                                                                                                                    .intro: This is the design of the MVFF (Manual Variable First-Fit)
+pool class. This pool implements a first (or last) fit policy for
 variable-sized manually-managed objects, with control over first/last,
 segment preference high/low, and slot fit low/high.
                                                                                                                    
+
                                                                                                                    The pool was created in a response to a belief that the ScriptWorks
+EPDL/EPDR’s first fit policy is beneficial for some classes of client
+behaviour, but the performance of a linear free list was unacceptable.
                                                                                                                    
 
                                                                                                                    
 
                                                                                                                    
-
                                                                                                                    14.2. Overview
                                                                                                                    
+
                                                                                                                    27.2. Overview
                                                                                                                    
 
                                                                                                                    .over: This pool implements certain variants of the address-ordered
 first-fit policy. The implementation allows allocation across segment
 boundaries.
                                                                                                                    
@@ -82,58 +83,53 @@ 
                                                                                                                    14.2. Overview
-
                                                                                                                    14.3. Methods
                                                                                                                    
+
                                                                                                                    27.3. Methods
                                                                                                                    
 
                                                                                                                    .method: The MVFF pool supports the following methods:
                                                                                                                    
-
                                                                                                                    .method.init: Res MVFFInit(Pool pool, va_list arg)
                                                                                                                    
-
                                                                                                                    This takes six keyword arguments:
                                                                                                                    
-
                                                                                                                    
-
                                                                                                                    
-MPS_KEY_EXTEND_BY
                                                                                                                    
-
                                                                                                                    
-the segment size
                                                                                                                    
-
                                                                                                                    
-
-
                                                                                                                    
-
                                                                                                                    
-MPS_KEY_MEAN_SIZE
                                                                                                                    
-
                                                                                                                    
-the average object size
                                                                                                                    
-
                                                                                                                    
-
-
                                                                                                                    
-
                                                                                                                    
-MPS_KEY_ALIGN
                                                                                                                    
-
                                                                                                                    
-the alignment of allocations and frees(must be at least sizeof(void*))
                                                                                                                    
-
                                                                                                                    
-
-
                                                                                                                    
-
                                                                                                                    
-MPS_KEY_MVFF_SLOT_HIGH
                                                                                                                    
-
                                                                                                                    
-whether to allocate objects at the end of free blocks found, as
                                                                                                                    
-
                                                                                                                    
-opposed to at the start(for unbuffered allocation)
                                                                                                                    
-
                                                                                                                    
-
-
                                                                                                                    
-
                                                                                                                    
-MPS_KEY_MVFF_ARENA_HIGH
                                                                                                                    
-
                                                                                                                    
-whether to express SegPrefHIGH to the arena, as opposed to
                                                                                                                    
-
                                                                                                                    
-SegPrefLOW
                                                                                                                    
-
                                                                                                                    
-
-
                                                                                                                    
-
                                                                                                                    
-MPS_KEY_MVFF_FIRST_FIT
                                                                                                                    
-
                                                                                                                    
-whether to use the suitable block of lowest address, as opposed
                                                                                                                    
-
                                                                                                                    
-to the highest(for unbuffered allocation)
                                                                                                                    
+
                                                                                                                    
+
                                                                                                                    
+Res MVFFInit(Pool pool, Args arg)
                                                                                                                    
 
                                                                                                                    
 
+
                                                                                                                    .method.init: This takes six keyword arguments:
                                                                                                                    
+
++++
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                                                                                    



                                                                                                                    Keyword argumentDescription
                                                                                                                    MPS_KEY_EXTEND_BYThe segment size.
                                                                                                                    MPS_KEY_MEAN_SIZEThe average object size.
                                                                                                                    MPS_KEY_ALIGNThe alignment of allocations and frees.
+Must be at least sizeof(void *).
                                                                                                                    MPS_KEY_MVFF_SLOT_HIGHWhether to allocate objects at the end of
+free blocks found, as opposed to at
+the start (for unbuffered
+allocation).
                                                                                                                    MPS_KEY_MVFF_ARENA_HIGHWhether to express SegPrefHIGH
+to the arena, as opposed to
+SegPrefLOW.
                                                                                                                    MPS_KEY_MVFF_FIRST_FITwhether to use the suitable block of lowest
+address, as opposed to the highest
+(for unbuffered allocation)
                                                                                                                    
 
                                                                                                                    .method.init.epdl: To simulate the EPDL pool, specify extendBy,
 avgSize, and maxSize as normal, and use slotHigh=FALSE,
 arenaHigh=FALSE, firstFit=TRUE.
                                                                                                                    
@@ -142,8 +138,8 @@ 
                                                                                                                    14.3. MethodsarenaHigh=TRUE, firstFit=TRUE.
                                                                                                                    
 
                                                                                                                    .method.init.other: The performance characteristics of other
 combinations are unknown.
                                                                                                                    
-
                                                                                                                    .method.finish: The PoolFinish method,
                                                                                                                    
-
                                                                                                                    .method.alloc: PoolAlloc and PoolFree methods are
+
                                                                                                                    .method.finish: The PoolFinish() method,
                                                                                                                    
+
                                                                                                                    .method.alloc: PoolAlloc() and PoolFree() methods are
 supported, implementing the policy set by the pool params (see
 .method.init).
                                                                                                                    
 
                                                                                                                    .method.describe: The usual describe method.
                                                                                                                    
@@ -151,33 +147,30 @@ 
                                                                                                                    14.3. Methods
-
                                                                                                                    14.4. External Functions
                                                                                                                    
+
                                                                                                                    27.4. External Functions
                                                                                                                    
 
                                                                                                                    .function: MVFF supports the following external functions:
                                                                                                                    
-
                                                                                                                    .function.free-size: size_t mps_mvff_free_size(mps_pool_t pool)
-This function returns the total size of free space in segments
-allocated to the MVFF pool instance.
                                                                                                                    
-
                                                                                                                    .function.size: size_t mps_mvff_size(mps_pool_t pool) This
-function returns the total memory used by pool segments, whether free
-or allocated.
                                                                                                                    
-
                                                                                                                    .function.class: mps_class_t mps_class_mvff(void) This function
-returns the class object for the pool class, to be used in pool
-creation.
                                                                                                                    
+
                                                                                                                    .function.free-size: mps_mvff_free_size() returns the total
+size of free space in segments allocated to the MVFF pool instance.
                                                                                                                    
+
                                                                                                                    .function.size: mps_mvff_size() returns the total memory used
+by pool segments, whether free or allocated.
                                                                                                                    
+
                                                                                                                    .function.class: mps_class_mvff() returns the class object for
+the pool class, to be used in pool creation.
                                                                                                                    
 
                                                                                                                    
 
                                                                                                                    
-
                                                                                                                    14.5. Implementation
                                                                                                                    
+
                                                                                                                    27.5. Implementation
                                                                                                                    
 
                                                                                                                    .impl.free-list: The pool stores its free list in a CBS (see
 design.mps.cbs). It uses the CBS’s mayUseInline facility to
-avoid running out of memory to store the free this. This is the reason
+avoid running out of memory to store the free list. This is the reason
 for the alignment restriction above.
                                                                                                                    
 
                                                                                                                    
 
                                                                                                                    
-
                                                                                                                    14.6. Details
                                                                                                                    
+
                                                                                                                    27.6. Details
                                                                                                                    
 
                                                                                                                    .design.seg-size: When adding a segment, we use extendBy as the
 segment size unless the object won’t fit, in which case we use the
 object size (in both cases we align up).
                                                                                                                    
 
                                                                                                                    .design.seg-fail: If allocating a segment fails, we try again with
 a segment size just large enough for the object we’re allocating. This
-is in response to request.mps.170186.
                                                                                                                    
+is in response to request.mps.170186.
                                                                                                                    
 
                                                                                                                    
 
                                                                                                                    
 
@@ -192,23 +185,23 @@ 
                                                                                                                    14.6. DetailsTable Of Contents
                                                                                                                    
   
                                                                                                            
+  
                                                                                                            
       
   
                                                                                                            one-bit reference count
   
                                                                                                            
 
-  
                                                                                                            
-  
                                                                                                            
       
   
                                                                                                            opaque type
   
                                                                                                            
 
       
-  
                                                                                                            opposed (C macro)
-  
                                                                                                            
-
-      
   
                                                                                                            out parameter
   
                                                                                                            
 
@@ -4730,8 +5289,6 @@ 
                                                                                                            P
                                                                                                            
   
 
       
                                                                                                            
-  
-  
                                                                                                            
       
   
                                                                                                            pointer
   
                                                                                                            
@@ -4746,14 +5303,6 @@ 
                                                                                                            P
                                                                                                            
 
       
                                                                                                            
         
-  
                                                                                                            AMC design
-  
                                                                                                            
-
-        
-  
                                                                                                            MVFF design
-  
                                                                                                            
-
-        
   
                                                                                                            creating, [1]
   
                                                                                                            
 
@@ -4776,6 +5325,10 @@ 
                                                                                                            P
                                                                                                            
   
 
         
+  
                                                                                                            AMC design
+  
                                                                                                            
+
+        
   
                                                                                                            AMCZ
   
                                                                                                            
 
@@ -4784,18 +5337,38 @@ 
                                                                                                            P
                                                                                                            
   
 
         
+  
                                                                                                            AMS design
+  
                                                                                                            
+
+        
   
                                                                                                            AWL
   
                                                                                                            
 
         
+  
                                                                                                            AWL design
+  
                                                                                                            
+
+        
   
                                                                                                            LO
   
                                                                                                            
 
         
+  
                                                                                                            LO design
+  
                                                                                                            
+
+        
   
                                                                                                            MFS
   
                                                                                                            
 
         
+  
                                                                                                            MFS design
+  
                                                                                                            
+
+        
+  
                                                                                                            MRG design
+  
                                                                                                            
+
+        
   
                                                                                                            MV
   
                                                                                                            
 
@@ -4804,6 +5377,10 @@ 
                                                                                                            P
                                                                                                            
   
 
         
+  
                                                                                                            MVFF design
+  
                                                                                                            
+
+        
   
                                                                                                            MVT
   
                                                                                                            
 
@@ -4836,6 +5413,32 @@ 
                                                                                                            P
                                                                                                            
 
       
                                                                                                            
       
+  
                                                                                                            PoolAddrInFrameMethod (C type)
+  
                                                                                                            
+
+      
+  
                                                                                                            PoolFramePopMethod (C type)
+  
                                                                                                            
+
+  
                                                                                                            
+  
                                                                                                            
+      
+  
                                                                                                            PoolFramePushMethod (C type)
+  
                                                                                                            
+
+      
+  
                                                                                                            PoolFrameSelectFromAddrMethod (C type)
+  
                                                                                                            
+
+      
+  
                                                                                                            PoolFrameSelectMethod (C type)
+  
                                                                                                            
+
+      
+  
                                                                                                            PoolSetFrameClassMethod (C type)
+  
                                                                                                            
+
+      
   
                                                                                                            
     porting
   
                                                                                                            
@@ -4847,6 +5450,17 @@ 
                                                                                                            P
                                                                                                            
 
       
                                                                                                            
       
+  
                                                                                                            
+    POSIX thread extensions
+  
                                                                                                            
+
+      
                                                                                                            
+        
+  
                                                                                                            design
+  
                                                                                                            
+
+      
                                                                                                            
+      
   
                                                                                                            PostScript
   
                                                                                                            
 
@@ -4935,6 +5549,25 @@ 
                                                                                                            P
                                                                                                            
 
       
       
+  
                                                                                                            
+    protection interface design
+  
                                                                                                            
+
+      
                                                                                                            
+        
+  
                                                                                                            ANSI
+  
                                                                                                            
+
+        
+  
                                                                                                            Linux
+  
                                                                                                            
+
+        
+  
                                                                                                            SunOS 4
+  
                                                                                                            
+
+      
                                                                                                            
+      
   
                                                                                                            protection violation
   
                                                                                                            
 
@@ -4978,6 +5611,34 @@ 
                                                                                                            P
                                                                                                            
   
 
       
+  
                                                                                                            PThreadext (C type)
+  
                                                                                                            
+
+      
+  
                                                                                                            PThreadextCheck (C function)
+  
                                                                                                            
+
+      
+  
                                                                                                            PThreadextFinish (C function)
+  
                                                                                                            
+
+      
+  
                                                                                                            PThreadextInit (C function)
+  
                                                                                                            
+
+      
+  
                                                                                                            PThreadextResume (C function)
+  
                                                                                                            
+
+      
+  
                                                                                                            PThreadextStruct (C type)
+  
                                                                                                            
+
+      
+  
                                                                                                            PThreadextSuspend (C function)
+  
                                                                                                            
+
+      
   
                                                                                                            
     punning
   
                                                                                                            
@@ -5013,7 +5674,7 @@ 
                                                                                                            R
                                                                                                            
   
 
       
-  
                                                                                                            ramp allocation, [1]
+  
                                                                                                            ramp allocation, [1]
   
                                                                                                            
 
       
@@ -5039,7 +5700,7 @@ 
                                                                                                            R
                                                                                                            
   
 
       
-  
                                                                                                            rash variety
+  
                                                                                                            rash variety
   
                                                                                                            
 
       
@@ -5524,10 +6185,6 @@ 
                                                                                                            S
                                                                                                            
   
 
       
-  
                                                                                                            SegPrefLOW (C macro)
-  
                                                                                                            
-
-      
   
                                                                                                            segregated allocation cache, [1]
   
                                                                                                            
 
@@ -5590,6 +6247,33 @@ 
                                                                                                            S
                                                                                                            
   
 
       
+  
                                                                                                            
+    shield
+  
                                                                                                            
+
+      
                                                                                                            
+        
+  
                                                                                                            design
+  
                                                                                                            
+
+      
                                                                                                            
+      
+  
                                                                                                            ShieldLower (C function)
+  
                                                                                                            
+
+      
+  
                                                                                                            ShieldRaise (C function)
+  
                                                                                                            
+
+      
+  
                                                                                                            ShieldResume (C function)
+  
                                                                                                            
+
+      
+  
                                                                                                            ShieldSuspend (C function)
+  
                                                                                                            
+
+      
   
                                                                                                            Shift (C type)
   
                                                                                                            
 
@@ -5624,12 +6308,6 @@ 
                                                                                                            S
                                                                                                            
   
                                                                                                            size
   
                                                                                                            
 
-      
                                                                                                            
-        
-  
                                                                                                            (C macro), [1]
-  
                                                                                                            
-
-      
                                                                                                            
       
   
                                                                                                            Size (C type)
   
                                                                                                            
@@ -5750,12 +6428,12 @@ 
                                                                                                            S
                                                                                                            
   
                                                                                                            SplayNodeInit (C function)
   
                                                                                                            
 
+  
+  
                                                                                                            
       
   
                                                                                                            SplayNodeRefresh (C function)
   
                                                                                                            
 
-  
                                                                                                            
-  
                                                                                                            
       
   
                                                                                                            SplayNodeStruct (C type)
   
                                                                                                            
@@ -5859,6 +6537,17 @@ 
                                                                                                            S
                                                                                                            
   
 
       
+  
                                                                                                            
+    stack scanner design
+  
                                                                                                            
+
+      
                                                                                                            
+        
+  
                                                                                                            Digital Unix on Alpha
+  
                                                                                                            
+
+      
                                                                                                            
+      
   
                                                                                                            
     staleness
   
                                                                                                            
@@ -5870,10 +6559,6 @@ 
                                                                                                            S
                                                                                                            
 
       
                                                                                                            
       
-  
                                                                                                            start (C macro)
-  
                                                                                                            
-
-      
   
                                                                                                            static allocation
   
                                                                                                            
 
@@ -5989,6 +6674,28 @@ 
                                                                                                            S
                                                                                                            
   
 
       
+  
                                                                                                            
+    SunOS 4
+  
                                                                                                            
+
+      
                                                                                                            
+        
+  
                                                                                                            protection interface design
+  
                                                                                                            
+
+      
                                                                                                            
+      
+  
                                                                                                            
+    SunOS 4 protection interface
+  
                                                                                                            
+
+      
                                                                                                            
+        
+  
                                                                                                            design
+  
                                                                                                            
+
+      
                                                                                                            
+      
   
                                                                                                            SUPERCLASS (C function)
   
                                                                                                            
 
@@ -6194,6 +6901,21 @@ 
                                                                                                            T
                                                                                                            
 
       
       
+  
                                                                                                            Thread (C type)
+  
                                                                                                            
+
+      
+  
                                                                                                            
+    thread manager
+  
                                                                                                            
+
+      
                                                                                                            
+        
+  
                                                                                                            design
+  
                                                                                                            
+
+      
                                                                                                            
+      
   
                                                                                                            thread safety
   
                                                                                                            
 
@@ -6208,6 +6930,26 @@ 
                                                                                                            T
                                                                                                            
 
       
       
+  
                                                                                                            ThreadDeregister (C function)
+  
                                                                                                            
+
+      
+  
                                                                                                            ThreadRegister (C function)
+  
                                                                                                            
+
+      
+  
                                                                                                            ThreadRingResume (C function)
+  
                                                                                                            
+
+      
+  
                                                                                                            ThreadRingSuspend (C function)
+  
                                                                                                            
+
+      
+  
                                                                                                            ThreadScan (C function)
+  
                                                                                                            
+
+      
   
                                                                                                            threatened set
   
                                                                                                            
 
@@ -6220,10 +6962,6 @@ 
                                                                                                            T
                                                                                                            
   
 
       
-  
                                                                                                            to (C macro)
-  
                                                                                                            
-
-      
   
                                                                                                            to space
   
                                                                                                            
 
@@ -6231,6 +6969,8 @@ 
                                                                                                            T
                                                                                                            
   
                                                                                                            tospace
   
                                                                                                            
 
+  
+  
                                                                                                            
       
   
                                                                                                            trace
   
                                                                                                            
@@ -6250,8 +6990,6 @@ 
                                                                                                            T
                                                                                                            
   
 
       
                                                                                                            
-  
-  
                                                                                                            
       
   
                                                                                                            TraceSet (C type)
   
                                                                                                            
@@ -6440,20 +7178,20 @@ 
                                                                                                            V
                                                                                                            
   
 
       
-  
                                                                                                            variety, [1]
+  
                                                                                                            variety, [1]
   
                                                                                                            
 
       
                                                                                                            
         
-  
                                                                                                            cool, [1]
+  
                                                                                                            cool, [1]
   
                                                                                                            
 
         
-  
                                                                                                            hot
+  
                                                                                                            hot
   
                                                                                                            
 
         
-  
                                                                                                            rash
+  
                                                                                                            rash
   
                                                                                                            
 
       
                                                                                                            
@@ -6491,8 +7229,6 @@ 
                                                                                                            V
                                                                                                            
   
 
       
                                                                                                            
-  
-  
                                                                                                            
       
   
                                                                                                            virtual memory
   
                                                                                                            
@@ -6501,6 +7237,14 @@ 
                                                                                                            V
                                                                                                            
   
                                                                                                            virtual memory arena
   
                                                                                                            
 
+      
                                                                                                            
+        
+  
                                                                                                            design
+  
                                                                                                            
+
+      
                                                                                                            
+  
                                                                                                            
+  
                                                                                                            
       
   
                                                                                                            virtual memory arena class
   
                                                                                                            
@@ -6520,6 +7264,39 @@ 
                                                                                                            V
                                                                                                            
 
       
                                                                                                            
       
+  
                                                                                                            
+    VM arena
+  
                                                                                                            
+
+      
                                                                                                            
+        
+  
                                                                                                            design
+  
                                                                                                            
+
+      
                                                                                                            
+      
+  
                                                                                                            
+    VM for Digital Unix
+  
                                                                                                            
+
+      
                                                                                                            
+        
+  
                                                                                                            design
+  
                                                                                                            
+
+      
                                                                                                            
+      
+  
                                                                                                            
+    VM for Solaris
+  
                                                                                                            
+
+      
                                                                                                            
+        
+  
                                                                                                            design
+  
                                                                                                            
+
+      
                                                                                                            
+      
   
                                                                                                            VMCreate (C function)
   
                                                                                                            
 
diff --git a/mps/manual/html/glossary/_Sidebar.html b/mps/manual/html/glossary/_Sidebar.html
new file mode 100644
index 00000000000..30244a7f179
--- /dev/null
+++ b/mps/manual/html/glossary/_Sidebar.html
@@ -0,0 +1,93 @@
+
+
+
+
+
+
+  
+    
+    
+    <no title> — Memory Pool System 1.111.0 documentation
+    
+    
+    
+    
+    
+    
+    
+    
+    
+     
+  
+  
+    
                                                                                                            
+      
                                                                                                            Navigation
                                                                                                            
+      
+    
                                                                                                              
+
+    
                                                                                                            
+      
                                                                                                            
+        
                                                                                                            
+          
                                                                                                            
+            
+  
+
+
+          
                                                                                                            
+        
                                                                                                            
+      
                                                                                                            
+      
                                                                                                            
+        
                                                                                                            
+            
                                                                                                            Downloads
                                                                                                            
+
+
                                                                                                            
+MPS Kit release 1.111.0
                                                                                                            
+All MPS Kit releases
+
                                                                                                            
+
+
                                                                                                            Issues
                                                                                                            
+
+
                                                                                                            
+Known issues
                                                                                                            
+Issues fixed in release 1.111.0
+
                                                                                                            Contact us
                                                                                                            
+
+
                                                                                                            mps-questions@ravenbrook.com
                                                                                                            
+        
                                                                                                            
+      
                                                                                                            
+      
                                                                                                            
+    
                                                                                                            
+    
                                                                                                            
+      
                                                                                                            Navigation
                                                                                                            
+      
+    
                                                                                                            
+    
                                                                                                            
+        © Copyright 2013, Ravenbrook Limited.
+      Created using Sphinx 1.1.3.
+    
                                                                                                            
+  
+
\ No newline at end of file
diff --git a/mps/manual/html/glossary/c.html b/mps/manual/html/glossary/c.html
index 9b257701e5e..d886f34e099 100644
--- a/mps/manual/html/glossary/c.html
+++ b/mps/manual/html/glossary/c.html
@@ -733,7 +733,7 @@ 
                                                                                                            Navigation
                                                                                                            
 
                                                                                                            The sequence of operations on which the MPS spends the
 majority of its time, consisting of scanning, fixing, marking and
 copying. See
-The critical path through the MPS.
                                                                                                            
+design-critical-path.
                                                                                                            
 
                                                                                                            
 
 
                                                                                                            crossing map
                                                                                                            
diff --git a/mps/manual/html/glossary/home.html b/mps/manual/html/glossary/home.html
new file mode 100644
index 00000000000..fd5b8867960
--- /dev/null
+++ b/mps/manual/html/glossary/home.html
@@ -0,0 +1,145 @@
+
+
+
+
+
+
+  
+    
+    
+    Memory Management Glossary — Memory Pool System 1.111.0 documentation
+    
+    
+    
+    
+    
+    
+    
+    
+    
+     
+  
+  
+    
                                                                                                            
+      
                                                                                                            Navigation
                                                                                                            
+      
+    
                                                                                                              
+
+    
                                                                                                            
+      
                                                                                                            
+        
                                                                                                            
+          
                                                                                                            
+            
+  
+
+
+          
                                                                                                            
+        
                                                                                                            
+      
                                                                                                            
+      
                                                                                                            
+        
                                                                                                            
+            
                                                                                                            Downloads
                                                                                                            
+
+
                                                                                                            
+MPS Kit release 1.111.0
                                                                                                            
+All MPS Kit releases
+
                                                                                                            
+
+
                                                                                                            Issues
                                                                                                            
+
+
                                                                                                            
+Known issues
                                                                                                            
+Issues fixed in release 1.111.0
+
                                                                                                            Contact us
                                                                                                            
+
+
                                                                                                            mps-questions@ravenbrook.com
                                                                                                            
+        
                                                                                                            
+      
                                                                                                            
+      
                                                                                                            
+    
                                                                                                            
+    
                                                                                                            
+      
                                                                                                            Navigation
                                                                                                            
+      
+    
                                                                                                            
+    
                                                                                                            
+        © Copyright 2013, Ravenbrook Limited.
+      Created using Sphinx 1.1.3.
+    
                                                                                                            
+  
+
\ No newline at end of file
diff --git a/mps/manual/html/guide/advanced.html b/mps/manual/html/guide/advanced.html
index 68a8e5ad86c..3848fcd1ee1 100644
--- a/mps/manual/html/guide/advanced.html
+++ b/mps/manual/html/guide/advanced.html
@@ -61,8 +61,8 @@ 
                                                                                                            Navigation
                                                                                                            
 
                                                                                                            In Scheme, an open file is represented by a port. In the toy Scheme
 interpreter, a port is a wrapper around a standard C file handle:
                                                                                                            
 
                                                                                                            typedef struct port_s {
-    type_t type;                    /* TYPE_PORT */
-    obj_t name;                     /* name of stream */
+    type_t type;                    /* TYPE_PORT */
+    obj_t name;                     /* name of stream */
     FILE *stream;
 } port_s;
 
                                                                                                            
@@ -84,14 +84,14 @@ 
                                                                                                            Navigation
                                                                                                            
 
                                                                                                            Any block in an automatically managed pool can be registered for finalization by calling
 mps_finalize(). In the toy Scheme interpreter, this can be done
 in make_port:
                                                                                                            
-
                                                                                                             static obj_t make_port(obj_t name, FILE *stream)
+
                                                                                                             static obj_t make_port(obj_t name, FILE *stream)
  {
-     mps_addr_t port_ref;
-     obj_t obj;
-     mps_addr_t addr;
+     mps_addr_t port_ref;
+     obj_t obj;
+     mps_addr_t addr;
      size_t size = ALIGN(sizeof(port_s));
      do {
-         mps_res_t res = mps_reserve(&addr, obj_ap, size);
+         mps_res_t res = mps_reserve(&addr, obj_ap, size);
          if (res != MPS_RES_OK) error("out of memory in make_port");
          obj = addr;
          obj->port.type = TYPE_PORT;
@@ -127,17 +127,17 @@ 
                                                                                                            Navigation
                                                                                                            
 message queue is at the start of the read–eval–print loop. When a
 finalization message is found, the associated file handle is closed
 (unless it has been closed already), and the message is discarded.
                                                                                                            
-
                                                                                                             mps_message_type_t type;
+
                                                                                                             mps_message_type_t type;
 
  while (mps_message_queue_type(&type, arena)) {
-     mps_message_t message;
-     mps_bool_t b;
+     mps_message_t message;
+     mps_bool_t b;
      b = mps_message_get(&message, arena, type);
      assert(b); /* we just checked there was one */
 
      if (type == mps_message_type_finalization()) {
-         mps_addr_t port_ref;
-         obj_t port;
+         mps_addr_t port_ref;
+         obj_t port;
          mps_message_finalization_ref(&port_ref, arena, message);
          port = port_ref;
          assert(TYPE(port) == TYPE_PORT);
@@ -176,11 +176,11 @@ 
                                                                                                            Navigation
                                                                                                            
 optimization: setting stream to NULL ensures that the file
 handle wouldn’t be closed more than once, even if the port object were
 later finalized.
                                                                                                            
-
                                                                                                            static void port_close(obj_t port)
+
                                                                                                            static void port_close(obj_t port)
 {
     assert(TYPE(port) == TYPE_PORT);
     if(port->port.stream != NULL) {
-        mps_addr_t port_ref = port;
+        mps_addr_t port_ref = port;
         fclose(port->port.stream);
         port->port.stream = NULL;
         mps_definalize(arena, &port_ref);
@@ -253,24 +253,24 @@ 
                                                                                                            Navigation
                                                                                                            
 case of a hash table, it is most convenient to inline it in the hash
 table’s metadata:
                                                                                                            
 
                                                                                                            typedef struct table_s {
-  type_t type;                  /* TYPE_TABLE */
-  hash_t hash;                  /* hash function */
-  cmp_t cmp;                    /* comparison function */
+  type_t type;                  /* TYPE_TABLE */
+  hash_t hash;                  /* hash function */
+  cmp_t cmp;                    /* comparison function */
   mps_ld_s ld;                  /* location dependency */
-  obj_t buckets;                /* hash buckets */
+  obj_t buckets;                /* hash buckets */
 } table_s;
 
                                                                                                            
 
                                                                                                            
 
                                                                                                            Before being used, the location dependency must be reset to indicate
 that nothing is depended upon, by calling mps_ld_reset().
                                                                                                            
 
                                                                                                            For example:
                                                                                                            
-
                                                                                                            static obj_t make_table(size_t length, hash_t hashf, cmp_t cmpf)
+
                                                                                                            static obj_t make_table(size_t length, hash_t hashf, cmp_t cmpf)
 {
-    obj_t obj;
-    mps_addr_t addr;
+    obj_t obj;
+    mps_addr_t addr;
     size_t l, size = ALIGN(sizeof(table_s));
     do {
-        mps_res_t res = mps_reserve(&addr, obj_ap, size);
+        mps_res_t res = mps_reserve(&addr, obj_ap, size);
         if (res != MPS_RES_OK) error("out of memory in make_table");
         obj = addr;
         obj->table.type = TYPE_TABLE;
@@ -296,12 +296,12 @@ 
                                                                                                            Navigation
                                                                                                            
 dependency.)
                                                                                                            
 
                                                                                                            In the toy Scheme interpreter, this is done just before the computation
 of the hash of the address.
                                                                                                            
-
                                                                                                            static unsigned long eq_hash(obj_t obj, mps_ld_t ld)
+
                                                                                                            static unsigned long eq_hash(obj_t obj, mps_ld_t ld)
 {
-    union {char s[sizeof(obj_t)]; obj_t addr;} u;
+    union {char s[sizeof(obj_t)]; obj_t addr;} u;
     if (ld) mps_ld_add(ld, arena, obj);
     u.addr = obj;
-    return hash(u.s, sizeof(obj_t));
+    return hash(u.s, sizeof(obj_t));
 }
 
                                                                                                            
 
                                                                                                            
@@ -309,7 +309,7 @@ 
                                                                                                            Navigation
                                                                                                            
 avoids adding unnecessary dependencies on a location. For example, an
 eqv? hash table does not need to depend on the location of numbers
 and characters:
                                                                                                            
-
                                                                                                            static unsigned long eqv_hash(obj_t obj, mps_ld_t ld)
+
                                                                                                            static unsigned long eqv_hash(obj_t obj, mps_ld_t ld)
 {
     switch(TYPE(obj)) {
         case TYPE_INTEGER:
@@ -339,7 +339,7 @@ 
                                                                                                            Navigation
                                                                                                            
 function mps_ld_isstale() tells you if any of the blocks whose
 locations you depended upon since the last call to
 mps_ld_reset() might have moved.
                                                                                                            
-
                                                                                                            static obj_t table_ref(obj_t tbl, obj_t key)
+
                                                                                                            static obj_t table_ref(obj_t tbl, obj_t key)
 {
     struct bucket_s *b = buckets_find(tbl, tbl->table.buckets, key, NULL);
     if (b && b->key != NULL && b->key != obj_deleted)
@@ -425,7 +425,7 @@ 
                                                                                                            Navigation
                                                                                                            
 
                                                                                                            Don’t forget to check the location dependency for staleness if you are
 about to delete a key from a hash table but discover that it’s not
 there. In the toy Scheme interpreter, deletion looks like this:
                                                                                                            
-
                                                                                                            static void table_delete(obj_t tbl, obj_t key)
+
                                                                                                            static void table_delete(obj_t tbl, obj_t key)
 {
     struct bucket_s *b;
     assert(TYPE(tbl) == TYPE_TABLE);
@@ -500,9 +500,9 @@ 
                                                                                                            Navigation
                                                                                                            
 and values to have different ranks.
                                                                                                            
 
                                                                                                            These vectors will be allocated from an AWL pool with two allocation
 points, one for strong references, and one for weak references:
                                                                                                            
-
                                                                                                            static mps_pool_t buckets_pool; /* pool for hash table buckets */
-static mps_ap_t strong_buckets_ap; /* allocation point for strong buckets */
-static mps_ap_t weak_buckets_ap; /* allocation point for weak buckets */
+
                                                                                                            static mps_pool_t buckets_pool; /* pool for hash table buckets */
+static mps_ap_t strong_buckets_ap; /* allocation point for strong buckets */
+static mps_ap_t weak_buckets_ap; /* allocation point for weak buckets */
 
                                                                                                            
 
                                                                                                            
 
                                                                                                            
@@ -515,16 +515,16 @@ 
                                                                                                            Navigation
                                                                                                            
 replacing it with a null pointer when it is fixed by the object
 format’s scan method. So the scan method for the buckets is
 going to have the following structure. (See below for the actual code.)
                                                                                                            
-
                                                                                                            static mps_res_t buckets_scan(mps_ss_t ss, mps_addr_t base, mps_addr_t limit)
+
                                                                                                            static mps_res_t buckets_scan(mps_ss_t ss, mps_addr_t base, mps_addr_t limit)
 {
     MPS_SCAN_BEGIN(ss) {
         while (base < limit) {
-            buckets_t buckets = base;
+            buckets_t buckets = base;
             size_t length = buckets->length;
             for (i = 0; i < length; ++i) {
-                mps_addr_t p = buckets->bucket[i];
+                mps_addr_t p = buckets->bucket[i];
                 if (MPS_FIX1(ss, p)) {
-                    mps_res_t res = MPS_FIX2(ss, &p);
+                    mps_res_t res = MPS_FIX2(ss, &p);
                     if (res != MPS_RES_OK) return res;
                     if (p == NULL) {
                         /* TODO: key/value was splatted: splat value/key too */
@@ -556,9 +556,9 @@ 
                                                                                                            Navigation
                                                                                                            
 
                                                                                                            The AWL pool determines an object’s dependent object by calling a
 function that you supply when creating the pool. This means that each
 object needs to have a reference to its dependent object:
                                                                                                            
-
                                                                                                            static mps_addr_t buckets_find_dependent(mps_addr_t addr)
+
                                                                                                            static mps_addr_t buckets_find_dependent(mps_addr_t addr)
 {
-    buckets_t buckets = addr;
+    buckets_t buckets = addr;
     return buckets->dependent;
 }
 
                                                                                                            
@@ -580,25 +580,25 @@ 
                                                                                                            Navigation
                                                                                                            
     size_t length;                /* number of buckets (tagged) */
     size_t used;                  /* number of buckets in use (tagged) */
     size_t deleted;               /* number of deleted buckets (tagged) */
-    obj_t bucket[1];              /* hash buckets */
-} buckets_s, *buckets_t;
+    obj_t bucket[1];              /* hash buckets */
+} buckets_s, *buckets_t;
 
                                                                                                            
 
                                                                                                            
 
                                                                                                            Now the full details of the scan method can be given, with the revised
 code highlighted:
                                                                                                            
-
                                                                                                            static mps_res_t buckets_scan(mps_ss_t ss, mps_addr_t base, mps_addr_t limit)
+
                                                                                                            static mps_res_t buckets_scan(mps_ss_t ss, mps_addr_t base, mps_addr_t limit)
 {
     MPS_SCAN_BEGIN(ss) {
         while (base < limit) {
-            buckets_t buckets = base;
+            buckets_t buckets = base;
             size_t i, length = UNTAG_SIZE(buckets->length);
             FIX(buckets->dependent);
             if(buckets->dependent != NULL)
                 assert(buckets->dependent->length == buckets->length);
             for (i = 0; i < length; ++i) {
-                mps_addr_t p = buckets->bucket[i];
+                mps_addr_t p = buckets->bucket[i];
                 if (MPS_FIX1(ss, p)) {
-                    mps_res_t res = MPS_FIX2(ss, &p);
+                    mps_res_t res = MPS_FIX2(ss, &p);
                     if (res != MPS_RES_OK) return res;
                     if (p == NULL) {
                         /* key/value was splatted: splat value/key too */
@@ -649,9 +649,9 @@ 
                                                                                                            Navigation
                                                                                                            
 
                                                                                                          
 
                                                                                                          
 
                                                                                                          The skip method is straightforward:
                                                                                                          
-
                                                                                                          static mps_addr_t buckets_skip(mps_addr_t base)
+
                                                                                                          static mps_addr_t buckets_skip(mps_addr_t base)
 {
-    buckets_t buckets = base;
+    buckets_t buckets = base;
     size_t length = UNTAG_SIZE(buckets->length);
     return (char *)base +
         ALIGN(offsetof(buckets_s, bucket) +
@@ -758,15 +758,15 @@ 
                                                                                                          Navigation
                                                                                                          
 
 
                                                                                                          Here’s the new symbol structure:
                                                                                                          
 
                                                                                                          typedef struct symbol_s {
-    type_t type;                  /* TYPE_SYMBOL */
-    obj_t name;                   /* its name (a string) */
+    type_t type;                  /* TYPE_SYMBOL */
+    obj_t name;                   /* its name (a string) */
 } symbol_s;
 
                                                                                                          
 
                                                                                                          
 
                                                                                                          and the new implementation of intern:
                                                                                                          
-
                                                                                                          static obj_t intern_string(obj_t name)
+
                                                                                                          static obj_t intern_string(obj_t name)
 {
-    obj_t symbol;
+    obj_t symbol;
     assert(TYPE(name) == TYPE_STRING);
     symbol = table_ref(symtab, name);
     if(symbol == NULL) {
@@ -776,7 +776,7 @@ 
                                                                                                          Navigation
                                                                                                          
     return symbol;
 }
 
-static obj_t intern(char *string)
+static obj_t intern(char *string)
 {
     return intern_string(make_string(strlen(string), string));
 }
@@ -784,7 +784,7 @@ 
                                                                                                          Navigation
                                                                                                          
 
                                                                                                          
 
                                                                                                          The symbol table now becomes a very simple root, that only has
 to be registered once (not every time it is rehashed, as previously):
                                                                                                          
-
                                                                                                          mps_addr_t ref;
+
                                                                                                          mps_addr_t ref;
 symtab = NULL;
 ref = &symtab;
 res = mps_root_create_table(&symtab_root, arena, mps_rank_exact(), 0,
@@ -822,7 +822,11 @@ 
                                                                                                          Navigation
                                                                                                          
 
                                                                                                          6.5. Segregation of objects
                                                                                                          
 
                                                                                                          When objects of different types have different properties (different
 sizes, lifetimes, references, layouts) it makes sense to segregate
-them into pools of appropriate classes.
                                                                                                          
+them into pools of appropriate classes. The garbage collector in the
+MPS is designed to work efficiently with many pools: it traces
+references between objects in different pools, and it coordinates the
+scanning of the registers and control stacks (see
+Thread roots).
                                                                                                          
 
                                                                                                          For example, the toy Scheme interpreter has a mixture of object types,
 some of which contain references to other objects (for example, pairs)
 that must be scanned, and some of which do not (for
@@ -832,8 +836,8 @@ 
                                                                                                          Navigation
                                                                                                          
 
                                                                                                          Here the appropriate class is AMCZ (Automatic Mostly-Copying Zero-rank), and the necessary code
 changes are straightforward. First, global variables for the new pool
 and its allocation point:
                                                                                                          
-
                                                                                                          static mps_pool_t leaf_pool;    /* pool for leaf objects */
-static mps_ap_t leaf_ap;        /* allocation point for leaf objects */
+
                                                                                                          static mps_pool_t leaf_pool;    /* pool for leaf objects */
+static mps_ap_t leaf_ap;        /* allocation point for leaf objects */
 
                                                                                                          
 
                                                                                                          
 
                                                                                                          Second, the leaf objects must be allocated on leaf_ap instead of
diff --git a/mps/manual/html/guide/debug.html b/mps/manual/html/guide/debug.html
index 6b4684fb187..5666b612f69 100644
--- a/mps/manual/html/guide/debug.html
+++ b/mps/manual/html/guide/debug.html
@@ -113,11 +113,11 @@ 
                                                                                                          Navigation
                                                                                                          
 handle SIGBUS pass nostop noprint
 
                                                                                                          
 
                                                                                                          
-
                                                                                                          If you are using GDB on Linux, run this command:
                                                                                                          
-
                                                                                                          handle SIGXFSZ pass nostop noprint
+
                                                                                                          If you are using GDB on Linux or FreeBSD, run this command:
                                                                                                          
+
                                                                                                          handle SIGSEGV pass nostop noprint
 
                                                                                                          
 
                                                                                                          
-
                                                                                                          (On either operating system, you can add these commands to your
+
                                                                                                          (On these operating systems, you can add these commands to your
 .gdbinit if you always want them to be run.)
                                                                                                          
 
 
@@ -227,13 +227,13 @@ 
                                                                                                          Navigation
                                                                                                          
 
                                                                                                          4.3. Example: allocating with wrong size
                                                                                                          
 
                                                                                                          Here’s another kind of mistake: an off-by-one error in make_string
 leading to the allocation of string objects with the wrong size:
                                                                                                          
-
                                                                                                          static obj_t make_string(size_t length, char *string)
+
                                                                                                          static obj_t make_string(size_t length, char *string)
 {
-  obj_t obj;
-  mps_addr_t addr;
+  obj_t obj;
+  mps_addr_t addr;
   size_t size = ALIGN(offsetof(string_s, string) + length/* oops, forgot: +1 */);
   do {
-    mps_res_t res = mps_reserve(&addr, obj_ap, size);
+    mps_res_t res = mps_reserve(&addr, obj_ap, size);
     if (res != MPS_RES_OK) error("out of memory in make_string");
     obj = addr;
     obj->string.type = TYPE_STRING;
diff --git a/mps/manual/html/guide/lang.html b/mps/manual/html/guide/lang.html
index ae2dd57bb00..59c692066a8 100644
--- a/mps/manual/html/guide/lang.html
+++ b/mps/manual/html/guide/lang.html
@@ -90,7 +90,7 @@ 
                                                                                                          Navigation
                                                                                                          
 
                                                                                                          A Scheme object (whose type is not necessarily known) is represented by
 an obj_t, which is a pointer to a union of every type in the
 language:
                                                                                                          
-
                                                                                                          typedef union obj_u *obj_t;
+
                                                                                                          typedef union obj_u *obj_t;
 typedef union obj_u {
     type_s type;
     pair_s pair;
@@ -113,8 +113,8 @@ 
                                                                                                          Navigation
                                                                                                          
 represented by a pointer to the structure pair_s defined as
 follows:
                                                                                                          
 
                                                                                                          typedef struct pair_s {
-    type_t type;        /* TYPE_PAIR */
-    obj_t car, cdr;     /* first and second projections */
+    type_t type;        /* TYPE_PAIR */
+    obj_t car, cdr;     /* first and second projections */
 } pair_s;
 
                                                                                                          
 
                                                                                                          
@@ -122,7 +122,7 @@ 
                                                                                                          Navigation
                                                                                                          
 operate on objects generically, testing TYPE(obj) as necessary
 (which is a macro for obj->type.type). For example, the
 print() function is implemented like this:
                                                                                                          
-
                                                                                                          static void print(obj_t obj, unsigned depth, FILE *stream)
+
                                                                                                          static void print(obj_t obj, unsigned depth, FILE *stream)
 {
     switch (TYPE(obj)) {
     case TYPE_INTEGER:
@@ -140,9 +140,9 @@ 
                                                                                                          Navigation
                                                                                                          
 
                                                                                                          
 
                                                                                                          Each constructor allocates memory for the new object by calling
 malloc. For example, make_pair is the constructor for pairs:
                                                                                                          
-
                                                                                                          static obj_t make_pair(obj_t car, obj_t cdr)
+
                                                                                                          static obj_t make_pair(obj_t car, obj_t cdr)
 {
-    obj_t obj = (obj_t)malloc(sizeof(pair_s));
+    obj_t obj = (obj_t)malloc(sizeof(pair_s));
     if (obj == NULL) error("out of memory");
     obj->pair.type = TYPE_PAIR;
     CAR(obj) = car;
@@ -181,7 +181,7 @@ 
                                                                                                          Navigation
                                                                                                          
 
                                                                                                          There’s only one arena, and many MPS functions take an arena as an
 argument, so it makes sense for the arena to be a global variable
 rather than having to pass it around everywhere:
                                                                                                          
-
                                                                                                          static mps_arena_t arena;
+
                                                                                                          static mps_arena_t arena;
 
                                                                                                          
 
                                                                                                          
 
                                                                                                          Create an arena by calling mps_arena_create_k(). This function
@@ -201,7 +201,7 @@ 
                                                                                                          Navigation
                                                                                                          
 Keyword arguments for the full details.
                                                                                                          
 
                                                                                                          
 
                                                                                                          Let’s reserve 32 megabytes:
                                                                                                          
-
                                                                                                          mps_res_t res;
+
                                                                                                          mps_res_t res;
 MPS_ARGS_BEGIN(args) {
     MPS_ARGS_ADD(args, MPS_KEY_ARENA_SIZE, 32 * 1024 * 1024);
     MPS_ARGS_DONE(args);
@@ -276,7 +276,7 @@ 
                                                                                                          Navigation
                                                                                                          
     obj_pad,
 };
 
-mps_fmt_t obj_fmt;
+mps_fmt_t obj_fmt;
 res = mps_fmt_create_A(&obj_fmt, arena, &obj_fmt_s);
 if (res != MPS_RES_OK) error("Couldn't create obj format");
 
                                                                                                          
@@ -334,11 +334,11 @@ 
                                                                                                          Navigation
                                                                                                          
 discover references and so determine which objects are alive and which are dead, and also to update references
 after objects have been moved.
                                                                                                          
 
                                                                                                          Here’s the scan method for the toy Scheme interpreter:
                                                                                                          
-
                                                                                                          static mps_res_t obj_scan(mps_ss_t ss, mps_addr_t base, mps_addr_t limit)
+
                                                                                                          static mps_res_t obj_scan(mps_ss_t ss, mps_addr_t base, mps_addr_t limit)
 {
     MPS_SCAN_BEGIN(ss) {
         while (base < limit) {
-            obj_t obj = base;
+            obj_t obj = base;
             switch (TYPE(obj)) {
             case TYPE_PAIR:
                 FIX(CAR(obj));
@@ -416,9 +416,9 @@ 
                                                                                                          Navigation
                                                                                                          
 mps_fmt_skip_t. It is called by the MPS to skip over an
 object belonging to the format, and also to determine its size.
                                                                                                          
 
                                                                                                          Here’s the skip method for the toy Scheme interpreter:
                                                                                                          
-
                                                                                                          static mps_addr_t obj_skip(mps_addr_t base)
+
                                                                                                          static mps_addr_t obj_skip(mps_addr_t base)
 {
-    obj_t obj = base;
+    obj_t obj = base;
     switch (TYPE(obj)) {
     case TYPE_PAIR:
         base = (char *)base + ALIGN(sizeof(pair_s));
@@ -471,24 +471,24 @@ 
                                                                                                          Navigation
                                                                                                          
 The first type is suitable for forwarding objects of three words or
 longer:
                                                                                                          
 
                                                                                                          typedef struct fwd_s {
-    type_t type;                  /* TYPE_FWD */
-    obj_t fwd;                    /* forwarded object */
+    type_t type;                  /* TYPE_FWD */
+    obj_t fwd;                    /* forwarded object */
     size_t size;                  /* total size of this object */
 } fwd_s;
 
                                                                                                          
 
                                                                                                          
 
                                                                                                          while the second type is suitable for forwarding objects of two words:
                                                                                                          
 
                                                                                                          typedef struct fwd2_s {
-    type_t type;                  /* TYPE_FWD2 */
-    obj_t fwd;                    /* forwarded object */
+    type_t type;                  /* TYPE_FWD2 */
+    obj_t fwd;                    /* forwarded object */
 } fwd2_s;
 
                                                                                                          
 
                                                                                                          
 
                                                                                                          Here’s the forward method for the toy Scheme interpreter:
                                                                                                          
-
                                                                                                          static void obj_fwd(mps_addr_t old, mps_addr_t new)
+
                                                                                                          static void obj_fwd(mps_addr_t old, mps_addr_t new)
 {
-    obj_t obj = old;
-    mps_addr_t limit = obj_skip(old);
+    obj_t obj = old;
+    mps_addr_t limit = obj_skip(old);
     size_t size = (char *)limit - (char *)old;
     assert(size >= ALIGN_UP(sizeof(fwd2_s)));
     if (size == ALIGN_UP(sizeof(fwd2_s))) {
@@ -547,9 +547,9 @@ 
                                                                                                          Navigation
                                                                                                          
 object is a forwarding object, and if it is, to determine the
 location where that object was moved.
                                                                                                          
 
                                                                                                          Here’s the is-forwarded method for the toy Scheme interpreter:
                                                                                                          
-
                                                                                                          static mps_addr_t obj_isfwd(mps_addr_t addr)
+
                                                                                                          static mps_addr_t obj_isfwd(mps_addr_t addr)
 {
-    obj_t obj = addr;
+    obj_t obj = addr;
     switch (TYPE(obj)) {
     case TYPE_FWD2:
         return obj->fwd2.fwd;
@@ -583,7 +583,7 @@ 
                                                                                                          Navigation
                                                                                                          
 types of padding object. The first type is suitable for padding
 objects of two words or longer:
                                                                                                          
 
                                                                                                          typedef struct pad_s {
-    type_t type;                  /* TYPE_PAD */
+    type_t type;                  /* TYPE_PAD */
     size_t size;                  /* total size of this object */
 } pad_s;
 
                                                                                                          
@@ -591,14 +591,14 @@ 
                                                                                                          Navigation
                                                                                                          
 
                                                                                                          while the second type is suitable for padding objects consisting of a
 single word:
                                                                                                          
 
                                                                                                          typedef struct pad1_s {
-    type_t type;                  /* TYPE_PAD1 */
+    type_t type;                  /* TYPE_PAD1 */
 } pad1_s;
 
                                                                                                          
 
                                                                                                          
 
                                                                                                          Here’s the padding method:
                                                                                                          
-
                                                                                                          static void obj_pad(mps_addr_t addr, size_t size)
+
                                                                                                          static void obj_pad(mps_addr_t addr, size_t size)
 {
-    obj_t obj = addr;
+    obj_t obj = addr;
     assert(size >= ALIGN(sizeof(pad1_s)));
     if (size == ALIGN(sizeof(pad1_s))) {
         TYPE(obj) = TYPE_PAD1;
@@ -674,7 +674,7 @@ 
                                                                                                          Navigation
                                                                                                          
 
                                                                                                          
 
                                                                                                          Second, the object format:
                                                                                                          
 
                                                                                                          struct mps_fmt_A_s obj_fmt_s = {
-    sizeof(mps_word_t),
+    sizeof(mps_word_t),
     obj_scan,
     obj_skip,
     NULL,
@@ -683,7 +683,7 @@ 
                                                                                                          Navigation
                                                                                                          
     obj_pad,
 };
 
-mps_fmt_t obj_fmt;
+mps_fmt_t obj_fmt;
 res = mps_fmt_create_A(&obj_fmt, arena, &obj_fmt_s);
 if (res != MPS_RES_OK) error("Couldn't create obj format");
 
                                                                                                          
@@ -694,7 +694,7 @@ 
                                                                                                          Navigation
                                                                                                          
     { 170, 0.45 },
 };
 
-mps_chain_t obj_chain;
+mps_chain_t obj_chain;
 res = mps_chain_create(&obj_chain,
                        arena,
                        LENGTH(obj_gen_params),
@@ -703,7 +703,7 @@ 
                                                                                                          Navigation
                                                                                                          
 
                                                                                                          
 
                                                                                                          
 
                                                                                                          And finally the pool:
                                                                                                          
-
                                                                                                          mps_pool_t obj_pool;
+
                                                                                                          mps_pool_t obj_pool;
 MPS_ARGS_BEGIN(args) {
     MPS_ARGS_ADD(args, MPS_KEY_CHAIN, obj_chain);
     MPS_ARGS_ADD(args, MPS_KEY_FORMAT, obj_fmt);
@@ -732,15 +732,15 @@ 
                                                                                                          Navigation
                                                                                                          
 describe to the MPS how to scan them for references.
                                                                                                          
 
                                                                                                          The toy Scheme interpreter has a number of static variables that point
 to heap-allocated objects. First, the special objects, including:
                                                                                                          
-
                                                                                                          static obj_t obj_empty;         /* (), the empty list */
+
                                                                                                          static obj_t obj_empty;         /* (), the empty list */
 
                                                                                                          
 
                                                                                                          
 
                                                                                                          Second, the predefined symbols, including:
                                                                                                          
-
                                                                                                          static obj_t obj_quote;         /* "quote" symbol */
+
                                                                                                          static obj_t obj_quote;         /* "quote" symbol */
 
                                                                                                          
 
                                                                                                          
 
                                                                                                          And third, the global symbol table:
                                                                                                          
-
                                                                                                          static obj_t *symtab;
+
                                                                                                          static obj_t *symtab;
 static size_t symtab_size;
 
                                                                                                          
 
                                                                                                          
@@ -751,7 +751,7 @@ 
                                                                                                          Navigation
                                                                                                          
 
                                                                                                          In the case of the toy Scheme interpreter, the root scanning function
 for the special objects and the predefined symbols could be written
 like this:
                                                                                                          
-
                                                                                                          static mps_res_t globals_scan(mps_ss_t ss, void *p, size_t s)
+
                                                                                                          static mps_res_t globals_scan(mps_ss_t ss, void *p, size_t s)
 {
     MPS_SCAN_BEGIN(ss) {
         FIX(obj_empty);
@@ -766,7 +766,7 @@ 
                                                                                                          Navigation
                                                                                                          
 
                                                                                                          but in fact the interpreter already has tables of these global
 objects, so it’s simpler and more extensible for the root scanning
 function to iterate over them:
                                                                                                          
-
                                                                                                          static mps_res_t globals_scan(mps_ss_t ss, void *p, size_t s)
+
                                                                                                          static mps_res_t globals_scan(mps_ss_t ss, void *p, size_t s)
 {
     MPS_SCAN_BEGIN(ss) {
         size_t i;
@@ -781,7 +781,7 @@ 
                                                                                                          Navigation
                                                                                                          
 
                                                                                                          
 
                                                                                                          Each root scanning function must be registered with the MPS by calling
 mps_root_create(), like this:
                                                                                                          
-
                                                                                                          mps_root_t globals_root;
+
                                                                                                          mps_root_t globals_root;
 res = mps_root_create(&globals_root, arena, mps_rank_exact(), 0,
                       globals_scan, NULL, 0);
 if (res != MPS_RES_OK) error("Couldn't register globals root");
@@ -819,11 +819,11 @@ 
                                                                                                          Navigation
                                                                                                          
 the global symbol table, but the case of a table of references is
 sufficiently common that the MPS provides a convenient (and optimized)
 function, mps_root_create_table(), for registering it:
                                                                                                          
-
                                                                                                          static mps_root_t symtab_root;
+
                                                                                                          static mps_root_t symtab_root;
 
 /* ... */
 
-mps_addr_t ref = symtab;
+mps_addr_t ref = symtab;
 res = mps_root_create_table(&symtab_root, arena, mps_rank_exact(), 0,
                             ref, symtab_size);
 if (res != MPS_RES_OK) error("Couldn't register new symtab root");
@@ -832,15 +832,15 @@ 
                                                                                                          Navigation
                                                                                                          
 
                                                                                                          The root must be re-registered whenever the global symbol table
 changes size:
                                                                                                          
 
                                                                                                          static void rehash(void) {
-    obj_t *old_symtab = symtab;
+    obj_t *old_symtab = symtab;
     unsigned old_symtab_size = symtab_size;
-    mps_root_t old_symtab_root = symtab_root;
+    mps_root_t old_symtab_root = symtab_root;
     unsigned i;
-    mps_addr_t ref;
-    mps_res_t res;
+    mps_addr_t ref;
+    mps_res_t res;
 
     symtab_size *= 2;
-    symtab = malloc(sizeof(obj_t) * symtab_size);
+    symtab = malloc(sizeof(obj_t) * symtab_size);
     if (symtab == NULL) error("out of memory");
 
     /* Initialize the new table to NULL so that "find" will work. */
@@ -854,7 +854,7 @@ 
                                                                                                          Navigation
                                                                                                          
 
     for (i = 0; i < old_symtab_size; ++i)
         if (old_symtab[i] != NULL) {
-            obj_t *where = find(old_symtab[i]->symbol.string);
+            obj_t *where = find(old_symtab[i]->symbol.string);
             assert(where != NULL);    /* new table shouldn't be full */
             assert(*where == NULL);   /* shouldn't be in new table */
             *where = old_symtab[i];
@@ -917,7 +917,7 @@ 
                                                                                                          Navigation
                                                                                                          
 
 
                                                                                                          You register a thread with an arena by calling
 mps_thread_reg():
                                                                                                          
-
                                                                                                          mps_thr_t thread;
+
                                                                                                          mps_thr_t thread;
 res = mps_thread_reg(&thread, arena);
 if (res != MPS_RES_OK) error("Couldn't register thread");
 
                                                                                                          
@@ -926,7 +926,7 @@ 
                                                                                                          Navigation
                                                                                                          
 calling mps_root_create_reg() and passing
 mps_stack_scan_ambig():
                                                                                                          
 
                                                                                                          void *marker = &marker;
-mps_root_t reg_root;
+mps_root_t reg_root;
 res = mps_root_create_reg(&reg_root,
                           arena,
                           mps_rank_ambig(),
@@ -957,11 +957,11 @@ 
                                                                                                          Navigation
                                                                                                          
 
                                                                                                          Manual pools typically support
 malloc-like allocation using the function
 mps_alloc(). But automatic pools cannot, because of the following problem:
                                                                                                          
-
                                                                                                          static obj_t make_pair(obj_t car, obj_t cdr)
+
                                                                                                          static obj_t make_pair(obj_t car, obj_t cdr)
 {
-    obj_t obj;
-    mps_addr_t addr;
-    mps_res_t res;
+    obj_t obj;
+    mps_addr_t addr;
+    mps_res_t res;
     res = mps_alloc(&addr, pool, sizeof(pair_s));
     if (res != MPS_RES_OK) error("out of memory in make_pair");
     obj = addr;
@@ -984,7 +984,7 @@ 
                                                                                                          Navigation
                                                                                                          
 Allocation point protocol. This needs an additional
 structure, an allocation point, to be attached to the pool by
 calling mps_ap_create_k():
                                                                                                          
-
                                                                                                          static mps_ap_t obj_ap;
+
                                                                                                          static mps_ap_t obj_ap;
 
 /* ... */
 
@@ -993,13 +993,13 @@ 
                                                                                                          Navigation
                                                                                                          
 
                                                                                                          
 
                                                                                                          
 
                                                                                                          And then the constructor can be implemented like this:
                                                                                                          
-
                                                                                                          static obj_t make_pair(obj_t car, obj_t cdr)
+
                                                                                                          static obj_t make_pair(obj_t car, obj_t cdr)
 {
-    obj_t obj;
-    mps_addr_t addr;
+    obj_t obj;
+    mps_addr_t addr;
     size_t size = ALIGN(sizeof(pair_s));
     do {
-        mps_res_t res = mps_reserve(&addr, obj_ap, size);
+        mps_res_t res = mps_reserve(&addr, obj_ap, size);
         if (res != MPS_RES_OK) error("out of memory in make_pair");
         obj = addr;
         obj->pair.type = TYPE_PAIR;
diff --git a/mps/manual/html/guide/overview.html b/mps/manual/html/guide/overview.html
index 5a20b0269de..acf999156d1 100644
--- a/mps/manual/html/guide/overview.html
+++ b/mps/manual/html/guide/overview.html
@@ -126,18 +126,20 @@ 
                                                                                                          Navigation
                                                                                                          
 
                                                                                                          Formatted pools need you to tell them how to
 scan for references to allocated blocks. See
 Scanning.
                                                                                                          
-
                                                                                                          The arena needs you to tell it how to find your roots: references to
-allocated blocks that are stored in static data, in memory not managed
-by the MPS, or on your program’s registers or
+
                                                                                                          The arena needs you to tell it how to find your roots: references
+to allocated blocks that are stored in static data, in memory not
+managed by the MPS, in your program’s registers, or on its
 control stack. See Roots.
                                                                                                          
 
                                                                                                          The MPS is designed to work with multi-threaded programs. Functions in
-the C interface are thread safe, except in a few documented
-cases. See Threads. The allocation point
-protocol provides fast lock-free allocation on multiple threads
-simultaneously. See Allocation.
                                                                                                          
-
                                                                                                          The garbage collector is incremental: it proceeds in small steps interleaved with the execution
-of your program, so there are no long waits. See
-Garbage collection.
                                                                                                          
+the C interface are thread safe, except in a few documented cases. See
+Threads. The allocation point protocol provides
+fast lock-free allocation on multiple threads simultaneously. See
+Allocation.
                                                                                                          
+
                                                                                                          The garbage collector is incremental: it proceeds in small steps interleaved with the
+execution of your program, so there are no long waits. The garbage
+collector is designed to work efficiently with multiple pools, and
+in cases where there are many references between objects in different
+pools. See Garbage collection.
                                                                                                          
 
                                                                                                          
 
                                                                                                          
 
                                                                                                          1.3. What next?
                                                                                                          
diff --git a/mps/manual/html/index.html b/mps/manual/html/index.html
index 1a81392eba4..12740e822d2 100644
--- a/mps/manual/html/index.html
+++ b/mps/manual/html/index.html
@@ -106,41 +106,65 @@ 
                                                                                                          Memory Pool System1. MPS Configuration
 
                                                                                                        • 2. The critical path through the MPS
                                                                                                          • 
 
                                                                                                        • 3. Transliterating the alphabet into hexadecimal
                                                                                                          • 
-
                                                                                                        • 4. Keyword arguments in the MPS
                                                                                                          • 
-
                                                                                                        • 5. Ring data structure
                                                                                                          • 
-
                                                                                                        • 6. Signatures in the MPS
                                                                                                          • 
+
                                                                                                        • 4. C Style – formatting
                                                                                                          • 
+
                                                                                                        • 5. Keyword arguments in the MPS
                                                                                                          • 
+
                                                                                                        • 6. Ring data structure
                                                                                                          • 
+
                                                                                                        • 7. Signatures in the MPS
                                                                                                          • 
 
                                                                                                        
 
 
                                                                                                      • Old design
 
                                                                                                        • 
 
                                                                                                      
diff --git a/mps/manual/html/mmref/index.html b/mps/manual/html/mmref/index.html
index dd024cc122c..dc77d21b0e0 100644
--- a/mps/manual/html/mmref/index.html
+++ b/mps/manual/html/mmref/index.html
@@ -28,7 +28,7 @@
     
     
     
-     
+     
   
   
     
                                                                                                      
@@ -41,7 +41,7 @@ 
                                                                                                      Navigation
                                                                                                      
           next |
                                                                                                      • 
         
                                                                                                    • 
-          previous |
                                                                                                      • 
         
                                                                                                    • Memory Pool System 1.111.0 documentation »
                                                                                                      •  
       
                                                                                                    
@@ -100,7 +100,7 @@ 
                                                                                                    Introduction to memory management24. The WriteF function
                                                                                                    
+                        title="previous chapter">52. The WriteF function
                                                                                                    
   
                                                                                                    Next topic
                                                                                                    
   
                                                                                                    1. Overview
                                                                                                    Downloads
                                                                                                    
@@ -132,7 +132,7 @@ 
                                                                                                    Navigation
                                                                                                    
           next |
                                                                                                    • 
         
                                                                                                  • 
-          previous |
                                                                                                    • 
         
                                                                                                  • Memory Pool System 1.111.0 documentation »
                                                                                                    •  
       
                                                                                                  
diff --git a/mps/manual/html/objects.inv b/mps/manual/html/objects.inv
index b8af9d60616..c7f6200715b 100644
Binary files a/mps/manual/html/objects.inv and b/mps/manual/html/objects.inv differ
diff --git a/mps/manual/html/pool/amc.html b/mps/manual/html/pool/amc.html
index 543eb275476..c0476ad346e 100644
--- a/mps/manual/html/pool/amc.html
+++ b/mps/manual/html/pool/amc.html
@@ -140,10 +140,10 @@ 
                                                                                                  Navigation
                                                                                                  
 
                                                                                                  starting with version 1.112.
                                                                                                  
 
                                                                                                  When using mps_pool_create(), pass the format and
 chain like this:
                                                                                                  
-
                                                                                                  mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
-                          mps_class_t mps_class_amc(),
-                          mps_fmt_t fmt,
-                          mps_chain_t chain)
+
                                                                                                  mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
+                          mps_class_t mps_class_amc(),
+                          mps_fmt_t fmt,
+                          mps_chain_t chain)
 
                                                                                                  
 
                                                                                                  
 
                                                                                                  
diff --git a/mps/manual/html/pool/amcz.html b/mps/manual/html/pool/amcz.html
index 75668225471..a4c5b1bc9f8 100644
--- a/mps/manual/html/pool/amcz.html
+++ b/mps/manual/html/pool/amcz.html
@@ -112,10 +112,10 @@ 
                                                                                                  Navigation
                                                                                                  
 
                                                                                                  starting with version 1.112.
                                                                                                  
 
                                                                                                  When using mps_pool_create(), pass the format and
 chain like this:
                                                                                                  
-
                                                                                                  mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
-                          mps_class_t mps_class_amcz(),
-                          mps_fmt_t fmt,
-                          mps_chain_t chain)
+
                                                                                                  mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
+                          mps_class_t mps_class_amcz(),
+                          mps_fmt_t fmt,
+                          mps_chain_t chain)
 
                                                                                                  
 
                                                                                                  
 
                                                                                                  
diff --git a/mps/manual/html/pool/ams.html b/mps/manual/html/pool/ams.html
index 267c99970d5..045a18aed3c 100644
--- a/mps/manual/html/pool/ams.html
+++ b/mps/manual/html/pool/ams.html
@@ -143,10 +143,10 @@ 
                                                                                                  Navigation
                                                                                                  
 
                                                                                                  starting with version 1.112.
                                                                                                  
 
                                                                                                  When using mps_pool_create(), pass the format and
 chain like this:
                                                                                                  
-
                                                                                                  mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
-                          mps_class_t mps_class_ams(),
-                          mps_fmt_t fmt,
-                          mps_chain_t chain)
+
                                                                                                  mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
+                          mps_class_t mps_class_ams(),
+                          mps_fmt_t fmt,
+                          mps_chain_t chain)
 
                                                                                                  
 
                                                                                                  
 
                                                                                                  
@@ -167,11 +167,11 @@ 
                                                                                                  Navigation
                                                                                                  
 
                                                                                                  starting with version 1.112.
                                                                                                  
 
                                                                                                  When using mps_pool_create(), pass the format,
 chain, and debugging options like this:
                                                                                                  
-
                                                                                                  mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
-                          mps_class_t mps_class_ams_debug(),
+
                                                                                                  mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
+                          mps_class_t mps_class_ams_debug(),
                           mps_debug_option_s debug_option,
-                          mps_fmt_t fmt,
-                          mps_chain_t chain)
+                          mps_fmt_t fmt,
+                          mps_chain_t chain)
 
                                                                                                  
 
                                                                                                  
 
                                                                                                  
diff --git a/mps/manual/html/pool/awl.html b/mps/manual/html/pool/awl.html
index 5321d5b39bf..492e712fdde 100644
--- a/mps/manual/html/pool/awl.html
+++ b/mps/manual/html/pool/awl.html
@@ -93,8 +93,8 @@ 
                                                                                                  Navigation
                                                                                                  
 mps_rank_exact() (to allocate ordinary objects containing
 exact references), or mps_rank_weak() (to allocate
 objects that contain weak references). For example:
                                                                                                  
-
                                                                                                  mps_ap_t ap;
-mps_res_t res;
+
                                                                                                  mps_ap_t ap;
+mps_res_t res;
 res = mps_ap_create(&ap, pool, mps_rank_weak());
 if (res != MPS_RES_OK) error("can't create allocation point");
 
                                                                                                  
@@ -169,31 +169,31 @@ 
                                                                                                  Navigation
                                                                                                  
 out for the splatting of a reference, and when this is detected, it
 splats the corresponding reference in the dependent object.
                                                                                                  
 
                                                                                                  For example:
                                                                                                  
-
                                                                                                  obj_t obj_deleted;              /* deleted entry in hash table */
+
                                                                                                  obj_t obj_deleted;              /* deleted entry in hash table */
 
 typedef struct weak_array_s {
     struct weak_array_s *dependent;
     size_t length;              /* tagged as "length * 2 + 1" */
-    obj_t slot[1];
-} weak_array_s, *weak_array_t;
+    obj_t slot[1];
+} weak_array_s, *weak_array_t;
 
 typedef weak_table_s {
     type_s type;                /* TYPE_WEAK_TABLE */
-    weak_array_t keys, values;
-} weak_table_s, *weak_table_t;
+    weak_array_t keys, values;
+} weak_table_s, *weak_table_t;
 
-mps_addr_t weak_array_find_dependent(mps_addr_t addr)
+mps_addr_t weak_array_find_dependent(mps_addr_t addr)
 {
-    weak_array_t a = addr;
+    weak_array_t a = addr;
     return a->dependent;
 }
 
-mps_res_t weak_array_scan(mps_ss_t ss, mps_addr_t base, mps_addr_t limit)
+mps_res_t weak_array_scan(mps_ss_t ss, mps_addr_t base, mps_addr_t limit)
 {
     MPS_SCAN_BEGIN(ss) {
         while (base < limit) {
-            mps_addr_t p;
-            weak_array_t a = base;
+            mps_addr_t p;
+            weak_array_t a = base;
             size_t i, length = a->length >> 1; /* untag */
             p = a->dependent;
             MPS_FIX12(ss, &p);
@@ -201,7 +201,7 @@ 
                                                                                                  Navigation
                                                                                                  
             for (i = 0; i < length; ++i) {
                 p = a->slot[i];
                 if (MPS_FIX1(ss, p)) {
-                    mps_res_t res = MPS_FIX2(ss, &p);
+                    mps_res_t res = MPS_FIX2(ss, &p);
                     if (res != MPS_RES_OK) return res;
                     if (p == NULL && a->dependent) {
                         /* key/value was splatted: splat value/key too */
@@ -337,10 +337,10 @@ 
                                                                                                  Navigation
                                                                                                  
 
                                                                                                  starting with version 1.112.
                                                                                                  
 
                                                                                                  When using mps_pool_create(), pass the format and
 find-dependent function like this:
                                                                                                  
-
                                                                                                  mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
-                          mps_class_t mps_class_awl(),
-                          mps_fmt_t fmt,
-                          mps_awl_find_dependent_t find_dependent)
+
                                                                                                  mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
+                          mps_class_t mps_class_awl(),
+                          mps_fmt_t fmt,
+                          mps_awl_find_dependent_t find_dependent)
 
                                                                                                  
 
                                                                                                  
 
                                                                                                  
@@ -366,8 +366,8 @@ 
                                                                                                  Navigation
                                                                                                  
 
                                                                                                  Deprecated
                                                                                                  
 
                                                                                                  starting with version 1.112.
                                                                                                  
 
                                                                                                  When using mps_ap_create(), pass the rank like this:
                                                                                                  
-
                                                                                                  mps_res_t mps_ap_create(mps_ap_t *ap_o, mps_pool_t pool,
-                        mps_rank_t rank)
+
                                                                                                  mps_res_t mps_ap_create(mps_ap_t *ap_o, mps_pool_t pool,
+                        mps_rank_t rank)
 
                                                                                                  
 
                                                                                                  
 
                                                                                                  
diff --git a/mps/manual/html/pool/intro.html b/mps/manual/html/pool/intro.html
index e2b12df09bc..38ffe31563a 100644
--- a/mps/manual/html/pool/intro.html
+++ b/mps/manual/html/pool/intro.html
@@ -243,7 +243,7 @@ 
                                                                                                  Navigation
                                                                                                  
 yes
 yes
 no
-no
+yes
 yes
 yes
 yes
diff --git a/mps/manual/html/pool/lo.html b/mps/manual/html/pool/lo.html
index b44879e69ec..d34ca81d0b5 100644
--- a/mps/manual/html/pool/lo.html
+++ b/mps/manual/html/pool/lo.html
@@ -139,9 +139,9 @@ 
                                                                                                  Navigation
                                                                                                  
 
                                                                                                  starting with version 1.112.
                                                                                                  
 
                                                                                                  When using mps_pool_create(), pass the format like
 this:
                                                                                                  
-
                                                                                                  mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
-                          mps_class_t mps_class_lo(),
-                          mps_fmt_t fmt)
+
                                                                                                  mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
+                          mps_class_t mps_class_lo(),
+                          mps_fmt_t fmt)
 
                                                                                                  
 
                                                                                                  
 
                                                                                                  
diff --git a/mps/manual/html/pool/mfs.html b/mps/manual/html/pool/mfs.html
index 14fe3b8992b..5d6b7eba7cf 100644
--- a/mps/manual/html/pool/mfs.html
+++ b/mps/manual/html/pool/mfs.html
@@ -59,12 +59,15 @@ 
                                                                                                  Navigation
                                                                                                  
 
                                                                                                  MFS is an manually managed
 pool class for small objects of fixed size.
                                                                                                  
 
                                                                                                  Unlike other manual pool classes, it is not subject to internal
-fragmentation.
                                                                                                  
-
                                                                                                  The implementation is very simple: unlike other pool classes
-which store their control structures separately from the allocated
-blocks, MFS maintains a stack of free blocks using a pointer in the
-free block. mps_alloc() pops this stack and mps_free()
-pushes it.
                                                                                                  
+fragmentation: if the population remains bounded, the memory usage
+remains bounded too. On the other hand, unlike MVT (Manual Variable Temporal) and
+MVFF (Manual Variable First Fit) it does not return unused memory to the arena for
+reuse by other pools.
                                                                                                  
+
                                                                                                  The implementation is very simple: unlike most other pool
+classes which store their control structures separately from the
+allocated blocks, MFS maintains a stack of free blocks using a pointer
+in the free block. mps_alloc() pops this stack and
+mps_free() pushes it.
                                                                                                  
 
                                                                                                  
 
                                                                                                  9.1. MFS properties
                                                                                                  
 
                                                                                                    
@@ -109,7 +112,7 @@ 
                                                                                                    Navigation
                                                                                                    
 
                                                                                                  
 
                                                                                                  In addition, mps_pool_create_k() may take:
                                                                                                  
 
                                                                                                    
-
                                                                                                  • MPS_KEY_EXTEND_BY (type size_t, default 65536) is the
+
                                                                                                  • MPS_KEY_EXTEND_BY (type size_t, default 65536) is the
 size of segment that the pool will request from the
 arena. It must be at least as big as the unit size
 specified by the MPS_KEY_MFS_UNIT_SIZE keyword
@@ -130,10 +133,10 @@ 
                                                                                                    Navigation
                                                                                                    
 
                                                                                                    starting with version 1.112.
                                                                                                    
 
                                                                                                    When using mps_pool_create(), pass the segment size and
 unit size like this:
                                                                                                    
-
                                                                                                    mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
-                          mps_class_t mps_class_mfs(),
-                          mps_size_t extend_size,
-                          mps_size_t unit_size)
+
                                                                                                    mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
+                          mps_class_t mps_class_mfs(),
+                          mps_size_t extend_size,
+                          mps_size_t unit_size)
 
                                                                                                    
 
                                                                                                    
 
                                                                                                    
diff --git a/mps/manual/html/pool/mv.html b/mps/manual/html/pool/mv.html
index 3dad82d96d1..3c4a86920b9 100644
--- a/mps/manual/html/pool/mv.html
+++ b/mps/manual/html/pool/mv.html
@@ -100,10 +100,10 @@ 
                                                                                                    Navigation
                                                                                                    
 
                                                                                                    When creating an MV pool, mps_pool_create_k() may take
 three keyword arguments:
                                                                                                    
 
                                                                                                      
-
                                                                                                    • MPS_KEY_EXTEND_BY (type size_t, default 65536) is the
+
                                                                                                    • MPS_KEY_EXTEND_BY (type size_t, default 65536) is the
 size of segment that the pool will request from the
 arena.
                                                                                                      • 
-
                                                                                                    • MPS_KEY_MEAN_SIZE (type size_t, default 32) is the
+
                                                                                                    • MPS_KEY_MEAN_SIZE (type size_t, default 32) is the
 predicted mean size of blocks that will be allocated from the
 pool.
                                                                                                      • 
 
                                                                                                    • MPS_KEY_MAX_SIZE (type size_t, default 65536) is the
@@ -127,11 +127,11 @@ 
                                                                                                      Navigation
                                                                                                      
 
                                                                                                      starting with version 1.112.
                                                                                                      
 
                                                                                                      When using mps_pool_create(), pass the segment size,
 mean size, and maximum size like this:
                                                                                                      
-
                                                                                                      mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
-                          mps_class_t mps_class_mv(),
-                          mps_size_t extend_size,
-                          mps_size_t average_size,
-                          mps_size_t maximum_size)
+
                                                                                                      mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
+                          mps_class_t mps_class_mv(),
+                          mps_size_t extend_size,
+                          mps_size_t average_size,
+                          mps_size_t maximum_size)
 
                                                                                                      
 
                                                                                                      
 
                                                                                                      
@@ -144,7 +144,7 @@ 
                                                                                                      Navigation
                                                                                                      
 class.
                                                                                                      
 
                                                                                                      When creating a debugging MV pool, mps_pool_create_k()
 requires four keyword arguments: MPS_KEY_EXTEND_SIZE,
-MPS_KEY_MEAN_SIZE, MPS_KEY_MAX_SIZE are as
+MPS_KEY_MEAN_SIZE, MPS_KEY_MAX_SIZE are as
 described above, and MPS_KEY_POOL_DEBUG_OPTIONS
 specifies the debugging options. See mps_debug_option_s.
                                                                                                      
 
                                                                                                      
@@ -152,12 +152,12 @@ 
                                                                                                      Navigation
                                                                                                      
 
                                                                                                      starting with version 1.112.
                                                                                                      
 
                                                                                                      When using mps_pool_create(), pass the debugging
 options, segment size, mean size, and maximum size like this:
                                                                                                      
-
                                                                                                      mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
-                          mps_class_t mps_class_mv_debug(),
+
                                                                                                      mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
+                          mps_class_t mps_class_mv_debug(),
                           mps_debug_option_s debug_option,
-                          mps_size_t extend_size,
-                          mps_size_t average_size,
-                          mps_size_t maximum_size)
+                          mps_size_t extend_size,
+                          mps_size_t average_size,
+                          mps_size_t maximum_size)
 
                                                                                                      
 
                                                                                                      
 
                                                                                                      
diff --git a/mps/manual/html/pool/mvff.html b/mps/manual/html/pool/mvff.html
index e246f136db1..96712c2727e 100644
--- a/mps/manual/html/pool/mvff.html
+++ b/mps/manual/html/pool/mvff.html
@@ -129,28 +129,28 @@ 
                                                                                                      Navigation
                                                                                                      
 
                                                                                                      When creating an MVFF pool, mps_pool_create_k() may take
 the following keyword arguments:
                                                                                                      
 
                                                                                                        
-
                                                                                                      • MPS_KEY_EXTEND_BY (type size_t, default
+
                                                                                                      • MPS_KEY_EXTEND_BY (type size_t, default
 65536) is the size of segment that the pool will request
 from the arena.
                                                                                                        • 
-
                                                                                                      • MPS_KEY_MEAN_SIZE (type size_t, default 32)
+
                                                                                                      • MPS_KEY_MEAN_SIZE (type size_t, default 32)
 is the predicted mean size of blocks that will be allocated from
 the pool. This is a hint to the MPS: the pool will be less
 efficient if this is wrong, but nothing will break.
                                                                                                        • 
-
                                                                                                      • MPS_KEY_ALIGN (type mps_align_t, default is
+
                                                                                                      • MPS_KEY_ALIGN (type mps_align_t, default is
 smallest general purpose alignment for the architecture) is the
 alignment of addresses for allocation (and freeing) in
 the pool. If an unaligned size is passed to mps_alloc() or
 mps_free(), it will be rounded up to the pool’s alignment.
 The minimum alignment supported by pools of this class is
 sizeof(void *).
                                                                                                        • 
-
                                                                                                      • MPS_KEY_MVFF_ARENA_HIGH (type mps_bool_t,
+
                                                                                                      • MPS_KEY_MVFF_ARENA_HIGH (type mps_bool_t,
 default false) determines whether new segments are acquired at high
 addresses (if true), or at low addresses (if false).
                                                                                                        • 
-
                                                                                                      • MPS_KEY_MVFF_SLOT_HIGH [1] (type mps_bool_t,
+
                                                                                                      • MPS_KEY_MVFF_SLOT_HIGH [1] (type mps_bool_t,
 default false) determines whether to search for the highest
 addressed free area (if true) or lowest (if false) when allocating
 using mps_alloc().
                                                                                                        • 
-
                                                                                                      • MPS_KEY_MVFF_FIRST_FIT [1] (type mps_bool_t, default
+
                                                                                                      • MPS_KEY_MVFF_FIRST_FIT [1] (type mps_bool_t, default
 true) determines whether to allocate from the highest address in a
 found free area (if true) or lowest (if false) when allocating
 using mps_alloc().
                                                                                                        • 
@@ -159,16 +159,16 @@ 
                                                                                                        Navigation
                                                                                                        
 
 
 [1](1, 2) Allocation points are not affected by
-MPS_KEY_MVFF_SLOT_HIGH or
-MPS_KEY_MVFF_FIRST_FIT.
+MPS_KEY_MVFF_SLOT_HIGH or
+MPS_KEY_MVFF_FIRST_FIT.
 They use a worst-fit policy in order to maximise the number of
 in-line allocations.
 
 
 
                                                                                                        The defaults yield a a simple first-fit allocator.  Specify
-MPS_KEY_MVFF_ARENA_HIGH and
-MPS_KEY_MVFF_SLOT_HIGH true, and
-MPS_KEY_MVFF_FIRST_FIT false to get a first-fit
+MPS_KEY_MVFF_ARENA_HIGH and
+MPS_KEY_MVFF_SLOT_HIGH true, and
+MPS_KEY_MVFF_FIRST_FIT false to get a first-fit
 allocator that works from the top of memory downwards.
 Other combinations may be useful in special circumstances.
                                                                                                        
 
                                                                                                        For example:
                                                                                                        
@@ -189,14 +189,14 @@ 
                                                                                                        Navigation
                                                                                                        
 
                                                                                                        starting with version 1.112.
                                                                                                        
 
                                                                                                        When using mps_pool_create(), pass the arguments like
 this:
                                                                                                        
-
                                                                                                        mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
-                          mps_class_t mps_class_mvff(),
-                          mps_size_t extend_size,
-                          mps_size_t average_size,
-                          mps_align_t alignment,
-                          mps_bool_t slot_high,
-                          mps_bool_t arena_high,
-                          mps_bool_t first_fit)
+
                                                                                                        mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
+                          mps_class_t mps_class_mvff(),
+                          mps_size_t extend_size,
+                          mps_size_t average_size,
+                          mps_align_t alignment,
+                          mps_bool_t slot_high,
+                          mps_bool_t arena_high,
+                          mps_bool_t first_fit)
 
                                                                                                        
 
                                                                                                        
 
                                                                                                        
@@ -210,27 +210,27 @@ 
                                                                                                        Navigation
                                                                                                        
 
                                                                                                        When creating a debugging MVFF pool, mps_pool_create_k()
 requires seven keyword arguments.
                                                                                                        
 
 
                                                                                                        
 
                                                                                                        Deprecated
                                                                                                        
 
                                                                                                        starting with version 1.112.
                                                                                                        
 
                                                                                                        When using mps_pool_create(), pass the debugging
 options, and other arguments like this:
                                                                                                        
-
                                                                                                        mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
-                          mps_class_t mps_class_mvff_debug(),
+
                                                                                                        mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
+                          mps_class_t mps_class_mvff_debug(),
                           mps_debug_option_s debug_option,
-                          mps_size_t extend_size,
-                          mps_size_t average_size,
-                          mps_align_t alignment,
-                          mps_bool_t slot_high,
-                          mps_bool_t arena_high,
-                          mps_bool_t first_fit)
+                          mps_size_t extend_size,
+                          mps_size_t average_size,
+                          mps_align_t alignment,
+                          mps_bool_t slot_high,
+                          mps_bool_t arena_high,
+                          mps_bool_t first_fit)
 
                                                                                                        
 
                                                                                                        
 
                                                                                                        
diff --git a/mps/manual/html/pool/mvt.html b/mps/manual/html/pool/mvt.html
index ad1f99a84d1..cf879386747 100644
--- a/mps/manual/html/pool/mvt.html
+++ b/mps/manual/html/pool/mvt.html
@@ -129,7 +129,7 @@ 
                                                                                                        Navigation
                                                                                                        
 smallest general purpose alignment for the architecture) is the
 predicted minimum size of blocks that will be allocated from the
 pool.
-
                                                                                                      • MPS_KEY_MEAN_SIZE (type size_t, default 32) is the
+
                                                                                                      • MPS_KEY_MEAN_SIZE (type size_t, default 32) is the
 predicted mean size of blocks that will be allocated from the
 pool.
                                                                                                        • 
 
                                                                                                      • MPS_KEY_MAX_SIZE (type size_t, default 8192) is the
@@ -201,13 +201,13 @@ 
                                                                                                        Navigation
                                                                                                        
 
                                                                                                        starting with version 1.112.
                                                                                                        
 
                                                                                                        When using mps_pool_create(), pass the arguments like
 this:
                                                                                                        
-
                                                                                                        mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
-                          mps_class_t mps_class_mvt(),
+
                                                                                                        mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
+                          mps_class_t mps_class_mvt(),
                           size_t minimum_size,
                           size_t mean_size,
                           size_t maximum_size,
-                          mps_count_t reserve_depth,
-                          mps_count_t fragmentation_limit)
+                          mps_count_t reserve_depth,
+                          mps_count_t fragmentation_limit)
 
                                                                                                        
 
                                                                                                        
 
                                                                                                        
diff --git a/mps/manual/html/pool/snc.html b/mps/manual/html/pool/snc.html
index b2212e5a00e..58bda41bf5c 100644
--- a/mps/manual/html/pool/snc.html
+++ b/mps/manual/html/pool/snc.html
@@ -133,9 +133,9 @@ 
                                                                                                        Navigation
                                                                                                        
 
                                                                                                        starting with version 1.112.
                                                                                                        
 
                                                                                                        When using mps_pool_create(), pass the format like
 this:
                                                                                                        
-
                                                                                                        mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
-                          mps_class_t mps_class_snc(),
-                          mps_fmt_t fmt)
+
                                                                                                        mps_res_t mps_pool_create(mps_pool_t *pool_o, mps_arena_t arena,
+                          mps_class_t mps_class_snc(),
+                          mps_fmt_t fmt)
 
                                                                                                        
 
                                                                                                        
 
                                                                                                        
@@ -158,8 +158,8 @@ 
                                                                                                        Navigation
                                                                                                        
 
                                                                                                        Deprecated
                                                                                                        
 
                                                                                                        starting with version 1.112.
                                                                                                        
 
                                                                                                        When using mps_ap_create(), pass the rank like this:
                                                                                                        
-
                                                                                                        mps_res_t mps_ap_create(mps_ap_t *ap_o, mps_pool_t pool,
-                        mps_rank_t rank)
+
                                                                                                        mps_res_t mps_ap_create(mps_ap_t *ap_o, mps_pool_t pool,
+                        mps_rank_t rank)
 
                                                                                                        
 
                                                                                                        
 
                                                                                                        
diff --git a/mps/manual/html/searchindex.js b/mps/manual/html/searchindex.js
index 28c96231df5..549c163f936 100644
--- a/mps/manual/html/searchindex.js
+++ b/mps/manual/html/searchindex.js
@@ -1 +1 @@
-Search.setIndex({objects:{"":{mps_ap_alloc_pattern_reset:[62,2,1,""],mps_arena_roots_walk:[99,2,1,""],ReservoirLimit:[50,2,1,""],MPS_SAC_CLASS_LIMIT:[16,3,1,""],SplayTreeFirst:[85,2,1,""],"-d":[17,0,1,"cmdoption-mpseventsql-d"],SplayTreeInit:[85,2,1,""],"-f":[17,0,1,"cmdoption-mpseventsql-f"],"-l":[17,0,1,"cmdoption-mpseventtxt-l"],"-o":[17,0,1,"cmdoption-mpseventsql-o"],"-i":[17,0,1,"cmdoption-mpseventsql-i"],mps_sac_create:[16,2,1,""],to:[55,3,1,""],mps_telemetry_flush:[17,2,1,""],"-v":[17,0,1,"cmdoption-mpseventsql-v"],"-p":[17,0,1,"cmdoption-mpseventsql-p"],"-r":[17,0,1,"cmdoption-mpseventsql-r"],RootVar:[53,4,1,""],CONFIG_VAR_RASH:[13,3,1,""],SplayNodeInit:[85,2,1,""],MPS_ARCH_I3:[106,3,1,""],mps_root_create_table:[99,2,1,""],MPS_SCAN_BEGIN:[42,2,1,""],mps_sac_t:[16,4,1,""],mps_pool_debug_option_s:[2,4,1,""],MPS_WORD_WIDTH:[106,3,1,""],mps_tramp:[113,2,1,""],mps_class_amc:[30,2,1,""],LockReleaseGlobalRecursive:[56,2,1,""],MessageClass:[25,4,1,""],SplayTreeSearch:[85,2,1,""],MPS_KEY_MEAN_SIZE:[55,3,1,""],SegPrefLOW:[55,3,1,""],mps_arena_create:[38,2,1,""],Rank:[53,4,1,""],mps_lib_get_stderr:[41,2,1,""],AMCScan:[28,2,1,""],Ring:[22,4,1,""],BTFindShortResRangeHigh:[23,2,1,""],mps_lib_get_stdout:[41,2,1,""],mps_message_type_disable:[0,2,1,""],mps_io_write:[41,2,1,""],Ref:[53,4,1,""],mps_arena_class_vm:[38,2,1,""],BTCopyInvertRange:[23,2,1,""],MPS_PF_XCI3LL:[106,3,1,""],mps_amc_apply_stepper_t:[30,4,1,""],mps_rank_weak:[99,2,1,""],mps_clock:[41,2,1,""],mps_ss_t:[42,4,1,""],mps_arena_unsafe_restore_protection:[38,2,1,""],mps_free:[102,2,1,""],Arena:[8,4,1,""],mps_message_type:[0,2,1,""],AMCBufferFill:[28,2,1,""],mps_clocks_per_sec:[41,2,1,""],CBSInit:[66,2,1,""],MPS_RES_OK:[13,3,1,""],SplayNodeStruct:[85,4,1,""],mps_arena_commit_limit:[38,2,1,""],Reservoir:[50,4,1,""],mps_lib_memcpy:[41,2,1,""],MPS_PF_STRING:[106,3,1,""],CBSBlockLimit:[66,2,1,""],Serial:[53,4,1,""],mps_addr_fmt:[46,2,1,""],mps_lib_telemetry_control:[41,2,1,""],mps_rank_t:[99,4,1,""],MPS_TELEMETRY_DATABASE:[17,1,1,"-"],SplayNodeRefresh:[85,2,1,""],"-h":[17,0,1,"cmdoption-mpseventcnv-h"],LockReleaseGlobal:[56,2,1,""],BTIsSetRange:[23,2,1,""],mps_telemetry_get:[17,2,1,""],Bool:[53,4,1,""],MPS_TELEMETRY_CONTROL:[17,1,1,"-"],mps_ld_merge:[105,2,1,""],"-t":[17,0,1,"cmdoption-mpseventsql-t"],ProtSet:[43,2,1,""],MessageStruct:[25,4,1,""],opposed:[55,3,1,""],Count:[53,4,1,""],BTSetRange:[23,2,1,""],SplayTreeCheck:[85,2,1,""],mps_class_mvff_debug:[111,2,1,""],mps_fmt_fwd_t:[46,4,1,""],MPS_ARGS_BEGIN:[37,2,1,""],mps_arena_step:[38,2,1,""],BTFindLongResRange:[23,2,1,""],MutatorFaultContext:[43,4,1,""],ProtCanStepInstruction:[43,2,1,""],mps_sac_class_s:[16,4,1,""],BTSet:[23,2,1,""],MessageFinish:[25,2,1,""],mps_arena_t:[38,4,1,""],mps_ld_reset:[105,2,1,""],LockFinish:[56,2,1,""],mps_root_create_fmt:[99,2,1,""],mps_class_ams:[36,2,1,""],mps_arena_committed:[38,2,1,""],MPS_ARCH_I6:[106,3,1,""],mps_arena_commit_limit_set:[38,2,1,""],MPS_RES_RESOURCE:[13,3,1,""],MPS_ARGS_END:[37,2,1,""],mps_frame_t:[51,4,1,""],mps_telemetry_intern:[17,2,1,""],mps_thread_dereg:[113,2,1,""],MessageInit:[25,2,1,""],TraceId:[53,4,1,""],Attr:[53,4,1,""],CBSBlockSize:[66,2,1,""],BTResRange:[23,2,1,""],mps_fmt_create_B:[46,2,1,""],MPS_BUILD_LL:[106,3,1,""],mps_fmt_class_t:[46,4,1,""],RING_FOR:[22,2,1,""],Pointer:[53,4,1,""],ProtocolClassSuperclassPoly:[45,2,1,""],MPS_OS_LI:[106,3,1,""],mps_telemetry_reset:[17,2,1,""],SplayTreeNeighbours:[85,2,1,""],MPS_KEY_ALIGN:[55,3,1,""],mps_lib_memset:[41,2,1,""],SplayTreeDelete:[85,2,1,""],mps_io_destroy:[41,2,1,""],ReservoirFinish:[50,2,1,""],LockInit:[56,2,1,""],mps_definalize:[108,2,1,""],MPS_FIX12:[42,2,1,""],MPS_RM_PROT:[99,3,1,""],mps_reserve:[102,2,1,""],mps_addr_t:[63,4,1,""],mps_class_lo:[12,2,1,""],SplayTreeFinish:[85,2,1,""],mps_rank_exact:[99,2,1,""],mps_key_t:[37,4,1,""],mps_ap_s:[102,4,1,""],mps_chain_create:[47,2,1,""],mps_ap_t:[102,4,1,""],IsSubclassPoly:[45,2,1,""],mps_reg_scan_t:[99,4,1,""],mps_root_create_reg:[99,2,1,""],AMCFix:[28,2,1,""],mps_arena_clamp:[38,2,1,""],mps_gen_param_s:[47,4,1,""],mps_arena_formatted_objects_walk:[46,2,1,""],VMDestroy:[15,2,1,""],MPS_T_WORD:[106,3,1,""],mps_fmt_create_auto_header:[46,2,1,""],mps_lib_FILE:[41,4,1,""],MPS_FIX2:[42,2,1,""],mps_fmt_put_fencepost_t:[61,2,1,""],ReservoirCheck:[50,2,1,""],mps_mvt_size:[93,2,1,""],mps_telemetry_label:[17,2,1,""],MPS_RES_MEMORY:[13,3,1,""],mps_root_create_table_masked:[99,2,1,""],mps_sac_free:[16,2,1,""],mps_stack_scan_ambig:[99,2,1,""],mps_ld_s:[105,4,1,""],mps_ld_t:[105,4,1,""],mps_sac_alloc:[16,2,1,""],mps_arena_create_k:[38,2,1,""],mps_arena_spare_commit_limit_set:[38,2,1,""],mps_arena_create_v:[38,2,1,""],mps_alloc_pattern_t:[62,4,1,""],Word:[53,4,1,""],mps_class_awl:[10,2,1,""],LockReleaseRecursive:[56,2,1,""],ReservoirEnsureFull:[50,2,1,""],mps_commit:[102,2,1,""],mps_message_t:[0,4,1,""],mps_alloc:[102,2,1,""],mps_arena_class_cl:[38,2,1,""],MPS_WORD_SHIFT:[106,3,1,""],mps_lib_fputc:[41,2,1,""],TractOfAddr:[8,2,1,""],BTCopyOffsetRange:[23,2,1,""],mps_pool_check_free_space:[2,2,1,""],mps_fmt_create_A:[46,2,1,""],mps_lib_fputs:[41,2,1,""],SplayNode:[85,4,1,""],Addr:[53,4,1,""],Index:[53,4,1,""],size:[55,3,1,""],mps_message_queue_type:[0,2,1,""],SegSplit:[24,2,1,""],MPS_PF_W3I6MV:[106,3,1,""],mps_roots_stepper_t:[99,4,1,""],mps_pool_create:[98,2,1,""],mps_message_get:[0,2,1,""],LockReleaseMPM:[56,2,1,""],CBSFindFirst:[66,2,1,""],AccessSet:[53,4,1,""],mps_pool_create_v:[98,2,1,""],mps_fmt_scan_t:[46,4,1,""],ClassOfPoly:[45,2,1,""],MPS_RES_IO:[13,3,1,""],mps_thread_reg:[113,2,1,""],LockClaimGlobal:[56,2,1,""],SegMergeMethod:[24,4,1,""],CBSIterate:[66,2,1,""],BTIsResRange:[23,2,1,""],Fun:[53,4,1,""],MPS_ARGS_ADD:[37,2,1,""],BTSize:[23,2,1,""],mps_pool_create_k:[98,2,1,""],MPS_SAC_ALLOC_FAST:[16,2,1,""],Seg:[24,4,1,""],mps_lib_assert_fail:[41,2,1,""],mps_message_type_gc:[47,2,1,""],MPS_RES_COMMIT_LIMIT:[13,3,1,""],MPS_OS_XC:[106,3,1,""],mps_ap_frame_push:[51,2,1,""],MPS_ARGS_DONE:[37,2,1,""],BTRes:[23,2,1,""],MPS_PF_W3I3MV:[106,3,1,""],SplayTestTreeMethod:[85,4,1,""],mps_root_destroy:[99,2,1,""],BTCopyRange:[23,2,1,""],MPS_KEY_EXTEND_BY:[55,3,1,""],mps_class_ams_debug:[36,2,1,""],MPS_BUILD_MV:[106,3,1,""],"(RingInsert)":[22,2,1,""],mps_mv_size:[91,2,1,""],CONFIG_VAR_HOT:[13,3,1,""],mps_tramp_t:[113,4,1,""],mps_ap_frame_pop:[51,2,1,""],mps_fmt_t:[46,4,1,""],mps_class_mfs:[103,2,1,""],DEFINE_CLASS:[45,2,1,""],RingInit:[22,2,1,""],MPS_PF_XCI6LL:[106,3,1,""],BTFindLongResRangeHigh:[23,2,1,""],mps_alloc_pattern_ramp:[62,2,1,""],mps_pool_t:[98,4,1,""],SplayTreeDescribe:[85,2,1,""],mps_message_gc_condemned_size:[47,2,1,""],MPS_RES_LIMIT:[13,3,1,""],mps_fmt_destroy:[46,2,1,""],mps_message_poll:[0,2,1,""],mps_fmt_fencepost_wrap:[61,2,1,""],ProtStepInstruction:[43,2,1,""],CBSBlockDescribe:[66,2,1,""],SplayRoot:[85,2,1,""],ACT_ON_RANGE:[23,2,1,""],mps_clock_t:[63,4,1,""],MPS_OS_W3:[106,3,1,""],Byte:[53,4,1,""],mps_ap_alloc_pattern_begin:[62,2,1,""],CBSFinish:[66,2,1,""],mps_fmt_pad_t:[46,4,1,""],SplayNodeFinish:[85,2,1,""],mps_fix:[42,2,1,""],ACT_ON_RANGE_HIGH:[23,2,1,""],mps_arena_start_collect:[38,2,1,""],mps_sac_destroy:[16,2,1,""],AMCFinish:[28,2,1,""],MPS_T_ULONGEST:[106,3,1,""],LockClaimGlobalRecursive:[56,2,1,""],mps_lib_get_EOF:[41,2,1,""],mps_mvff_size:[111,2,1,""],mps_chain_t:[47,4,1,""],mps_root_create:[99,2,1,""],ReservoirInit:[50,2,1,""],MPS_PF_XCI3GC:[106,3,1,""],mps_arena_has_addr:[38,2,1,""],CBSBlockBase:[66,2,1,""],mps_formatted_objects_stepper_t:[46,4,1,""],MPS_RES_UNIMPL:[13,3,1,""],Epoch:[53,4,1,""],TraceSet:[53,4,1,""],LockSize:[56,2,1,""],mps_sac_flush:[16,2,1,""],ReservoirAvailable:[50,2,1,""],mps_arena_reserved:[38,2,1,""],MPS_RES_PARAM:[13,3,1,""],mps_fmt_auto_header_s:[46,4,1,""],ReservoirSetLimit:[50,2,1,""],mps_ld_add:[105,2,1,""],Accumulation:[53,4,1,""],mps_ap_destroy:[102,2,1,""],SplayNodeDescribeMethod:[85,4,1,""],SplayCompareMethod:[85,4,1,""],mps_class_mv:[91,2,1,""],CHECKD:[9,2,1,""],CONFIG_PLINTH_NONE:[41,3,1,""],mps_pool_destroy:[98,2,1,""],AMCReclaim:[28,2,1,""],mps_fmt_isfwd_t:[46,4,1,""],CHECKU:[9,2,1,""],CHECKS:[9,2,1,""],mps_arena_destroy:[38,2,1,""],SplayTreeInsert:[85,2,1,""],MPS_BUILD_GC:[106,3,1,""],mps_class_mv_debug:[91,2,1,""],mps_arena_spare_committed:[38,2,1,""],SUPERCLASS:[45,2,1,""],RefSet:[53,4,1,""],mps_message_type_enable:[0,2,1,""],MPS_TELEMETRY_FILENAME:[17,1,1,"-"],RING_ELT:[22,2,1,""],mps_pool_check_fenceposts:[2,2,1,""],MPS_RM_CONST:[99,3,1,""],mps_arena_extend:[38,2,1,""],mps_collections:[38,2,1,""],mps_message_gc_live_size:[47,2,1,""],Align:[53,4,1,""],mps_fmt_A_s:[46,4,1,""],CHECKL:[9,2,1,""],mps_objects_step_t:[61,2,1,""],MPS_RES_FAIL:[13,3,1,""],mps_arena_spare_commit_limit:[38,2,1,""],SplayTreeStruct:[85,4,1,""],mps_ap_create_v:[102,2,1,""],mps_align_t:[63,4,1,""],mps_arena_expose:[38,2,1,""],AMCBufferEmpty:[28,2,1,""],mps_ap_alloc_pattern_end:[62,2,1,""],mps_ap_create_k:[102,2,1,""],ProtocolClass:[45,4,1,""],CBSFindLast:[66,2,1,""],Size:[53,4,1,""],BTCreate:[23,2,1,""],MessageEmpty:[25,2,1,""],mps_message_type_finalization:[108,2,1,""],LockClaimRecursive:[56,2,1,""],mps_thr_t:[113,4,1,""],ULongest:[53,4,1,""],SplayFindFirst:[85,2,1,""],mps_word_t:[63,4,1,""],SplayUpdateNodeMethod:[85,4,1,""],MPS_FIX_CALL:[42,2,1,""],mps_arena_class_t:[38,4,1,""],mps_res_t:[13,4,1,""],mps_bool_t:[63,4,1,""],mps_fmt_adjust_fencepost_t:[61,2,1,""],mps_ld_isstale:[105,2,1,""],mps_addr_pool:[98,2,1,""],mps_fmt_skip_t:[46,4,1,""],mps_io_t:[41,4,1,""],RingAppend:[22,2,1,""],mps_ap_trip:[102,2,1,""],SegSplitMethod:[24,4,1,""],MPS_ARGS_ADD_FIELD:[37,2,1,""],mps_lib_memcmp:[41,2,1,""],MPS_PF_FRI3GC:[106,3,1,""],mps_rank_ambig:[99,2,1,""],RingFinish:[22,2,1,""],MPS_OS_FR:[106,3,1,""],CBSDelete:[66,2,1,""],SegMerge:[24,2,1,""],BT:[23,4,1,""],MPS_RESERVE_BLOCK:[102,2,1,""],LockClaim:[56,2,1,""],MPS_KEY_MVFF_SLOT_HIGH:[55,3,1,""],mps_message_type_gc_start:[47,2,1,""],mps_ap_create:[102,2,1,""],mps_telemetry_control:[17,2,1,""],DEFINE_ALIAS_CLASS:[45,2,1,""],SplayTree:[85,4,1,""],BTFindResRangeHigh:[23,2,1,""],MPS_KEY_MVFF_ARENA_HIGH:[55,3,1,""],SplayTestNodeMethod:[85,4,1,""],CBSInsert:[66,2,1,""],SplayNodeCheck:[85,2,1,""],GCSeg:[24,4,1,""],MPS_PF_LII6GC:[106,3,1,""],mps_awl_find_dependent_t:[10,4,1,""],MPS_SCAN_END:[42,2,1,""],MPS_SAC_FREE_FAST:[16,2,1,""],MPS_PF_LII3GC:[106,3,1,""],INHERIT_CLASS:[45,2,1,""],ProtSetup:[43,2,1,""],ProtSync:[43,2,1,""],VMCreate:[15,2,1,""],frees:[55,3,1,""],mps_class_amcz:[4,2,1,""],mps_message_finalization_ref:[108,2,1,""],CBSSetMinSize:[66,2,1,""],mps_args_none:[37,3,1,""],ArenaFinalize:[100,2,1,""],mps_arena_park:[38,2,1,""],mps_mvff_free_size:[111,2,1,""],mps_message_discard:[0,2,1,""],ProtTramp:[43,2,1,""],mps_message_type_t:[0,4,1,""],mps_alloc_pattern_ramp_collect_all:[62,2,1,""],mps_root_scan_t:[99,4,1,""],mps_pool_walk:[61,2,1,""],mps_root_t:[99,4,1,""],MPS_FIX1:[42,2,1,""],mps_ap_fill:[102,2,1,""],mps_arena_unsafe_expose_remember_protection:[38,2,1,""],Message:[25,4,1,""],mps_message_gc_not_condemned_size:[47,2,1,""],mps_mvt_free_size:[93,2,1,""],mps_arena_walk:[61,2,1,""],MPS_PF_ALIGN:[106,3,1,""],mps_message_clock:[0,2,1,""],BTFindResRange:[23,2,1,""],mps_class_mvff:[111,2,1,""],mps_label_t:[63,4,1,""],MPS_PF_FRI6GC:[106,3,1,""],BTDestroy:[23,2,1,""],mps_class_snc:[96,2,1,""],mps_message_gc_start_why:[47,2,1,""],start:[55,3,1,""],BTFindShortResRange:[23,2,1,""],CBSIterateLarge:[66,2,1,""],ReservoirWithdraw:[50,2,1,""],mps_amc_apply:[30,2,1,""],mps_debug_class:[61,2,1,""],Res:[53,4,1,""],mps_arena_release:[38,2,1,""],highest:[55,3,1,""],CBSDescribe:[66,2,1,""],Compare:[53,4,1,""],mps_mv_free_size:[91,2,1,""],ReservoirDeposit:[50,2,1,""],mps_io_create:[41,2,1,""],"(RingRemove)":[22,2,1,""],MessagePost:[25,2,1,""],mps_class_t:[98,4,1,""],as:[55,3,1,""],BTGet:[23,2,1,""],mps_fmt_B_s:[46,4,1,""],mps_arena_collect:[38,2,1,""],mps_fmt_check_fenceposts_t:[61,2,1,""],CBSFindLargest:[66,2,1,""],WriteF:[101,2,1,""],mps_finalize:[108,2,1,""],Shift:[53,4,1,""],mps_chain_destroy:[47,2,1,""],CONFIG_VAR_COOL:[13,3,1,""],SplayTreeNext:[85,2,1,""],mps_arg_s:[37,4,1,""],mps_telemetry_set:[17,2,1,""],mps_rm_t:[99,4,1,""],mps_class_mvt:[93,2,1,""],MPS_KEY_MVFF_FIRST_FIT:[55,3,1,""],mps_io_flush:[41,2,1,""]}},terms:{scriptwork:[55,67],circuitri:78,ru_utim:41,orthogon:[40,49],mps_arena_roots_walk:[99,38],messagefinalizationrefmethod:25,btset:23,four:[39,28,74,23,86,99,83,65,9,88,89,66,91],secondli:[8,78,64,33,20],prefix:[74,8,63,6,64,67],nurseri:[69,73,77,79,62,90,47],oldest:[28,90],effienc:61,payoff:[28,58],whose:[0,70,81,82,84,65,22,2,25,17,54,93,30,92,34,37,98,99,10,16,64,46,105,47,63,11,87,20,108,42,45,51,112,113,48,49],accur:[39,71,90,19,79,86,97,66],"const":[47,41,25,52,17,37],find_depend:10,splayupdatenodemethod:85,albuquerqu:40,freeblocktesttre:85,illustr:[86,38,33,48],mps_telemetry_flush:[41,17,38],concret:[75,60,8,58,61,25,53,67],buddi:[70,72,74,40,39,107,81,31,83,87],under:[1,72,73,23,63,84,85,90,5,102,7,57,97,38,13,61,45,19,108,66,67,49],messagecollectionstatslivesizemethod:25,sped:[0,20],spec:53,merchant:[7,97],digit:[40,106,78,3,89,6],everi:[0,50,70,76,77,78,81,85,86,51,88,52,17,54,28,95,9,33,34,11,38,39,99,59,40,13,61,53,46,21,66,45,48],risk:[28,58,66],mps_final:[70,108,100,34],pageretstruct:28,macraki:[112,74],"void":[0,50,23,70,76,63,85,86,22,4,2,25,52,91,45,55,28,56,93,8,64,95,96,34,36,37,38,98,39,99,12,40,41,101,10,43,61,15,16,17,46,103,105,47,53,106,48,102,108,62,66,111,113,30,67,88],rise:87,thvv:95,risc:79,implicit:[73,45,86,51,87],quantiz:90,addrstruct:53,govern:25,jacob:40,affect:[47,23,96,57,86,14,108,83,61,65,21,87,67,111,25,73,64,38],mps_pool_check_fencepost:[61,2],poorli:[39,32,16,81],deleterang:66,vast:107,agesen:40,extend_s:[111,91,103],kilobyt:[80,78,47,48,74],ben:40,ferreira:40,factori:88,vector:[99,79,74,23,84,34,61,75,87,42,48],terabyt:[86,74],cmu:40,parenthes:63,initialis:[28,59,56,95,110,85,66,25,11],cmp:[105,34],x86_64:6,lockw3:13,deutsch:[72,40,20],mps_lib_get_stdout:[41,64],naiv:[28,45],direct:[69,28,72,73,7,23,41,14,71,81,65,97,45,11,102,67],histor:[69,70,72,73,74,75,76,78,81,83,84,86,87,88,89,6,28,56,58,100,106,20,68],nail:[28,77,24,58,90,35],consequ:[12,13,67,10,96,4,34,36,113,38],second:[102,28,60,57,41,78,106,64,85,81,48,32,22,33,34,87,17,11,45,38,49],reorder:102,aggreg:[84,75],type_fwd:48,freeblocklimitofsplaynod:85,p_v:[102,16],ap_o:[96,102,10],thisclass:45,mps_key_vmw3_top_down:[37,38],even:[0,50,72,73,23,81,82,83,69,86,87,88,90,64,54,28,75,7,93,32,33,34,35,11,38,39,66,61,62,16,17,46,97,65,20,102,108,21,42,113,48,67],gcsegstruct:24,disk:[39,74,40,78,79,82,84,87,88,90],hide:[61,84],make_symbol:[102,34],arena_poll_max:8,neg:[98,105,23,41,64,46,38],asid:16,weren:73,btcopyoffsetrang:23,children:[69,77,85,86],cheng:40,supplier:39,"new":[0,1,73,74,23,70,77,78,79,81,69,83,85,86,22,88,90,25,26,6,17,54,27,28,56,8,64,32,66,10,38,98,39,99,40,13,34,61,63,111,45,46,97,105,47,19,87,106,107,20,102,108,42,51,48,49],mps_ss_t:[99,10,42,46,94,87,33,34,48],upward:[111,23],ever:[39,99,106,8,14,86,33,17,113],topolog:85,told:[54,81],protocolensuresomeclass:45,elimin:[39,73,78,107,20,83,85,87,88,33,102],subtre:85,avert:[45,95],mps_arena_class_cl:[37,48,38],mem:[53,66],ring_elt:22,splinter:[61,8],here:[0,23,79,85,25,6,102,54,28,29,57,8,58,33,34,11,38,99,13,61,15,17,105,47,108,21,42,48,67,49],block_requiring_fin:108,met:[83,24,7,97],mpscmv:91,undef:[63,20],studio:[6,67,106],subword:23,debugg:[99,17,21,64,38],path:[102,73,81,82,83,87,88,90,64,27,28,33,11,60,13,61,53,17,21,42,45,48,67,68],mps_message_type_dis:[0,25],abstractli:[25,11],interpret:[0,98,99,105,73,2,57,42,64,104,20,86,108,21,51,97,34,25,17,48,38],michal:40,bevan:112,firstfit:55,precis:[69,39,28,74,40,24,66,71,65,85,9,87,90,46,78],findshortresrangehigh:23,bitmask:[99,17,74],drj:[28,23,8,97,25,53,11],scaveng:[69,87,86,73,40],permit:[0,1,73,75,78,84,85,86,90,25,45,28,7,93,8,97,24,38,39,61,64,107,102,66,67],vmstruct:15,krishnan:40,aka:[8,58,23,106],prolog:[69,73,14,20],mps_lib_telemetry_control:41,basereturn:[50,28,85,23,66],joshua:40,frombas:23,norsk:40,keysig:52,mps_key_chain:[30,2,4,34,36,37,48],tempt:[105,63,42],skippabl:48,brought:58,mps_releas:29,unix:[69,74,76,13,78,43,95,87,88,41,53,113,6,67],mps_sac_free_fast:16,brk:[87,74,75],amherst:40,strai:61,printf:[0,3,101,34],newspac:[77,86],total:[39,28,47,55,57,8,78,85,93,32,21,87,97,44,34,73,53,91,111,48,38],cbsfindlast:66,mps_fmt_create_b:46,unit:[54,28,48,73,74,89,76,41,8,46,72,88,33,90,53,24,78,103],highli:[1,39,28,20,33,48],bookkeep:[39,32,14,78,20],describ:[69,70,73,74,75,76,24,81,85,86,51,88,90,25,5,6,91,17,54,55,28,29,8,64,32,66,33,34,36,78,39,99,59,41,101,10,14,104,16,44,111,45,46,97,47,63,53,107,20,102,42,87,48,67,49],would:[102,70,71,73,74,23,77,24,79,83,85,22,4,17,54,28,7,93,8,32,33,34,11,38,39,99,59,13,10,14,61,16,44,45,46,103,105,53,41,107,20,108,100,66,48,88],tail:[61,40,20],unpredict:39,vol:40,edward:[78,40,20],call:[0,50,72,73,74,23,70,76,24,2,80,81,69,83,85,86,22,88,90,25,6,45,54,66,28,75,56,93,8,94,95,96,32,9,33,10,100,36,11,78,38,98,39,99,59,12,87,13,34,14,43,61,15,16,111,17,46,1,97,105,47,19,63,53,37,41,107,65,20,48,102,108,21,62,42,110,51,113,30,67],card:[73,40,90],"0x1003fb148":21,recommend:[41,14,63,48,16,33,42,113,46,49],indiana:40,collectionstatscondemneds:25,promptli:[0,70,14,32,88,102],type:[0,50,71,72,73,74,23,70,76,78,79,80,81,83,84,85,86,22,4,90,25,91,45,54,27,28,95,75,106,93,8,64,58,96,32,9,33,10,36,11,38,98,39,99,111,113,12,40,87,13,101,34,14,43,61,62,16,66,17,46,103,97,105,47,63,88,53,37,41,65,20,48,102,108,21,42,110,51,2,30,67,68],until:[0,50,73,75,70,76,77,81,85,86,87,90,28,56,8,95,32,34,38,98,39,99,12,97,100,62,16,102,46,105,47,19,108,42,48],swap:[74,76,78,82,84,15,87,88,90,38],mps_arch_m2:106,mps_arch_m4:106,musn:67,mps_arch_m6:106,relax:34,notif:[25,100,66],notic:[40,7,23,97,63,22,90,25,11],toolkit:40,warn:[1,113,58,16,42,53,11,102,67],exce:[39,47,23,93,8,17],mps_pf_string:[106,67,29],phd:40,wari:8,excl:102,hold:[0,70,71,74,23,78,81,22,88,6,64,28,56,8,34,38,98,99,16,53,46,104,47,87,102,108,51,113,49],overrun:61,must:[0,50,72,73,23,70,76,77,24,2,81,69,84,85,86,22,4,90,25,6,91,45,54,55,28,75,7,56,93,8,64,94,95,96,32,9,33,10,35,36,37,78,38,98,39,99,59,12,41,34,14,111,61,15,16,66,17,46,1,103,97,105,47,19,63,88,53,87,107,65,48,102,108,21,100,42,110,51,113,30,67,49],shoot:39,btfindshortresrangehigh:23,springer:40,isvalid:59,join:[22,109,3,63],room:[61,28,47,84],err:8,henri:[86,40],generalis:101,setup:[28,43],work:[1,69,73,23,78,79,81,83,85,86,22,88,6,53,54,28,57,8,64,32,33,10,36,11,38,39,99,59,40,100,97,14,15,16,111,17,47,19,107,20,102,108,66,87,112,48,67,49],btsetrang:23,pierc:40,doubleword:[72,79,89],mccaughan:112,conceptu:15,culprit:13,arenafinish:8,customis:[67,40],poolfinish:[55,97],hansen:[112,40],root:[1,69,71,73,74,75,78,83,85,86,87,88,90,6,91,45,54,27,93,8,94,58,32,66,33,34,36,11,38,99,59,12,40,10,100,44,30,53,103,104,65,20,102,108,42,111,68,113,48,49],cbsst:66,pierr:40,overrid:[45,33],defer:[72,73,75,40,32,62,88,66,102,92],august:40,obj_fmt_:[46,48],give:[0,1,73,77,24,63,83,85,87,52,64,28,106,57,9,33,38,39,41,14,61,17,105,47,93,110,49],mps_ld_reset:[105,34],dahl:[40,20],jelica:40,indic:[0,70,72,75,76,24,63,85,86,3,88,25,53,54,28,56,8,64,32,66,41,35,38,99,13,34,100,62,45,46,97,105,87,106,17,42,51,48,67,49],sick:40,clariti:[13,53,99],segmergemethod:24,attrbuf:53,caution:[99,10,108,34,26,102,46,68],fibonacci:[70,107,74],want:[50,1,23,24,69,85,88,90,25,6,53,54,8,64,41,37,38,39,99,13,34,61,15,16,30,17,46,21,48],noprint:21,tracesetempti:[8,24],mps_key_mvt_reserve_depth:[93,37],david:[112,40,97],unsign:[0,75,24,63,85,17,64,23,106,8,9,34,37,99,41,10,16,53,105,66,48,67],tediou:39,motion:[65,73,40,38,90],vanish:21,end:[102,70,71,23,76,81,3,88,25,45,55,28,8,33,34,37,38,99,13,62,63,64,46,108,21,66,110,87,48,49],"0x000000010000206b":21,quot:[70,78,63,83,87,48],icfp:40,ordinari:[28,73,78,88,10,46],findfirst:66,classifi:[70,90],revisit:40,how:[0,1,72,73,74,23,70,24,85,86,3,88,25,54,28,7,8,95,32,33,34,78,38,98,39,99,59,40,60,10,14,61,15,16,17,46,97,47,107,21,42,22,48,67,49],hot:[73,13,82,84,17,88,33,6,64,67],arenafre:[50,8],confin:[53,14],env:[64,21,101],"000ae0397333bc6d":17,answer:[39,73,48,23,49],symposium:40,ancestor:20,config:[28,53,67,29],updat:[69,70,72,73,74,24,81,85,87,88,25,17,54,32,33,41,34,78,38,98,39,59,40,13,66,43,63,53,46,97,65,42,48,67],costli:[69,78,79],lam:40,simmon:112,recogn:[13,102,105,10],lai:48,after:[0,70,72,73,74,24,2,85,88,90,25,6,45,54,28,29,57,8,94,95,96,32,33,34,37,78,38,39,99,59,13,66,43,61,62,16,17,46,105,11,41,56,107,65,20,102,108,21,42,113,48,67,49],lovemor:112,"0x0000000100011ded":21,diagram:[102,32,73,85],befor:[102,70,74,23,24,63,85,22,2,25,17,55,28,56,8,64,95,32,33,10,37,78,38,39,99,59,13,34,61,111,45,105,107,20,48,108,42,87,30,49],wrong:[39,104,47,93,13,14,95,21,22,33,111,59,53,91,48],mps_sac_fre:16,mps_tramp:113,freeblockbaseofsplaynod:85,rebal:85,arch:[54,64,59,67,29],parallel:[69,39,73,40,81,86,87,90,46],averag:[55,53,79],poolmvff:[85,66],amcaccess:[],type_port:34,attempt:[50,72,73,75,78,85,87,88,90,23,93,33,97,11,38,39,59,100,14,61,102,46,107,20,66,22,48],third:[40,60,57,106,64,32,22,33,34,53,11,48,67],opaqu:[72,56,76,63,86,105],bootstrap:22,segsplit:24,cbsiter:66,perform:[0,69,72,73,23,70,24,81,85,86,22,88,90,6,64,54,27,28,56,57,58,32,9,33,10,11,78,38,39,99,59,12,40,55,66,14,104,61,45,46,97,105,47,107,20,102,93,108,21,42,87,48,67,49],type_:[48,10],maintain:[50,72,73,75,78,79,83,85,86,87,88,45,54,56,8,33,11,24,38,99,16,64,103,104,66,112,48,67],environ:[74,75,76,85,17,88,90,6,102,56,34,39,59,40,41,101,64,20,21,113,48,67,68],migh:61,reloc:[54,73,74,87,88,46],finalis:[97,56],exclus:[59,56,86,48,15,113,46,49],mps_telemetry_reset:17,gen_param:47,lambda:[108,21,34],order:[69,70,72,73,74,75,77,78,79,81,82,83,85,86,22,88,6,53,55,28,56,8,64,32,9,33,34,35,37,39,59,40,10,100,43,111,16,66,17,11,87,107,20,102,108,21,42,51,113,48,67],finaliz:[83,35,108,88,34,25],decl:67,origin:[70,23,24,108,20,46,83,85,87,58,33,34,112,11,8,88],mpstd:[53,106,67,29],composit:[84,87,73,20],feedback:[28,109,58],afip:40,diagnos:17,mps_io_:41,over:[72,73,23,24,2,85,22,90,53,54,55,28,75,93,8,9,33,34,78,38,99,59,41,14,61,62,64,46,105,47,100,66,87,48,67],config_var_cool:[13,21],message_type_o:0,becaus:[50,1,71,72,73,74,23,70,76,77,24,79,81,69,83,84,85,86,3,88,90,52,45,54,51,28,75,56,8,64,94,32,9,33,10,11,78,38,39,99,59,87,13,34,14,111,61,15,16,44,66,17,82,97,105,63,2,53,37,41,107,20,102,108,21,100,42,110,22,48,67,101],fifo:[70,79,75,111],poolcreat:[59,97],reservoirlimit:50,dijkstra:[78,86,73,40],vmdestroi:15,app_for:22,ulongest:[53,101,67],flexibl:[1,54,99,72,76,24,107,83,22,16,64,38],vari:[39,73,70,57,93,85,87,33,11,67],btcopyrang:23,digest:90,sigplan:40,hashf:34,shieldmod:101,fit:[69,70,71,72,2,74,23,77,24,79,81,83,87,88,90,26,91,102,54,27,28,75,7,57,58,31,97,78,39,40,55,15,53,107,93,62,66,111,67,49],obj_pool:[46,48],fwrite:41,fix:[0,50,72,73,75,70,79,81,87,88,90,26,64,54,27,28,8,58,66,33,10,35,11,39,99,60,13,34,14,61,17,46,1,103,97,19,102,94,21,42,110,68,48,67,49],christoph:40,arenaent:[8,59],patchi:88,better:[98,70,99,105,12,23,53,107,42,14,48,102,85,88,33,10,6,82,46,38,49],tramp:43,thingi:[],fig:[85,22,67],zag:85,comprehens:73,traceinit:11,hidden:[99,100,20],erlang:14,taiichi:40,easier:[54,39,59,14,107,101],define_pool_class:45,descend:[85,20],them:[0,1,72,73,74,23,88,77,24,79,81,69,83,85,87,4,25,52,45,54,28,75,57,8,64,94,95,32,66,33,10,36,78,38,39,99,12,34,14,61,15,16,17,46,97,47,63,107,20,48,93,108,21,42,111,113,30,67,49],poolclass:[45,59,97,110,53,17],nygaard:20,thei:[0,1,95,72,73,74,23,70,88,24,79,81,69,83,84,85,86,3,4,90,25,52,53,54,66,28,75,56,93,8,64,58,92,32,9,33,34,35,36,11,78,38,39,99,12,40,41,101,10,14,61,15,16,44,111,45,46,97,105,47,63,2,87,107,65,20,48,102,94,100,42,110,22,113,30,49],fragment:[70,71,73,74,75,77,78,79,81,82,87,88,90,28,93,32,38,40,14,61,15,16,103,107,66,111,49],thee:17,safe:[0,70,75,24,63,85,86,22,102,28,56,93,58,96,37,38,39,99,59,40,53,1,105,11,20,87,113,48],poolfix:[110,33],debugmixin:61,"break":[102,74,23,106,93,100,64,20,48,61,21,87,88,42,111,6,91,11,45,38],band:[70,74,76,81,82,86,11],inescap:61,promis:[73,48],housekeep:85,closer:107,interrupt:[39,32,7,97],itanium:106,eventwdstruct:64,epdr:[55,45],choic:[72,47,75,23,84,24,107,20,61,87,48,78],tendenc:[77,30],"0x000000010001f2d2":21,mps_messag:[],codewarrior:[6,67,106],string_hash:34,firsttract:24,queuer:95,xcppgc:106,accommod:[69,16,46],loss:[64,97,23,7,42],dest_ld:105,"000ae039733592f9":17,arrow:69,each:[0,50,71,72,73,74,23,70,76,77,24,79,81,69,83,84,85,86,87,88,90,6,45,54,66,28,75,106,57,8,64,32,9,33,10,37,78,38,39,99,59,13,101,34,14,43,61,15,16,17,46,103,97,105,47,19,63,2,53,107,48,102,93,94,21,42,113,30,67,49],debug:[0,72,75,85,86,17,95,2,6,91,45,27,56,30,64,58,41,36,38,13,34,14,61,16,53,46,104,102,21,66,111,48,67,68],went:[13,53],european:40,oblig:48,side:[102,61,24,85,63],mean:[69,70,74,23,76,78,79,81,82,83,84,85,86,22,88,90,25,52,91,45,54,28,75,7,93,30,64,9,33,10,35,38,39,99,59,12,13,34,61,15,63,111,17,46,97,105,19,53,87,20,102,108,21,42,51,113,48,67,49],data_scan:42,laboratori:40,poolepvm:23,btfindshortresrang:23,overflow:39,bufferfil:[61,59],oppos:[39,72,73,55,81,53],rootcreatet:59,mps_res_limit:[13,16],cbsbl:66,forgot:21,collector:[1,69,71,72,73,74,75,70,76,77,78,79,81,83,65,86,87,88,90,6,102,54,28,57,30,31,96,32,33,34,38,98,39,99,40,13,14,17,46,47,20,108,21,48],poolamc:[28,21],unbound:[0,88],network:[39,72,41,14,20,108,38],freetreeinsert:85,goe:[39,28,40,99,61,87,6,38],newli:[28,59,73,85,22,47,102],crucial:[32,34],digraph:71,content:[0,1,28,72,47,74,84,30,20,48,102,61,21,88,97,25,52,64,46,38],rewrit:102,laid:[70,21],daniel:[112,40],adapt:[1,40,85,109,52,112],reader:[85,42],mps_arena_create_v:38,protocolclass:45,forth:87,kiem:40,mccarthi:[69,17,78,40,20],cbsblockstruct:66,arizona:40,traceunflip:11,linear:[55,23,40,79,87,33],barrier:[72,74,88,79,81,83,84,86,87,4,90,91,102,54,93,8,58,96,10,36,11,38,99,12,40,100,44,30,53,46,103,19,20,21,111,113,48,49],worthwhil:39,mps_class_awl:[34,37,10],situat:[50,28,105,59,19,76,8,66,81,32,21,10,46,38],free:[50,1,71,72,73,74,23,70,76,77,78,79,81,69,83,85,86,87,88,90,25,52,6,91,54,55,75,93,8,32,10,38,39,99,13,97,14,61,15,16,102,82,103,2,107,65,20,108,66,111,48,49],ineffici:[93,107,79,14,32,87,88,90],mps_commit:[102,21,48,34],ian:40,cytron:40,hand:[27,28,75,23,39,13,63,48,88,33,10,53,46,68],anal:[64,59],foocreat:64,mvt:[27,93,66,26,102,49],atc:[86,75],puzzl:34,reservoirfinish:50,epvm:23,ringinsert:22,assert_mpm:67,filter:[41,17,86,33],rampoutsid:28,ish:61,iso:[73,74,40,29,41,20,63],createv:59,"__int_64":[63,106],bufferstruct:97,"0x0000000000000000":21,subtl:[70,88,33],onto:[50,39,28,19,75,24,97,61,51,2,87],cbstest:[23,66],"0x0000000000000004":21,"0x0000000000000005":21,synergi:61,rang:[50,93,74,23,76,78,66,64,83,61,65,15,87,88,90,53,48],tracestart:11,kim:40,render:101,p_o:[102,21,16],hoop:97,independ:[54,72,59,12,40,81,15,67,64,38],wast:[28,59,23,57,107,14,81,16,90,103],rank:[71,75,88,24,83,87,4,26,27,28,96,33,34,37,99,12,10,100,101,44,53,11,94,21,42,49,48,68],xci3ll:[6,106],restrict:[102,55,74,41,10,81,61,108,66,51,67,90,87,6,11,46,38],hook:[8,99],instruct:[102,2,74,40,78,79,14,43,20,109,65,86,87,81,33,10,53,48],alreadi:[0,70,28,72,59,56,8,66,85,48,110,32,22,33,34,25,73,17,113,45],wrapper:[83,41,66,61,34],wasn:[13,28,16,33],splaytreedelet:85,agre:[0,20],flagella:[40,20],primari:[85,78,67,90],brock:40,"00000001003fc000":17,provabl:[72,79,48],mps_message_gc_live_s:47,nomin:[7,97],attach:[0,55,28,59,74,8,48,61,86,16,44,25,102,24,78,88],top:[1,39,28,47,23,8,66,58,83,85,21,87,34,111,64,11,30],epdrpoolclass:45,sometim:[0,70,72,73,74,23,76,81,69,65,86,87,88,90,6,75,32,10,39,61,15,19,20,108],stack:[1,71,72,73,75,81,82,85,86,51,88,90,26,27,28,93,30,96,32,33,10,36,37,39,99,12,40,14,62,111,102,103,20,108,21,87,113,48,67],timothi:40,cumul:19,too:[1,78,83,86,54,28,57,32,34,38,98,39,10,61,15,16,53,47,20,21,66,48,67],kanefski:40,epdralloc:45,mps_message_get:[0,47,78,108,34,25],upshot:105,john:[69,40,78,20,17,112],bttest:23,hewitt:[71,40],mps_build_cc:106,mps_fill_fencepost:61,"0x5195bace":3,tool:[64,39,40,29,41,78,60,14,20,58,95,6,106,17,67,88],tractofaddr:[8,11],mutati:85,took:[102,105],"10g":21,mps_sac_class_:[87,16],incur:[71,4],somewhat:[34,87,33,90],conserv:[69,39,28,73,74,40,70,78,10,14,85,20,32,75,87,81,90,35,53,71],happili:[28,100],simula:[40,20],config_var_rash:[13,88],mps_clock_t:[0,41,63],technic:[1,54,104,40,111,46,49],symptom:16,poolclassamc:59,modula3:20,nmk:6,r4000:106,silli:23,target:[1,39,104,23,60,53,41,42,9,33,90,6,106,48,67],keyword:[73,80,63,87,4,2,52,91,102,27,93,30,60,96,10,36,37,38,98,12,55,64,103,111,48,68],cxref:106,provid:[50,1,73,23,70,76,24,79,85,86,22,4,90,25,52,6,45,54,66,28,75,7,56,30,64,95,96,32,9,33,10,36,78,38,39,99,12,13,101,34,14,43,61,15,16,44,17,46,97,105,88,41,107,20,48,102,108,109,42,87,2,8,49],splaytreeinsert:85,lvalu:[102,16],tree:[27,75,70,8,81,82,61,85,87,58,66,6],mps_os_w3:[67,106],withington:[79,40,112],project:[1,104,40,20,109,6,48,67],matter:[24,105,32,40,74],"char":[102,105,47,74,53,41,42,64,21,101,34,25,52,17,37,48],mpmtype:[53,101,23],design:[1,69,2,23,70,24,79,85,3,95,52,25,5,53,54,27,28,75,29,8,60,64,58,32,9,33,34,35,11,78,38,39,59,40,55,41,10,14,43,61,15,101,66,45,97,56,20,102,108,109,100,42,110,22,113,48,67,49],prone:[39,52],searchlimit:23,provis:[97,66],messageinit:[25,95],uniniti:[102,24,48,95],entail:[32,15,73,46,33],mps_ap_frame_push:[96,51,75],configura:[100,67],ran:[53,16],mps_count_t:93,modern:[39,75,78,14,20,82,84,32,33,90,48,67],mind:[57,87,32,14],mine:40,bitfield:53,raw:[8,65,88],rat:67,lookup_in_fram:[17,21],manner:[61,28,101,7,97],increment:[1,70,73,74,78,79,81,83,69,86,87,88,90,53,54,28,8,32,10,11,38,39,40,13,97,64,20,102,113,48,49],infring:[7,97],seen:[39,19,56,66,61,87,90,64,67],seem:[39,28,59,85,61,32,53,48],splaynodeinit:85,strength:[107,88],recreat:97,mmdevel_poolam:19,harper:40,latter:[83,28,88,23],cope:[39,99,78,10,108,90,11],thorough:67,fmt_o:46,client:[0,50,72,73,23,70,76,24,79,63,69,85,86,51,88,90,25,5,45,54,27,28,75,56,93,8,64,58,2,66,33,34,35,37,78,38,98,39,99,55,13,10,100,61,15,16,44,17,46,97,105,47,52,53,41,48,102,108,21,62,42,87,68,113,30,67,49],"5th":40,fwd2:48,transmit:[41,64],thoroughli:53,pretenur:40,memo:40,eagerli:66,wherebi:[0,79,62,73],simplifi:[1,69,74,23,70,34,86,95,61,75,4,42],transistor:87,table_set:34,shall:[63,8,23,7,97],bst:19,object:[0,2,22,4,6,8,9,10,11,12,13,14,15,16,17,19,20,21,23,24,25,26,27,28,29,30,31,32,33,34,35,36,38,39,40,44,45,46,47,48,49,50,53,54,55,56,57,58,61,63,64,65,42,68,69,70,71,72,73,74,75,76,77,78,79,81,82,83,84,85,86,87,88,90,91,92,93,94,95,96,97,99,100,102,103,104,106,107,108,110,111],mps_root_scan_t:99,lexic:20,regular:[0,85,83,108,34,6],alan:40,letter:[63,64,3,67,40],phase:[54,78,85,58,32,87,90,11,67],fwd_:48,coin:40,character_:48,prematur:[69,39,72,78,14,65,90],tradit:56,event_poolinit:17,simplic:[50,23,85,42,113,67],don:[1,74,23,24,63,83,8,88,102,54,55,28,30,95,33,34,37,38,39,97,61,45,19,108,66,48,67,49],freeblockcompar:85,simplif:39,doc:[54,64,23],"0x1003f9878":21,flow:[25,64,59,20],doe:[0,69,73,74,23,70,76,77,24,79,81,83,85,22,88,90,25,91,64,54,66,28,7,56,57,8,94,96,32,9,33,10,36,11,78,38,39,99,59,12,13,34,14,16,111,17,46,103,97,105,63,2,37,41,107,65,20,48,93,108,21,100,42,110,87,113,30,67,49],buckets_:[48,34],dummi:[102,8,28],declar:[102,70,3,23,63,83,87,88,25,52,53,75,29,96,51,97,38,39,99,40,45,22,67],metat:20,caml:20,splaynod:85,unchang:[2,66],"2fe338":64,notion:[39,8],came:[76,67],kristen:20,ungar:[79,40,20,88],introspect:[98,99,93,30,58,96,111,26,45,91,46,38,68],wow64:1,sigsegv:113,opposit:[69,70,71,72,73,74,23,76,77,78,79,81,82,83,84,65,86,87,88,90,75,85],esoter:52,cheapli:72,syntax:[45,73,20],minimum_s:93,amcgenstruct:28,modula:[69,14,20],identifi:[48,59,23,29,80,8,79,64,81,46,84,87,63,42,25,17,37,45,67,68],winston:40,figueiredo:20,involv:[74,23,76,24,83,85,86,87,88,90,33,10,11,78,39,59,14,61,62,45,46,107,66],despit:[105,73,74,14,20,87,88,34,45],bind:[21,73],layout:[73,34,14,21,87,33,42,46,67],acquir:[93,13,24,38,111],mpsliban:[41,6],i5m2cc:106,mps_key_mvff_slot_high:[55,37,111],menu:6,explain:[13,14,85,3,33,10,45,37,48,67],configur:[23,24,86,6,91,27,56,93,8,96,10,36,11,38,12,60,17,103,20,111,30,67,49],mps_key_ams_support_ambigu:37,mps_pool_create_k:[98,2,12,93,13,30,10,48,96,111,4,34,52,36,91,46,103],artur:40,philosophi:20,btget:23,splaynodecheck:85,rich:[39,64,20],weakrefer:[83,88,20],predecessor:20,plate:87,strip:42,stoy:[76,40],segpreflow:55,likewis:[8,78],stop:[39,59,40,2,81,32,87,34,25,38],compli:65,ceil:23,mpscmvff:111,watson:40,mps_variety_str:29,report:[102,39,105,40,41,24,100,20,85,86,81,66,17,48],reconstruct:21,mutual:[56,40,49],mps_ap_fil:[102,21],symmetr:85,first_fit:111,softli:[20,83,61,87,88,90],bar:[87,22,67],gareth:[112,66],emb:[50,45,85],"\u00e5ke":40,headerlength:28,baz:[22,67],patch:63,"__date__":29,twice:[39,99,66,51,61],bad:[39,28,74,107,86,20,61,85,21,81,34,52,102],rung:22,tr94:40,singhal:[40,90],steal:[85,38],valid:[70,73,75,78,95,82,85,88,52,102,23,8,58,9,34,24,38,98,99,59,10,14,61,64,97,47,21,66],respond:[107,14,16],mps_arena_has_addr:38,cbssetmins:66,fragmentation_limit:93,victim:17,fair:23,specialist:64,fp_size:61,btcv:23,richer:25,datatyp:56,loreclaim:[11,33],nul:[102,41,17,64],port_ref:34,accumulatorscal:53,result:[0,70,73,23,78,81,85,22,88,90,25,17,28,93,8,66,33,10,36,11,38,98,39,99,87,13,34,61,62,16,45,46,97,105,47,63,53,41,65,102,108,21,42,51,113,48,67,68],"0x1003faf20":[17,21],respons:[1,72,73,75,24,81,85,90,54,55,56,8,32,97,11,78,38,98,39,15,16,45,66],fail:[102,72,23,24,63,51,17,55,75,57,8,64,32,33,34,11,38,39,13,100,61,15,16,45,46,47,53,62,20,21,66,87,48,67],hash:[104,72,105,10,20,83,61,94,21,81,34,48,49],ringjoin:22,splaytreefinish:85,tractofbaseaddr:8,best:[1,70,74,75,81,83,69,87,90,25,93,34,38,39,40,66,53,107,20,42,111,48,67],subject:[0,99,41,66,64,83,61,108,87,34,25,6,46,38,103],awar:[70,45,10],said:[54,69,77,78,61,65,86,88,90,17],hopefulli:33,erez:40,databas:[7,40,97,32,88,66,6,17],delphi:20,phantomli:90,shenker:40,yet:[0,54,28,47,53,13,66,64,108,20,69,102,61,32,21,100,33,10,45,11,48],figur:[1,54,102,22,61],languag:[1,69,72,73,74,75,70,76,78,79,81,84,65,86,87,88,90,102,27,7,94,31,32,33,39,40,41,14,63,45,104,20,108,48,67,68],res_io:61,sos8cx:106,drawn:85,awai:[28,14,33],approach:[28,59,40,107,14,63,85,67],glasgow:40,pad_:48,attribut:[53,105,85,97],inabl:[70,71],accord:[70,23,77,24,81,87,90,45,54,28,95,33,11,39,43,62,63,102,53,107,111,67],never:[50,69,74,23,70,78,79,63,84,88,17,57,8,96,32,34,98,39,59,41,97,44,53,46,105,20,102,93,108,66,48],extend:[54,74,23,24,66,109,20,48,75,97,33,10,25,52,45,8,38,101],mps_:63,sram:87,weak:[1,72,23,83,86,87,88,90,26,54,27,28,30,94,96,33,10,36,11,99,34,53,104,107,20,108,49,48,68],obj_chain:[48,34],extens:[69,99,73,23,57,13,24,67,14,78,20,82,58,45,48,38,49],lazi:[81,100,40,23],unabl:[30,38],preprocessor:[106,77,41,20,21,63,13,67],extent:[71,72,73,75,79,14,81,82,108,87,20],messagefinish:[25,95],dbgpool:[13,61],toler:[83,28,86,10],mps_build_gc:106,xci6ll:[6,106],mps_clocks_per_sec:41,protect:[69,70,74,88,24,63,83,84,87,4,90,26,91,45,54,27,56,93,8,58,96,34,36,78,38,99,59,12,40,10,100,43,30,53,46,103,97,102,21,111,68,113,48,67,49],accident:[52,53,78],expos:[69,28,84,87,25,38],"0000178ea03c2c27":64,fault:[1,69,74,40,8,10,43,81,83,84,87,88,90,26,46,78],howev:[0,70,72,73,74,23,76,78,81,87,88,6,102,54,28,75,7,57,8,32,34,36,38,39,59,41,97,16,44,45,20,42,112,113,48,67],shouldn:[54,48,33],against:[39,105,57,8,90,85,101,42,64,78],eventcom:64,logic:[28,23,76,79,20,84,88,33,67,49],messagecollectionstatscondemnedsizemethod:25,browser:20,mps_telemetry_databas:17,col:44,mps_rm_t:[99,88],con:[0,73,40,75,20,83],rehash:[105,48,34],epdldebugsig:45,threadregist:59,bool:[50,28,23,53,8,64,43,95,85,9,66,35,52,45,24],toni:[45,112,59,40,23],character:[83,39,40,20],ref_o:108,delic:10,loader:38,dconfig_var_cool:[6,21],enorm:[61,28,112],guil:20,exemplari:[7,97],dsm:11,vmmap:[17,15],free_siz:2,wider:6,guid:[27,28,105,23,64,24,14,104,58,85,63,95,10,45,48,88],assum:[50,69,73,77,24,83,102,54,28,32,10,11,99,13,61,15,16,53,108,45,48,67],summar:[8,49],duplic:[54,73,74,8,14,65,85,11,67],mps_lib_fput:41,liabil:[7,97],degener:79,fre:20,union:[54,105,19,75,8,63,86,95,24,34,52,53,37,48],convolut:28,three:[0,70,73,78,81,83,84,85,22,88,90,5,6,91,64,54,28,29,57,8,32,9,34,36,38,39,13,66,14,61,63,17,46,105,106,107,65,20,102,93,21,42,87,48,67],been:[0,1,72,73,74,23,70,76,78,79,95,69,83,85,86,87,88,90,25,45,54,28,106,8,64,94,58,92,32,33,34,35,37,38,98,39,13,66,14,43,61,15,16,17,46,97,105,47,19,53,65,20,48,102,108,21,100,42,112,113,30,67,49],specul:[23,20],accumul:[28,19,77,14,97,53,11],much:[0,1,72,74,23,78,69,86,6,54,28,57,58,32,33,11,38,39,42,14,62,16,47,107,108,15,66,48,67,101],mps_arena_unsafe_restore_protect:38,mult:45,interest:[0,39,48,88,13,66,20,46,94,109,58,33,42,25,54,6,11,17,38,49],subscrib:109,insert_link:102,"__time__":29,cohen:40,quickli:[73,74,8,78,86,38,33,48,67,88],withreservoirpermit:[24,28],life:[40,93,79,58,34,25,11],retrospect:40,lifo:[70,79,87,75],suppress:[63,67],tractreturn:8,uncommon:28,ani:[0,50,72,73,74,23,70,76,24,79,81,82,83,85,86,3,88,90,25,52,6,45,54,55,28,75,7,29,93,8,64,95,32,9,33,10,11,78,38,39,99,111,59,87,13,101,34,14,43,61,15,16,44,66,17,46,97,105,19,63,2,53,37,41,56,107,65,20,48,102,108,21,100,42,110,22,113,30,67,49],"0x0000000100001ef7":21,unzip:6,dave:40,lift:23,efficaci:11,child:[85,9,22,81],"catch":[72,47,67,20,95],pool_o:[98,12,93,30,96,4,10,111,36,91,103],fourteenth:40,"_m_ix86":67,emploi:79,type_fwd2:48,mps_alloc_pattern_ramp_collect_al:62,ident:[105,59,23,106,57,24,79,100,63,84,4,66,45,16],aix:76,gnu:[0,106,20,21,6,17],ada:70,servic:[54,39,7,107,78,97,14,43,86,87,16,66],properti:[23,24,79,81,83,85,86,87,4,26,91,64,27,93,30,58,96,34,36,38,12,40,10,53,103,105,47,66,45,111,68,48,49],mps_lib_memcpi:[41,53],commerci:[1,39,7,97],mps_rm_const:[99,73],conclud:[25,39],aim:[40,20],calcul:[28,107,58,83,53,46],"1992c":[76,86],zerokei:85,publicli:[39,20],thrash:[39,40,78,83,86,88,90],aid:[99,66],vagu:74,anchor:40,spawn:20,seven:[111,28],cons:75,mps_amc_apply_stepper_t:30,arenasetcommitlimit:8,mexico:40,tabl:[71,72,73,74,23,81,82,83,84,86,17,88,90,64,27,28,106,57,58,92,33,10,37,38,99,40,34,15,53,104,105,20,94,21,48,49],freeblockofsplaynod:85,contributor:[7,97],noop:67,cond:9,conf:[67,40,49],mps_thr_t:[99,86,113,48],symtab_s:[99,48],"1003fd328":17,maximis:111,dumper:[64,58],disappear:[108,28,88,63,66],grown:20,mps_word_t:[99,105,53,63,21,33,42,17,37,48,38],op_env:21,descent:85,incorrectli:[108,75],receiv:[39,99,21,73,7,76,64,107,14,108,48,85,9,66,25,17,46],suggest:[39,23,57,13,76,109,3,66,111,112,11,48],make:[0,50,71,72,74,23,70,24,79,81,69,84,85,86,51,88,90,52,6,45,54,95,28,75,7,29,57,30,58,32,33,34,106,11,78,38,98,39,99,60,13,101,66,14,61,15,63,17,46,1,104,47,53,41,56,107,20,102,93,94,21,42,87,68,113,48,67,49],transpar:[99,72,76,13,63,61,86,102,105],tobas:23,who:[0,13,20,39],complex:[39,75,55,78,86,14,20,61,85,21,81,45,67,88],guardian:[25,45,100,40],split:[70,72,74,23,107,24,79,14,58,83,61,85,87,66,5,17],mps_mvt_free_siz:93,phantom:[83,87,88,20,90],complet:[102,73,23,78,83,85,87,45,54,7,57,95,32,41,11,38,39,99,13,97,14,64,46,42,48,67],elli:[54,40,20],mps_fmt_adjust_fencepost_t:61,fragil:42,evid:[21,75],vvv:17,quentin:40,rail:70,kit:[27,6,104,7],fairli:[71,11,88],rais:46,refil:[28,113,102],ownership:56,refin:[54,32,73,88,20],gustavo:40,poolarena:[45,59],protocolerror:66,mps_io_t:41,studi:[61,14,40],tune:[27,28,40,39,57,30,104,48,21,52,46,78],dylan:[28,23,7,100,8,34,14,20,84,33,10,25,45,11,67],char_bit:106,undesir:[25,93,59,95],bewar:[102,21],mps_ap_trip:102,mps_lib_assert_fail:41,thu:[0,39,28,73,76,77,90,20,83,93,69,86,33,34,53,102],messeng:[39,40],thr:[99,113],inherit:[27,75,58,20,44,45],poolmrg:[25,35,100],contact:[1,27,99,7,10,63,109,102,96,94,21,51,97,34,111,6,113,36,38],greatest:23,thi:[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,19,20,21,22,23,24,25,28,29,30,32,33,34,35,36,37,38,39,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,61,62,63,64,65,66,67,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,90,91,93,94,95,96,97,98,99,100,101,102,103,105,106,107,108,110,111,113],endif:67,lockstruct:56,programm:[0,39,28,75,70,76,78,106,14,108,20,93,69,87,81,45],everyth:[99,17,48,19,28],portabl:[1,40,41,20,87,63,42,17,48,67],arenasetsparecommitlimit:8,ringfinish:[22,95],bufferinitseg:64,left:[66,28,73,23,2,53,13,8,34,107,78,20,63,85,42,4,90,17,24,38],arena_ld_length:8,protocol:[1,73,75,24,81,83,85,51,25,64,54,27,28,8,58,96,97,35,99,59,42,61,44,53,102,110,66,45,48,67,68],background:[23,56,8,65,58,85,101,38],just:[0,70,73,74,23,24,83,85,17,2,25,52,6,53,54,55,28,75,57,64,94,95,33,34,11,38,39,99,66,100,61,44,45,46,20,108,21,42,87,113,48,67,49],mps_sac_alloc_fast:16,shapiro:40,antidot:25,greyr:24,"0000178ea03f6b72":64,orient:[54,70,40,76,78,20,85,45],bandwidth:[78,88],entranc:22,"_mps_key_extend_bi":52,human:[25,5,17,64,29],ifdef:67,nowadai:[83,87],unbuff:[55,111],poolcondemn:97,act_on_rang:23,previous:[19,75,56,108,85,33,34,35,17],messagecollectionstatsnotcondemnedsizemethod:25,"000ae0397335c8b5":17,easi:[64,99,59,23,30,14,20,48,83,21,22,101,52,6,113,46,67],amcseggen:28,interfer:38,had:[0,39,19,100,20,54,61,21,88,34,52,17,82,111,48,74],lumpi:47,define_class:45,fortran:[14,20],spread:[39,107,77],"0x1003f9ae0":21,board:[28,40],henriqu:20,els:[0,54,28,10,95,85,21,67,44,34,102,48,38],save:[69,71,73,40,42,20,87,66],elt:22,gave:[39,20],opt:6,applic:[1,70,75,78,84,69,87,90,25,6,93,31,38,39,40,41,14,107,20,108,21,42,49],"2fe288":64,"0x1003f9c18":21,preserv:[28,72,77,83,86,87,33,97,64],r_o:113,pretest:[0,20],distanc:46,lcc:106,birth:93,"0x1003f99d8":21,obj_isfwd:[46,48],"0x000000010000ea40":21,apart:[9,14],richardk:3,measur:[74,40,78,87,33,42,53,38],overcompens:78,specif:[102,73,23,24,79,88,90,25,52,17,54,28,75,56,8,31,33,97,35,11,78,38,98,39,99,40,14,61,44,53,47,20,66,67],arbitrari:[8,63,82,85,3,45,46],bufferinit:[64,97],hunt:40,manual:[0,1,72,75,70,77,78,2,82,69,51,97,90,26,91,54,27,93,58,31,96,32,33,10,52,98,39,99,55,66,14,61,16,111,102,103,20,42,87,68,48,67,49],mit:40,dep:67,"0x00000001003fb130":21,mps_pf_fri3gc:106,src_ld:105,slothigh:55,unnecessari:[69,39,28,33,34],underli:[73,34,14,108,87,66,64],jean:40,www:[6,97],right:[39,23,40,57,24,66,14,63,61,85,97,42,53,7,48,49],old:[69,70,73,74,75,76,77,24,79,85,86,22,88,90,25,102,27,28,106,8,58,32,34,11,78,39,53,46,105,20,66,3,48],mps_arch_s8:106,deal:[39,28,105,84,53,71,20,83,76,87,90,45,36,67],spongr:22,interv:[0,70,23,66,43,34,102,48,38],mps_arch_s9:106,maxim:[54,93,45],percentag:93,mmqa_test_funct:23,zct:[72,92],born:90,intern:[102,70,71,74,23,100,81,85,87,90,25,52,6,17,8,64,58,33,34,38,98,39,59,40,60,13,101,14,61,16,53,103,41,107,21,66,67,49],c90:73,addrcomp:53,pain:[39,33],indirect:[71,72,7,65,81,85,33,97,11],successfulli:[98,99,72,47,102,85,62,16,66,45,46,38,88],make_pair:48,mps_key_max_s:[93,52,91,37],txt:[17,67],cooper:[54,74,40,56,8,86,20,32,15,38],trace:[69,72,73,74,75,24,79,81,83,86,87,88,17,54,28,8,58,31,32,33,97,11,78,38,99,40,100,15,44,64,46,19,53,21,42,48],bottom:[99,10,34,95,85,21,66,48],stronger:74,mps_class_amcz:[37,4,34],fox:40,arthur:40,subclass:[28,74,60,8,61,22,45,24],messagestruct:[25,95],track:[54,39,73,70,13,85,20,61,32,21,87,81,11,48,88],ucsc:40,eventcnv:64,argchecks:52,overcom:20,condit:[69,75,24,81,85,87,25,6,45,28,7,9,97,11,98,39,13,14,62,53,46,102,66,48],foo:[63,21,22,16,97,17,67],type_integ:[48,34],c99:[52,73],arg_define_kei:52,rampgen:28,plu:[93,8,7,97],sensibl:[11,97],idiomat:22,bold:39,safest:42,someclass:45,pose:48,libsqlite3:6,confer:40,colmerau:20,splaytre:85,promot:[69,28,47,75,77,30,86,101,90,45],"0x7fff5fbff808":21,hsu:40,mps_frequenc:16,messagereturn:25,"super":[61,45],gartner:20,proceed:40,chapter:[85,21,40,38,48],"0005e040":64,alexand:40,"0x1003cb970":21,steadili:93,slightli:[28,59,8,66,88,33,34,11],mpslib:[41,6],simul:[84,55,40,20,66],felleisen:40,poolscan:[21,97],despair:49,mps_key_awl_find_depend:[34,37,10],frame_o:51,old_symtab_s:48,coars:64,commit:[102,99,59,13,8,78,58,15,87,16,97,73,53,48,38],sept:40,produc:[98,28,47,23,99,20,61,67,17,102,38,88],fixedsummari:11,eventdump:64,encount:[13,17,14,42],buffertrip:59,"float":[69,70,28,75,77,81,65,22,90,87,67],encod:[74,23,29,86,83,84,65,15,88,17],bound:[0,72,47,74,23,76,78,79,20,84,85,21,87],soo:40,two:[0,70,71,72,73,74,23,24,2,81,83,84,85,86,22,4,90,25,6,53,54,28,75,29,8,64,32,66,10,36,11,78,38,39,99,59,40,13,34,14,61,15,16,44,111,17,97,105,47,19,63,41,56,107,20,48,102,21,62,42,87,30,67,88],down:[0,70,23,24,95,85,86,87,88,6,54,28,106,8,58,9,33,41,11,38,39,13,61,16,46,20,21,66,48],attrincr_rb:53,"0x0":21,seglo:24,formerli:[106,73,34],lieu:54,wrap:[83,39,65,61,42],opportun:[61,85,47],cafeteria:87,storag:[0,69,72,73,74,23,76,78,79,82,83,84,87,88,90,25,75,93,32,38,39,40,45,20,66],kakkad:40,sigsoft:40,accordingli:[5,20,41],suffici:[69,28,23,93,107,24,64,20,85,86,45,48],mps_class:46,mps_t_word:[53,67,106],judici:[39,85],support:[0,50,72,73,74,23,70,24,63,82,85,86,51,88,90,5,6,91,53,54,55,28,75,56,93,30,64,94,96,32,66,41,34,36,78,39,99,12,40,13,101,10,61,15,16,44,111,45,46,1,103,104,105,106,107,20,48,102,108,62,42,110,87,68,113,8,67,49],extendbi:55,happi:67,avail:[50,1,73,74,23,70,78,81,84,86,87,88,90,25,6,17,28,75,7,57,41,38,98,39,13,34,14,64,97,19,107,20,102,93,21,66,113,67],width:[75,106,66,53,11,67],reli:[39,59,76,13,108,63,93,32,86,33,73,17,113,102,49],editor:[112,20],fraction:111,acknowledg:[27,112],overhead:[54,39,28,59,75,23,93,8,14,85,81,84,32,86,33,66,45,11,78,49],btfindresrang:23,lowest:[55,9,75,23,111],head:[50,77,61,22,64,102],traceid:53,toward:[39,87,23],form:[0,69,72,73,23,70,76,77,78,79,81,82,83,85,86,3,88,90,17,28,7,95,9,10,11,13,97,14,63,111,64,37,107,20,21,66,87,113,48,67],offer:[69,20,83,61,87,90],forc:[39,20,42,25,17,48],poolno:[110,97],st85:85,somehow:20,substrat:15,splaytreenext:85,hear:49,dead:[69,70,72,73,75,76,77,78,79,81,65,51,88,54,28,57,30,95,96,33,97,62,102,47,21,48],heap:[69,70,72,73,74,75,78,81,82,86,87,88,54,30,97,11,38,39,99,40,14,46,107,20,21,42,48],old_symtab_root:48,oopsla:40,hashtabl:34,"true":[0,70,23,24,63,85,25,64,55,28,75,8,95,9,34,35,11,38,98,39,10,43,66,53,46,105,102,108,42,45,111,48],freenod:85,reset:[28,105,23,8,34,53,17],"throw":[28,14],flavour:28,attr:[13,8,53],full:[50,39,28,21,70,24,106,86,108,20,82,85,9,22,16,95,34,17,62,48,38],rattl:39,maximum:[50,54,79,47,23,93,8,67,61,85,16,66,53,91,64,38],tell:[0,1,71,105,29,90,99,20,54,70,69,67,34,102,48,38,88],dens:23,tucson:40,absenc:[41,100,61],autoconf:6,emit:[28,75,97,64,11,17,67],mpscsnc:96,accessset:[53,24,43],uncoop:[78,40],featur:[0,72,75,63,85,86,87,88,2,102,27,8,58,34,38,99,10,14,61,30,17,20,48],alongsid:[45,72],mps_word_width:[67,23,106],classic:[39,6,87,32,82],utc:[17,21,40],"abstract":[50,39,67,40,23,56,8,60,43,20,54,70,61,85,9,58,45,53,38],consciou:40,decrypt:42,mps_class_t:[98,55,12,96,93,30,10,61,4,90,111,36,91,103],"__line__":61,diagnost:[6,28,67],refsetismemb:24,exist:[0,72,23,78,63,85,17,25,5,64,54,28,8,32,33,35,37,39,61,16,53,46,47,11,66,45,87,112,48,101],darko:40,amcbuffertrip:[],triv:110,check:[0,50,72,23,70,76,24,2,85,22,95,52,25,26,6,53,54,27,28,56,8,58,96,9,33,34,11,38,98,39,59,40,60,13,66,61,16,45,97,19,106,107,102,108,21,42,110,51,48,67,101],protsync:[43,67],buckets_find_depend:34,assembl:[40,20,85,33,52,67],"_io":[63,81],encrypt:42,testor:56,amcgencr:[28,64],index:[27,105,74,23,70,20,83,87,81,33,90,53,64],tracepol:[8,21,11],when:[0,50,71,72,73,74,23,70,76,77,24,79,81,69,83,85,86,22,4,90,25,5,6,91,45,54,55,28,75,57,8,64,94,95,96,32,66,33,10,36,11,78,38,39,99,113,12,13,34,14,61,15,16,44,111,17,82,46,103,97,105,47,19,63,88,53,37,41,107,65,20,48,102,93,108,21,100,42,110,87,2,30,67,49],lockclaimrecurs:56,fixer:11,mps_begin:61,poolstruct:[110,28,97],role:[70,48,67],jone:[39,72,40,76,14,81,86,88,97,112],fmt_scan:99,test:[0,69,23,76,78,84,85,17,95,6,45,106,57,58,9,33,34,11,38,39,13,15,53,105,20,102,94,21,66,111,48,67,68],ckq:3,presum:[25,8,56],telemetri:[27,105,57,13,41,97,64,58,48,86,21,63,33,34,6,17,38,68],unlimit:[39,9],jonl:[112,74],node:[69,71,73,77,83,85,86,22,44,66,25,87],matur:[13,30,40],relat:[69,70,71,72,73,74,75,76,77,78,79,80,81,83,84,65,86,17,88,90,64,28,9,39,14,53,46,105,19,20,66,45,87],intend:[23,76,24,85,3,4,64,28,56,93,30,9,41,38,99,12,13,42,53,46,97,105,20,66,45,113,48,67,88],prot:[25,8,43,67],benefici:[55,85,23],subdivid:24,put:[54,70,28,105,73,19,23,76,78,10,100,63,61,65,95,90,110,11,34,38],felt:39,stringid:17,mps_args_:37,intens:[72,11,40],intent:[23,86,63,15,66,25,17,53],consid:[69,39,47,75,23,70,77,8,79,14,87,97,33,66,102,98,46,78,49],xavier:40,mps_build_ac:106,russo:40,mps_telemetry_set:17,younger:[69,28,73,77,71,81,88],event_kind:17,my_malloc:39,longer:[0,70,72,73,23,24,79,87,88,90,45,28,32,10,35,11,78,98,39,13,97,14,15,16,53,46,47,20,108,112,48,67],furthermor:[61,99,33],leah:112,home:20,arenainit:[8,59],phantomrefer:[88,90],blockrang:66,candid:[73,46,23],iwmm:40,phong:40,ignor:[28,73,62,99,81,32,9,88,33,25,52],mrb:76,config_:67,time:[0,1,71,72,73,23,76,78,79,81,69,83,84,85,86,3,88,90,25,6,45,54,55,28,75,7,29,57,30,64,94,95,32,33,10,11,38,39,99,59,40,13,34,14,61,62,16,44,111,17,82,46,105,47,19,63,2,53,37,41,56,107,65,20,48,102,93,108,21,100,87,68,113,8,67,49],push:[75,79,3,51,87,103],mps_fmt_fwd_t:[70,46,48],offsetof:[10,42,48,21,97,102,34],backward:[69,23,8,3,52,67],hope:[99,15,67],strong_buckets_ap:34,concept:[67,40,33],rom:[78,88],chain:[0,69,72,74,75,70,77,78,79,83,85,87,4,2,28,57,30,34,36,37,38,45,104,47,107,65,48,68],globals_root:48,skip:[102,70,28,12,23,30,34,104,48,96,21,87,4,33,10,36,46],oss:15,consum:[0,81,51,38,52,67,88],ost:40,invent:[69,32,74,20],osi:7,cacm:40,signific:[69,39,59,75,23,93,41,8,107,14,83,85,86,90,111,17,64,78],addrcopi:53,dalton:40,milo:40,pldi:40,event_foocreate_param:64,osf:[6,106],hierarch:40,decid:[54,39,28,47,23,97,14,102,61,87,16,33,90,73,53,48,38,49],middl:[28,73,78,99,81,85,21,88,66,45,102,38],depend:[69,70,72,73,23,79,63,83,84,85,51,88,90,26,91,17,27,28,75,106,93,8,64,58,96,9,33,10,36,11,38,39,99,12,13,34,61,111,101,66,45,95,103,104,105,47,53,107,65,20,48,94,42,87,68,113,30,67,49],zone:[54,19,8,15,33,11],graph:[69,71,72,73,77,81,83,86,87,44],decim:101,intermedi:[93,33],w3ppmv:106,rel:[39,72,74,86,20,15,87,16,64],environment:41,yve:40,rightmost:23,morereturn:21,decis:[47,75,23,41,95,94,51,33,48],jvm:20,tenur:[39,86,40,90],lasttract:8,aspx:67,henderson:40,brown:40,sourc:[1,75,85,3,97,6,45,27,7,29,8,64,58,10,38,39,40,60,41,66,61,53,105,20,17,94,42,22,67,49],mps_pf_lii3gc:106,string:[102,39,81,47,40,29,41,86,64,20,84,21,4,33,34,17,37,48,67,101],barrett:[112,40],blumof:40,"1003fe000":17,experienc:39,unfamiliar:80,feasibl:61,broadli:[79,46],bruggeman:40,octob:40,word:[69,72,73,74,23,77,78,81,83,86,17,88,89,90,64,28,75,109,33,10,99,34,42,61,63,53,46,103,102,21,66,87,48,67,101],exact:[70,71,73,75,78,63,86,87,88,90,102,28,106,30,96,33,10,36,11,99,13,34,53,48,49],seemingli:21,cool:[73,13,82,84,21,17,88,6,64,67],"0x1003f9af8":21,format_return:61,"0x1003fe278":21,administr:[14,20],level:[1,73,75,24,81,82,83,84,85,17,88,90,64,106,8,58,32,9,34,11,78,39,10,14,61,15,53,20,21,66,87,67],did:[39,19,20,34,52,48,38],die:[69,47,75,30,81,21,88,33,34],gui:40,dig:64,metadata:[34,10],iter:[23,60,8,20,85,22,58,33,66,48],rusag:41,magnet:74,item:[101,8,87,85,29],unsupport:[24,64],exit_failur:39,signif:59,recogniz:74,dip:61,round:[28,74,13,107,14,87,16,34,111,102,48,38],dir:67,o1algc:106,prevent:[0,28,59,19,40,8,44,108,94,32,86,16,33,10,73,53,88],edelson:[87,40,20],slower:[39,78,73,74,23],core:[28,72,73,78,63,64],segmerg:24,sign:[52,8,95],oldspac:[76,70],colin:40,cost:[71,72,76,78,79,95,83,85,86,87,4,102,54,28,7,57,58,32,34,59,40,42,16,17,97,20,93,66,48,67],unprotect:[99,72,59,10],minimis:[64,67],relocat:82,port:[41,20,108,34,64,48,67],mps_sac_alloc:16,leaf_ap:34,addr:[50,24,85,17,64,28,8,34,37,38,98,10,100,43,61,101,30,53,46,105,102,21,66,45,48],malo:40,texa:40,protocolclassstruct:45,uniform:[75,23,97],current:[0,50,73,74,23,70,24,84,85,86,22,88,90,6,17,54,28,75,29,8,10,36,11,106,38,99,59,66,14,61,101,45,1,19,53,87,56,20,42,51,113,67],"0x00000001003f9730":21,coalesc:[50,27,71,72,73,74,75,70,93,39,79,107,58,83,87,66],suspect:21,mps_os_i5:106,filenam:17,va_list:[98,55,61,52,45,102,38],tolimit:23,failobj1:45,lockclaimglob:56,defici:50,deriv:[72,73,74,76,41,8,81,32,86,22,63,66,110,45,11,53],harder:[107,81,20,90],vector_:[48,42],amalgam:6,gener:[0,1,71,72,73,74,23,70,76,77,24,79,80,81,69,83,104,85,86,51,4,90,25,52,6,91,53,54,27,28,75,56,57,8,64,94,58,33,10,35,36,11,78,38,39,99,40,34,14,43,61,15,16,44,111,45,46,97,47,19,63,88,62,107,20,48,102,93,108,21,42,110,87,113,30,67,68],"1003fa7d0":17,integer_:48,disclaim:[7,97],consult:[25,41,8,102,33],explicitli:[1,69,63,53,79,20,85,81,25,45,11,17,38],modif:[73,23,7,20,61,32,87,88,97,6,11],address:[0,70,71,72,74,23,76,77,24,79,81,82,83,84,85,86,87,88,90,53,55,28,75,57,8,64,58,66,33,10,37,78,38,98,39,99,13,34,15,16,17,46,105,63,11,107,65,20,48,102,21,42,111,113,30,101],failnoteseg:45,ratio:93,along:[50,28,73,13,24,97,107,95,77,34,45,11,53],lii6gc:[6,106],wait:[0,1,59,8,34,38],epdldebugpoolclass:45,mps_os_ia:106,bop:22,shift:[53,67,33,23],finalizationmessag:25,steffen:40,queue:[0,73,78,34,100,95,83,108,87,88,33,66,25,68],weak_array_:10,attrpm_no_read:53,behav:[39,73,14,63,84,62,45],sigxcpu:113,amcrampbegin:28,extrem:[28,86,95,15,87,33,67],bob:40,rafael:40,reclaim:[0,1,72,73,70,77,79,81,83,69,86,51,88,90,25,91,92,54,28,93,30,94,58,96,32,10,36,11,98,99,12,13,34,61,111,53,103,97,19,2,20,102,108,87,48,49],macintosh:[67,40,106],mps_rank_t:[99,96,88,10,53,37],chalmer:40,semant:[72,41,8,20,25,45,11,64],refsetuniv:[54,19],regardless:[28,38,66],prerequisit:[6,104],grunwald:[79,40],extra:[98,39,28,72,59,23,8,81,83,110,32,33,97,25,102,78,38],messagepost:25,pentium:72,modul:[50,69,23,24,81,85,90,25,52,54,27,7,29,8,58,97,39,59,60,41,14,43,15,45,56,20,66,67,68],prefer:[55,74,8,32,33,53,37,6],special_:48,reig:40,type_uniniti:102,visibl:[63,59,75,38],marker:[70,99,75,76,48,51,46],prompt:[70,108,20,32,88,10,6,38],mobil:28,post:[0,70,47,19,78,95,108,34,25,64,11],tracecr:11,transplant:85,prei:90,perf:[64,59],memori:[0,1,2,22,6,7,8,10,11,13,14,15,16,17,18,20,21,23,24,25,27,28,106,30,31,32,33,34,35,38,39,40,41,42,43,53,46,47,48,49,50,52,54,55,57,58,61,62,63,64,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,65,86,87,88,89,90,92,95,97,98,99,102,104,105,107,108,109,111,112,113],aaron:53,univers:[54,22,40],visit:[69,99,74,30,21,6,46,38],todai:[39,87,20],perl:[69,14,3,20,70],cmp_t:[105,34],live:[0,70,71,72,73,75,78,79,83,69,86,88,90,28,57,30,94,32,10,39,99,12,40,13,34,62,16,97,47,2,65,108,21],handler:[50,21,8,43,84,9,90,17,113,46],bole:40,mps_key_args_end:[52,37],scope:[87,20,22,95,33,3,45],prev:102,guido:20,ree:66,trishul:40,unsaf:[87,108,59,38],idempot:17,afford:[54,39,33],peopl:[0,39,73,78,80,20,109,86,87,112],claus:7,brooksbi:[1,40,95,66,52,112,67],scholten:40,visual:[1,73,106,20,6,67],appel:[54,74,81,40,90],olivi:40,accept:[28,47,78,97,48,86,16,42,73,45,46,67,49],examin:[54,72,74,23,77,64,43,32,105,87,33,45,11,48,38],mustn:[25,99],obj:[28,21,8,34,100,48,61,94,9,42,102,46,105],mps_pool_check_free_spac:2,effort:[13,78,81,38,90,67],easiest:[61,59],behalf:39,fly:40,judi:112,graphic:[64,112,67,20,74],amcfinish:28,poolam:[13,23],car:[21,48,40,42],prepar:[0,47,21,16,97,102],pretend:14,judg:28,uniqu:[54,59,74,40,17,53,67],imper:20,descriptor:[70,28,8,97,66,24],abcdef9811c7340bc6520f3812:[3,95],can:[0,1,2,3,6,7,8,10,11,12,13,14,15,16,17,19,20,21,22,23,24,25,28,29,32,33,34,36,37,38,39,40,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,59,61,63,64,65,66,67,69,70,71,72,73,74,75,76,77,78,79,81,82,83,84,85,86,87,88,90,92,93,108,97,99,100,102,105,106,107,94,109,111,113],inadequ:[87,14],findshortresrang:23,purpos:[70,73,74,78,95,85,87,4,6,91,17,28,7,56,93,8,58,10,38,39,59,40,42,16,30,45,46,97,20,66,111,113,48],laughter:17,preclud:49,cisc:79,boilerpl:45,strother:40,mps_arena_t:[0,75,76,63,4,91,93,30,96,10,36,37,38,98,99,12,61,46,103,105,47,108,111,113,48],encapsul:[105,8,90,83,15,87,88,34,25,38],stream:[70,101,74,13,41,66,64,48,86,85,21,97,34,6,17,38,68],predict:[39,93,47,75,23,57,73,79,14,76,15,87,33,111,52,102,91,38],mps_root_create_fmt:99,unreason:59,agent:54,seglimit:24,heard:39,critic:[102,73,78,81,82,25,17,27,28,56,95,33,11,40,60,13,61,64,21,42,45,48,67,68],abort:[41,17,21,48,42],sharp:62,recycl:[69,70,73,75,78,79,81,86,87,88,2,54,27,30,31,32,33,97,38,99,14,107,20],mps_pf_xci6ll:106,unfortun:[39,28,14],occur:[0,70,72,73,75,76,78,81,83,84,65,86,87,88,90,45,28,95,32,11,38,13,14,62,53,105,102,48],verlag:40,alwai:[0,50,74,75,70,24,79,81,83,84,69,87,88,2,52,17,28,106,93,64,34,35,11,38,39,99,59,13,61,62,63,44,53,46,19,107,21,42,111,48,67],differenti:88,exit_cod:99,multipl:[1,69,72,23,70,76,77,2,82,83,85,86,87,90,45,54,28,75,56,8,58,10,11,38,39,59,61,62,16,44,64,103,105,65,20,102,108,113,48,68],instant:[98,70,38],mps_frame_t:51,noaver:11,oslo:[0,20],mps_telemetry_intern:[17,86],write:[0,72,73,74,76,24,100,81,83,84,85,87,88,90,26,6,45,54,27,28,7,64,33,10,38,39,99,12,40,41,101,14,43,61,15,63,17,19,53,20,102,108,109,5,42,113,48,49],vital:[74,13,81,42,102,53],anyon:[39,3],foreach:3,fourth:[64,48],familiar:[54,48],parameter:67,predictor:40,controlalloc:[8,45],poolclassepvm:23,unlucki:108,product:[1,69,104,75,7,29,13,30,46,61,21,67,33,36,6,17,38],proc:[40,29],snc:[26,49,51,96,27],book:[112,14],csl:40,max:8,clone:40,scoff:67,make_t:34,usabl:38,splaytestnodemethod:85,intrus:[28,40],membership:[8,66],mad:40,"1993a":[84,88],mai:[0,1,71,72,73,74,75,70,76,24,79,81,69,83,84,85,86,3,4,90,25,6,91,45,28,56,93,8,64,94,95,96,32,66,33,10,36,11,78,38,98,39,99,59,12,40,87,13,101,34,14,43,15,16,111,17,46,103,97,105,47,19,63,88,53,113,41,107,65,20,48,102,108,21,62,42,51,2,30,67,49],segloreturn:24,underscor:[52,63],allocat:56,data:[50,1,72,73,74,23,70,76,24,79,81,82,83,84,69,86,22,88,90,45,27,75,7,56,8,64,58,32,9,33,34,78,38,39,99,59,12,40,60,13,66,14,61,62,16,17,95,97,2,53,41,65,20,102,21,42,87,113,48,49],grow:[0,39,28,47,93,78,87,66],man:[78,23],mps_key_mvff_arena_high:[55,37,111],mps_fmt_class_t:46,stress:[6,66],mps_arena_:[76,8,63],practic:[54,28,105,59,40,23,14,63,83,32,15,42,110,73,17,48,74],findshortresetrang:23,mpsio:[41,17],explicit:[39,72,59,74,70,14,20,61,45],mps_root_create_t:[99,48,34],pooltrivbufferinit:97,subsequ:[39,28,72,73,19,70,66,25,52,11,38],inform:[0,69,72,73,74,75,70,76,78,80,81,83,84,65,86,90,25,45,54,7,29,8,64,31,32,109,33,97,11,38,40,41,66,14,61,15,17,46,47,21,42],"switch":[28,42,64,20,48,33,34,6,36],preced:[107,28,37,85],combin:[1,73,83,88,90,6,54,55,106,8,95,32,39,40,14,61,15,16,44,107,20,66,111,67],deposit:50,finddelet:66,csd:40,splaytreeneighbour:85,ordinarili:28,talk:[61,28],approx:54,"_ts_":61,shield:24,schwartz:[83,86,40],anticip:[39,90],changeov:33,approv:[7,66],ymmv:1,cutt:40,mps_fmt_destroi:[46,48],mps_key_pool_debug_opt:[111,36,91,37,2],thr_o:113,lsp:[28,58],eventmaxstringlength:64,size_t:[23,63,2,52,91,102,55,56,93,30,10,37,38,39,99,41,34,43,61,16,53,46,103,47,21,42,111,113,48,67],equip:40,still:[69,72,23,78,79,85,86,22,89,90,25,6,17,54,28,75,56,94,32,33,34,11,38,39,97,14,61,64,46,105,20,108,21,66],ieee:40,dynam:[69,72,73,75,78,79,81,82,65,86,87,88,25,28,8,95,39,59,40,45,107,85,20,108],"0x000000010006631f":21,conjunct:[72,67,56],interspers:85,group:[28,112,64,19,20],mps_key_align:[55,37,111],concis:[52,17,66],mckinlei:40,zendra:40,elliot:40,torn:95,bekker:40,tort:[7,97],window:[1,69,74,56,41,78,106,43,95,65,67,10,6,113,53,38],mps_var:67,curiou:17,mail:[23,61,109,3,52,45,11,64],arguabl:45,main:[72,73,74,78,63,84,85,86,87,88,90,52,28,58,32,39,99,40,45,107,21,66,48,67],message_o:0,recoveri:[64,40],non:[73,23,77,24,81,85,86,22,88,2,25,5,53,54,28,75,7,56,8,58,66,34,35,36,11,78,38,99,59,40,13,10,45,46,97,105,41,20,42,110,87,48],free_templ:2,recal:[59,48],halt:[69,75],traceaccess:19,halv:86,mmqa:23,mps_arena_walk:61,cbsblocksiz:66,jame:40,alist:13,mayuseinlin:[55,66],initi:[50,70,73,23,24,79,83,85,86,22,95,25,64,28,56,57,8,58,33,34,11,38,39,99,59,97,43,16,53,102,66,45,87,48],sol:[64,59],tucker:[112,40],varag:52,therebi:[69,23],half:[86,43,23],superset:54,provision:54,discuss:[54,70,29,14,83,108,109,45,48],nor:[72,78,79,83,87,16,90],introduct:[50,1,23,24,85,22,95,52,25,5,6,53,54,27,28,29,8,60,64,58,31,9,33,97,35,11,59,55,43,61,15,101,45,104,66,3,48,67],critiqu:40,obj_scan:[94,48,46,42],term:[1,70,71,72,73,74,75,76,77,78,79,81,82,83,84,69,86,87,88,89,90,6,28,7,93,33,39,59,14,61,64,65],workload:40,name:[74,23,76,79,81,22,97,25,52,6,53,54,28,75,29,10,64,95,9,41,37,39,60,13,34,61,63,45,46,106,20,17,66,67,101],lewi:[40,20],mps_rank_weak:[99,10,83,94,88,34],predefinit:67,didn:[69,19,75,20,61,85],revert:54,type_vector:42,buckets_pool:34,btre:23,separ:[71,73,23,76,78,79,63,84,22,88,6,64,54,32,33,34,38,39,59,14,61,15,16,44,111,53,103,66,45,87,67],mps_addr_return:[],wrt:59,massachusett:40,gain:[57,20,61,42,113,38],sigusr2:113,januari:40,mps_fmt_put_fencepost_t:61,confid:[32,36,34],compil:[1,70,72,73,74,23,76,78,79,81,82,84,65,86,87,88,90,25,5,6,17,7,29,95,32,33,11,39,99,40,13,64,104,106,20,102,21,42,48,67],nick:[112,40],splaytreeinit:85,replai:[64,97],mps_args_begin:[2,12,93,30,10,48,96,4,34,111,36,91,37,46,38,103],dialect:20,moher:40,replac:[70,28,59,76,10,94,20,48,61,85,15,34,52,45,11,46],individu:[105,73,23,8,62,90,64],continu:[1,73,75,79,81,83,86,88,23,32,9,34,38,39,66,14,43,64,107,20,42,48],lookasid:[84,86,75],dramat:[57,69],"0x00000001003f9b70":21,redistribut:[7,97],replay:[64,58,97],"0x00000001003f9bc8":21,significantli:[54,39,59,23,107,22],poolreadi:8,reassign:85,operand:[53,21],happen:[73,77,78,85,88,102,54,28,33,34,11,98,39,59,13,10,14,61,16,45,46,21,113,48],"0000178ea03acf6d":64,dispos:[46,20],lesson:57,conting:66,shown:[21,83,108,86,22,34,17,102],abcdefghijklmnopqrstuvwxyz:[3,95],jackson:[112,40],space:[102,70,72,73,74,75,76,77,78,79,81,84,86,3,88,90,25,91,53,54,55,28,57,8,64,32,33,34,35,11,38,39,40,13,97,14,43,61,15,16,44,111,17,103,105,47,2,87,20,93,21,100,66,51,48,67],profit:[7,97],protocolsomeclassguardian:45,rankfin:53,mps_cached_count:16,spacesig:3,"0x7fff5fbff174":21,profil:[21,40,106,57,93,86,17,11],underwrit:[61,2],toolchain:[6,106],rational:[77,53,67,58,60],mps_arch_i4:106,mps_alloc_pattern_t:62,mps_arch_i6:106,mps_arena_expos:38,correct:[1,73,78,85,86,51,45,28,56,10,8,58,32,34,36,13,42,102,46,19,106,108,66],mps_arch_i3:[67,106],undead:[65,72,79],some_pool_class:52,"goto":[45,33,23],newsiz:66,thirdli:[8,20],freeblockstruct:85,million:[57,48],seventh:48,argv:[99,21,3],mps_key_mvt_frag_limit:[93,37],mps_message_t:[0,108,47,34],california:40,lab:40,carl:40,org:[6,20],"byte":[69,73,74,23,78,80,83,84,65,86,87,2,25,91,53,28,75,93,8,97,38,99,41,42,61,15,16,64,103,107,20,102,66,111,48],argc:[99,21],sigxfsz:[21,113],boehm:[69,39,99,73,74,40,81,108,20,112],care:[102,70,28,59,75,53,24,99,33,34,45,46],mps_key_min_s:[93,52,37],reusabl:45,kaufmann:40,punc:3,wai:[102,23,78,81,83,85,86,88,90,25,6,53,54,28,7,29,8,94,95,32,33,10,11,38,39,99,59,13,34,14,61,15,101,45,97,105,41,56,107,20,108,21,62,48,67,49],mps_word_shift:[67,23,106],badli:[83,107,86,14,10],prescrib:87,frequenc:[32,64,16],synchron:[0,39,72,73,74,40,86,85,75,87,16,102,88],mps_size_t:[111,91,103],refus:[8,38],unavoid:28,recov:[39,62],thing:[88,45,28,93,8,9,33,11,38,39,59,40,14,100,61,15,16,53,105,19,108,110,48,67],tlb:86,place:[74,78,81,85,86,87,88,90,25,102,28,93,8,10,38,39,99,59,34,14,44,17,46,105,47,20,108,21,48,67,49],unwis:61,principl:[54,52,67,40],imposs:[25,52,24,81],frequent:[69,27,48,59,39,30,20,31,32,21,33,90,46,38],first:[0,69,73,74,23,70,77,24,79,81,83,85,22,95,2,25,26,6,91,45,27,28,75,106,57,8,64,58,31,32,33,34,35,37,78,38,98,59,40,55,10,100,43,16,111,17,46,105,47,11,107,20,102,93,21,66,87,113,48,67,49],oper:[0,1,72,73,74,23,70,24,81,69,83,84,85,86,22,88,90,6,53,54,66,28,75,7,56,93,8,58,31,32,9,33,10,78,38,98,39,99,59,12,40,13,34,14,43,61,15,16,17,82,46,97,105,19,63,106,107,20,102,21,42,87,113,48,67,101],findlast:66,suspend:[54,59,56,8,113,46],directli:[69,72,74,24,82,85,88,90,17,28,7,29,95,32,9,78,99,53,20,102,108,45,67],subrang:23,carri:[105,90,75,42,108,97,34],onc:[1,73,23,79,81,87,88,53,54,28,33,34,11,38,39,59,40,10,43,61,63,45,20,102,16],arrai:[70,71,73,74,23,79,80,81,84,22,52,28,8,34,37,99,10,16,30,53,46,47,63,20,87,113,48],resultreturn:[21,43],bufferempti:8,yourself:[48,38,49],acquisit:108,refsetempti:[24,19],act_on_range_high:23,"long":[0,1,23,63,69,83,85,87,88,90,102,54,28,75,106,93,30,32,33,34,37,38,39,59,12,40,41,66,100,16,53,105,47,21,42,48,67],symmetri:23,xci3gc:[6,64,106],fromlimit:23,ring:[27,28,59,60,8,95,22,25,73,53,24],mps_arena:38,open:[40,27,97,7,23,70,41,94,34,43,20,1,108,66,67,33,10,6,64,38,49],predefin:[48,67],size:[50,69,71,72,73,74,23,70,76,77,79,81,82,83,85,87,88,89,90,25,52,91,45,27,28,75,56,57,8,64,58,96,66,33,10,36,37,38,39,99,12,55,13,34,14,104,61,15,16,17,46,103,97,105,47,63,2,53,41,106,107,65,20,48,102,93,21,62,42,111,113,30,67,49],freeblock:85,mps_build_sc:106,given:[71,72,75,76,78,81,83,85,2,25,17,54,28,34,37,39,99,41,100,61,15,16,64,66,45,48],unlink:86,capac:[0,39,28,47,57,30,36,48,78],convent:[27,71,72,73,23,39,76,81,86,22,63,90,45,67,68],stuck:28,spars:[71,75,81,15,20,90,88],fmt:[12,30,2,96,4,10,36,46],anderson:112,seghireturn:24,typep:28,checker:61,necessarili:[73,86,48,21,45,53,17,38],draft:97,yip:[78,40],circl:20,handbook:[112,14,40],white:[44,54,28,73,19,76,8,71,81,46,83,69,86,87,33,97,35,112,11,24,74],conveni:[0,39,99,73,23,13,8,42,41,20,54,83,85,66,34,52,45,37,48],frame:[70,72,73,75,81,51,90,91,27,93,30,96,10,36,99,12,111,17,103,21,87,49,68],mps_mv_size:91,gcseg:24,mps_fmt_scan_t:[99,46,87,33,42,48],demer:[69,40],mps_res_io:13,especi:[39,72,76,66,81,61,86,22,88,33,90,67],resetrang:23,copi:[69,70,73,74,23,76,78,79,81,83,84,65,86,87,4,90,26,6,64,54,27,28,7,57,8,32,33,34,35,36,11,39,12,40,13,61,62,63,44,45,46,47,88,41,20,48,102,42,2,30,49],specifi:[0,50,73,23,70,2,81,69,85,4,90,25,52,91,64,55,28,8,94,96,10,36,37,98,39,99,12,13,34,43,61,15,16,17,46,1,103,97,47,48,108,62,66,111,30,49],ebi:40,blacklist:74,prottramp:[21,43],weak_array_t:10,enclos:[70,73,22,63],writefb:101,mostli:[23,78,79,63,51,4,52,26,6,27,28,57,8,34,36,39,12,40,13,14,61,62,30,53,47,20,21,42,87,48,49],finalpool:8,floppi:[78,74],domin:39,holder:[7,97],than:[0,69,72,73,74,23,70,76,77,78,79,80,81,83,84,85,86,22,88,90,52,53,54,28,7,57,8,64,95,66,33,10,38,39,99,59,87,13,34,14,61,15,16,111,45,46,97,105,47,19,63,2,41,107,20,102,93,21,62,42,110,51,113,48,67,49],serv:[93,8],wide:[39,28,72,47,93,30,79,20,32],amcfix:[28,11,33],gather:[69,87,74],subexpress:102,kolodn:40,"0x1003f9b98":21,balanc:[85,78,75],mpsavm:[63,48,38],were:[102,70,72,73,23,24,79,83,85,86,3,4,25,17,28,106,57,30,34,11,39,99,61,16,45,46,105,47,19,20,66,51,113,48],posit:[98,99,105,75,23,80,24,34,64,63,46,42,52,53,48],server:[78,40,20],seri:[83,70,17,72,32],testnod:85,analysi:[0,54,99,59,23,40,76,30,64,58,48,75,88,44,17,11,46,67],sai:[54,39,53,41,78,90,14,95,102,86,87,88,34,52,6,46],cbss:66,obj_empti:[21,48],anywher:39,danger:[13,45,107],subroutin:73,"1992a":87,nickola:40,medium:[28,58],"20g":21,deliv:[20,29],ravenbrook:[1,7,109,97,52,6,112,67],fp_pattern:61,repack:40,sat:[17,21],buffercr:[59,97],engin:[54,101,20],techniqu:[1,69,72,73,74,75,77,78,79,83,84,87,88,54,27,57,8,95,31,32,33,39,40,14,45,107,20,42],longword:[72,79],scanstat:[35,28,53],destroi:[72,23,76,24,81,85,87,88,2,25,102,28,93,95,97,11,38,98,39,99,100,15,16,44,17,46,47,20,48],note:[0,69,72,73,74,23,70,76,24,81,83,84,85,86,3,88,89,25,6,53,51,28,75,106,57,30,64,94,58,32,66,33,34,36,11,78,38,98,39,99,12,40,60,13,101,10,61,15,16,44,111,17,46,97,105,47,63,37,41,107,20,102,93,108,62,42,22,87,113,48,67,49],ideal:[12,57,78,14,81,88,33,45],take:[102,70,73,23,79,81,86,22,97,91,17,54,55,75,93,8,64,95,96,32,9,33,34,36,37,38,98,39,99,59,12,13,10,14,61,111,16,66,45,103,105,47,63,107,20,48,108,21,42,87,30,67,49],advis:[111,97,67,7,66],"0x000000010001287d":21,interior:[72,73,74,81,42],unfix:[68,42],noth:[54,28,47,19,56,53,2,43,84,67,34,111,17,91,48,38,49],mutatorfaultcontext:43,wirf:40,begin:[70,73,23,77,81,83,85,86,87,25,6,54,28,29,97,38,13,61,63,102,107,110,22,3,67],printer:[17,20],importantli:67,norman:[76,40],job001809:28,normal:[0,71,73,63,85,87,88,90,64,55,28,56,93,32,9,33,10,38,34,61,53,105,102,17,108,45,67],buffer:[50,74,23,24,81,84,86,87,64,55,28,75,8,58,97,59,12,41,101,53,102,17,111,113],friedman:[76,40],enter:[28,75,21,87,90,64],compress:[87,73],clearer:53,eclect:20,poollo:23,egc:[6,106],abut:24,wire:[78,90],messagesig:95,abus:22,tract:[50,8,58,33,11,24],pair:[66,72,74,23,106,34,85,21,42,6,48],neatli:39,mortem:64,dylan_skip:11,paulo:40,mps_alloc_pattern_ramp:[28,62],spector:112,perceiv:[0,20],synonym:[73,74,23,20,87,90],proud:17,drive:64,quantiti:[69,39,28,74,78,80,82,86,90,25],multiprocessor:[59,40],runtim:[40,33,20,48],pattern:[27,72,47,75,39,107,79,14,105,70,61,85,62,51,88,2,102,68],amcreclaim:[28,11],fixemerg:28,senior:112,mrg:[25,35,100],review:[67,40,33,48],gracefulli:[76,11],uncontrol:[41,17],messageempti:[25,100],mps_amc_appli:30,show:[39,57,8,32,21,34,17,11,45,67],mps_mvff_free_siz:[55,111],maint:67,infant:[69,81,40],merit:61,freetreestruct:85,concurr:[1,70,59,74,40,83,108,88,44,90,73,45,11],map:[70,73,74,75,76,78,79,84,85,3,88,90,27,28,23,8,58,34,24,38,39,41,61,15,65,87,67],overlarg:16,permiss:[102,64,46,20],hack:[28,64,23],threshold:[8,28],obj_delet:[34,105,10],precondit:25,cbschangesizemethod:66,ground:88,slot:[70,55,10,52,45,102],onli:[50,1,71,72,73,74,23,76,77,24,79,81,69,83,85,86,51,88,90,25,52,45,54,66,28,7,29,93,8,64,94,96,32,9,33,10,36,37,78,38,98,39,99,59,12,13,101,34,100,43,61,15,16,44,17,82,46,97,105,19,63,2,53,41,56,107,65,20,48,102,108,21,62,42,87,113,30,67,49],slow:[0,39,79,86,20,61,21,87,16,33,11,38],slop:61,fenc:[61,70],lua:20,"0x7fff5fbfef2c":21,transact:[25,40],activ:[50,39,72,59,75,56,8,78,20,54,70,65,87,81,44,73,79,48,38],behind:[54,17,73,4,34],tobt:23,z80:23,sparecommitlimit:8,black:[54,69,28,73,74,76,24,81,83,86,87,58,97,46],cached_count:16,btfindshort:23,petrank:40,analys:47,wilei:40,overwritten:[76,28,21,32,88],moreau:40,nearli:[28,19,78,81,95,33,102,48],variou:[27,99,23,29,53,39,66,64,78,20,31,61,15,95,33,42,25,6,11,48,67],get:[0,73,23,77,84,22,90,25,52,6,102,54,28,57,30,95,33,10,11,38,39,13,34,100,61,16,111,45,104,47,19,107,21,42,110,87,48,67],genera:40,mung:67,repr:44,clang:[1,6,21,106],secondari:[67,40],cannot:[0,71,72,73,23,24,81,82,83,85,86,87,88,25,53,54,28,75,8,32,66,34,36,38,39,13,10,14,43,61,62,63,44,45,107,65,102,108,42,48,67,49],murali:40,freestor:[70,82],eventrep:97,mps_io_writ:41,tospac:[70,87,86,73,77],gen:[28,67],requir:[0,69,72,73,74,23,70,76,77,78,2,81,83,85,86,3,4,90,25,91,45,28,75,29,8,64,58,96,32,66,34,36,11,38,39,99,59,12,60,13,10,14,61,101,111,17,46,103,97,105,88,53,37,41,56,107,20,48,108,109,100,42,110,22,87,113,30,67,49],ssb:87,reveal:[21,75,34],bulk:[79,11],discontigu:75,arenaclamp:8,seldom:84,protan:24,borrow:61,yield:[111,24,64,90],hash_t:[105,34],joker:17,tillotson:112,"0x7fff5fbfef28":21,roger:40,scott:40,where:[102,70,71,72,73,23,77,24,79,81,84,85,86,22,88,90,6,17,66,28,75,29,8,64,32,9,33,10,78,38,39,99,59,60,100,34,14,61,16,45,46,105,47,63,53,56,107,21,42,87,113,48,67],mps_key_mvff_first_fit:[55,37,111],summari:[54,19,8,97,58,33,66,64,11,24],kernel:[15,88],ams_alloc:13,lasttractbas:8,mps_formatted_objects_stepper_t:[87,46],closurep:[85,66],symtab_root:[48,34],fork:73,zaphod:23,segsummari:19,tape:74,foor:22,lnc:40,concern:[54,39,76,78,14,86,21,88,66,11,48],infinit:78,checkl:9,detect:[102,72,75,24,79,81,83,85,88,2,25,45,28,94,95,34,38,39,99,60,10,14,61,16,64,108,21,66,48,67,49],"0x1003cb958":21,splaytreesearch:85,mps_sac_flush:16,mps_telemetry_filenam:[41,17],checkd:[9,95],updatenod:85,enumer:[53,87,66],"0x000000010007b14a":21,label:[17,86,63,68],hist:66,palimpsest:90,enough:[70,74,75,79,85,17,55,28,23,93,41,38,39,13,14,15,16,53,46,19,107,21,66,48],between:[0,69,71,72,73,70,24,81,82,83,84,85,87,88,90,6,64,28,106,93,8,95,32,33,34,37,78,38,39,59,40,41,66,14,43,61,16,45,97,47,63,11,48,102,108,42,30,67],"import":[102,23,63,86,87,88,17,28,57,32,9,33,34,39,99,66,15,81,53,20,42,48,67],checku:[9,95],across:[55,73,81,66,111,6,67],dybvig:[88,40],assumpt:[28,30,14,61,108,10,25,45,53],bufferclass:55,amort:[85,66],mps_arena_extend:38,mps_build_:67,comp:20,tarditi:40,style:[45,97,23,20,33],cheap:[69,64,72,107],blame:39,cycl:[69,70,28,73,75,57,10,20,83,86,87,58,81,90,25,11,38],sparc:[6,23,106],pieper:[112,40],spare:[70,8,14,58,87,38],inflex:[86,14],uncondition:108,shortag:[113,14],"0000178ea03f4db4":64,come:[48,23,8,66,14,78,20,46,84,72,81,24,10,17,6,38],caar:21,reaction:17,tractp:50,unrel:21,mono:20,region:[39,75,40,55,24,97,20,70,21,87,88,42,45],mps_var_df:67,contract:[8,7,97],retir:[67,60],audienc:17,saguaro:73,coucaud:40,mani:[1,70,71,72,73,74,23,78,79,81,82,84,85,3,88,90,45,54,28,75,93,95,32,33,34,38,39,99,41,14,16,17,105,107,20,102,108,21,87,112,48,67,49],emiss:64,unstructur:12,evict:73,bitset:[53,74],nettl:[88,40],bufferpool:[13,59],undocu:[113,43],color:[69,73,74,76,81,83,86,87],nodereturn:85,inspir:20,period:[39,72,32,62,87,48,38],dispatch:[28,66,20,33,34,11,48],mps_class_mv_debug:[91,37,2],duti:20,fri3gc:[6,106],exploit:[93,30,33],qin:40,anti:[24,45],newblock:85,sleator96:85,exclud:[41,6,74,23],sentinel:8,event_label:17,poll:[0,25,8,58,34],poli:45,damag:[78,7,97],ultim:8,amer:40,limitreturn:[28,23,66],coupl:[39,48],resort:34,invert:[81,23,20,90],feldt:112,invers:[69,15,23],fixabl:97,mark:[69,70,73,74,23,77,78,79,81,83,65,86,87,90,26,54,27,28,95,32,33,34,35,36,40,13,97,17,47,2,20,112,49],klauser:40,workshop:[40,106],sparecommitexceed:8,uniq:95,weak_table_:10,scannabl:[54,75,87,34,48,49],string_equalp:34,"0x0000000100002fe4":21,parser:48,mps_arena_spare_commit:[8,87,38],"000ae0397334e0a0":17,derefer:2,thousand:57,persist:[98,28,47,40,99,62,16,42,46,38],andrew:[112,40],"0x5193e559":95,catastroph:87,mps_sac_class_limit:16,amcz:[27,12,42,4,34,26,48,49],quick:[70,79,107],ironpython:20,lectur:[17,40],former:[54,70,83,88,29],those:[70,72,73,74,23,77,24,79,81,85,86,87,88,90,52,102,54,56,8,9,33,41,38,39,59,13,97,61,15,17,107,94,48],sound:[14,3,23],kathryn:40,"0x000000010000261b":21,thesi:40,"0x000000010002686d":21,mps_align_t:[75,63,111,53,37,46],postscript:[73,87,14,20,84],pedant:28,poolfre:[55,53,59,97],epdlpoolclass:45,antoni:40,thisclasscoerc:45,wasmark:35,trick:[85,48],cast:[70,76,41,63,86,101,42,45,53],invok:[39,73,75,23,24,66,64,108,46,61,85,9,42,17,11,45],sizeisalign:13,mps_pool_debug_option_:[61,37,2],"na\u00efv":[108,34],amcscan:[28,21],invoc:[73,75,63,87,66,45],mps_message_gc_not_condemned_s:47,addroffset:[53,85],findshortresetrangehigh:23,program:[0,1,72,73,74,75,70,76,78,79,81,82,83,84,69,86,51,88,90,5,6,102,7,29,57,30,94,32,33,10,36,38,98,39,99,40,13,34,14,62,16,17,46,105,47,63,2,41,107,65,20,93,108,21,42,87,113,48,67,49],advantag:[39,74,56,93,107,14,81,61,87,88,34],stdout:41,metric:[28,80],henc:[69,39,28,59,55,90,64,71,102,86,85,15,9,34,73,45,66,46,97,88],mps_scan_begin:[99,10,42,63,46,94,33,34,48],worri:[39,59,14,20,33,34,102],destin:[41,105,19,38],arenaleav:59,cluster:23,splaycomparemethod:85,cobol:[14,20],eras:20,cbsiteratelarg:66,"0x7fff5fbff830":21,mps_ss:33,nearbi:[79,21,14],smalltalk:[69,70,72,40,14,20,88],sos9sc:106,develop:[1,23,85,86,25,6,64,28,7,29,57,8,58,9,36,38,40,13,14,43,61,45,104,20,66,67,49],author:[],eventf:64,alphabet:[27,3,23,60],stepper:[99,13,30,84,87,46],lippgc:106,same:[102,70,71,72,73,74,23,24,79,63,83,84,85,3,88,90,25,45,54,51,28,75,56,93,30,64,94,95,96,66,33,34,35,36,78,38,39,99,59,40,55,13,10,61,15,16,111,17,46,103,105,47,53,41,106,65,108,62,42,22,48,67,49],trip:[28,59],binari:[70,72,59,74,7,29,41,8,56,107,58,83,85,67,33,97,17,38,101],epoch:[41,8,53],mps_arena_class_t:[75,38],pad:[70,73,76,77,90,81,3,4,2,28,30,58,96,10,36,12,34,104,61,64,46,97,21,48],pirinen:[74,40,81,83,86,87,112,67],sos8gc:106,oldnod:85,knuth:87,sticki:[79,87,40],ensuresomeclass:45,week:20,exhaust:[93,85,11,46],finish:[0,50,74,77,24,81,69,85,22,90,25,17,54,55,28,8,95,34,37,38,39,59,12,60,97,14,61,45,21,66],typesett:20,rightchild:85,mps_reg_scan_t:[99,48],nest:[73,28,62,37],assist:[87,17,21,86,81],driver:67,someon:[39,63],treadmil:[76,86,73,40],event_param:17,driven:[83,40],capabl:[102,17,87,88,20],mps_root_create_table_mask:99,mps_addr_pool:[98,38],improv:[72,23,79,84,22,88,6,28,57,30,32,41,36,11,39,12,40,13,10,61,47,107,20,93,109,111,67],extern:[70,71,72,73,74,23,81,85,87,88,90,25,52,64,54,55,58,32,97,38,39,59,100,14,45,107,108,66,111,67],immedi:[72,74,81,84,65,51,25,54,28,29,93,34,11,38,98,39,99,105,85,21,42,48],postpon:[48,34],mps_fmt_skip_t:[87,46,48],tradition:83,mps_args_end:[2,12,93,30,10,48,96,4,34,111,36,91,37,46,38,103],appropri:[72,73,74,23,24,81,85,87,88,90,45,54,55,28,75,29,93,9,34,78,38,99,97,101,64,46,107,108,48,49],moder:67,extend_bi:52,port_:[48,34],macro:[23,77,63,22,52,53,29,8,64,95,9,33,37,61,16,102,106,42,45,48,67,68],"9c000":64,attrscan:53,amcstruct:28,pronounc:72,without:[0,1,71,72,23,70,76,78,81,69,83,85,87,88,25,6,53,28,7,8,64,32,33,97,36,37,38,98,39,99,59,12,40,13,66,14,61,15,16,44,45,46,104,47,63,20,102,108,62,42,67],mann:112,temptat:[101,42],model:[69,40,20],branquart:[40,20],event3:64,commitlimit:8,table_rehash:[105,34],summer:40,gdr:97,warranti:[7,97],bufferdescrib:[59,101],printezi:40,execut:[1,71,72,73,74,23,78,2,86,22,90,75,7,56,57,33,10,59,41,97,43,15,45,29,20,113],among:[39,24,20,61],excel:85,unflush:17,rest:[28,59,48,101,64,113,46],halfwai:66,arenahigh:55,gdb:[17,21,64,38],doligez:[40,20,90],kill:39,tracequantum:[21,11],aspect:[73,29,57,106,14,87,66,11,38],touch:[13,28,105,102,77],rankexact:53,speed:[39,28,73,23,93,14,58,20,15,87,16,42,17,11,102,49],mps_build_ll:106,concentr:[39,67,29],threadderegist:59,versu:28,death:[69,93,64,40,34],autocad:69,miscellan:[39,41,31],issetrang:23,mmap:[76,78,88,67],poolclassstruct:[53,97],except:[1,74,23,24,81,83,3,4,90,25,52,28,75,7,56,8,97,78,39,99,59,66,100,61,16,44,17,46,63,107,20,42,22,113,30,67,88],littl:[54,39,28,23,8,79,14,20,61,85,16,97,78,67],desktop:87,"0x1003cbe50":21,instrument:67,setenv:6,treatment:73,exercis:[23,40,86,85,21,66],overview:[1,23,24,85,95,5,52,45,54,27,28,29,8,58,31,33,59,60,100,14,61,64,55,104,56,66,48,67],accessread:[53,43],doctorat:40,pitman:112,disrupt:40,splayfindfirst:[85,66],nielsen:40,"8kib":33,read:[0,74,23,79,63,83,86,17,88,90,25,64,54,56,8,10,38,99,59,12,41,34,100,43,61,15,53,46,20,108,21,87,113],outermost:62,amc:[27,28,47,63,13,30,58,21,62,4,33,97,26,36,11,48,49],mop:61,mov:10,vivek:40,reassembl:42,categoris:28,anchovi:66,insist:45,sobalvarro:[73,40,20],mod:67,intel:[72,74,106],rootdescrib:59,smell:85,robson:40,integ:[70,99,105,74,23,106,53,41,10,48,83,65,9,87,75,34,25,17,46,67],shrink:[93,8,74,66],benefit:[54,39,28,70,8,61,87,10,45,78],weakest:88,either:[1,73,74,23,24,79,81,83,85,87,88,25,6,54,28,7,56,93,8,32,34,35,37,78,38,98,39,99,59,100,10,14,61,15,16,53,46,97,105,63,11,107,20,108,21,66,48,67],larchant:40,output:[13,66,63,85,21,17,101,41,87,6,64,67],downward:[111,38,23],inter:[73,30,81,83,32,88,46],manag:[0,1,2,22,4,7,8,10,11,12,14,15,16,17,18,20,21,23,24,25,27,28,30,31,32,33,34,35,36,38,39,40,42,44,45,46,47,48,49,50,51,53,54,55,58,61,63,66,67,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,65,86,87,88,89,90,91,92,93,95,96,97,98,99,100,102,103,105,107,108,111,112,113],fulfil:8,arena_o:38,cbsfinish:66,free_:97,poolawl:23,"boolean":[8,63,66,45,53,64],thermodynam:40,shield_depth_width:24,legitim:42,interlock:105,accessmax:24,splayroot:[85,66],satisfactori:[28,85],journei:48,cruz:40,assert_mpsi:67,inlin:[1,39,99,105,102,75,42,81,63,66,22,16,33,34,6,11,53,67],has_reservoir_permit:16,constitut:[48,23],resfail:[53,85,66],basic:[74,24,86,87,88,90,52,54,28,8,58,34,38,39,14,61,15,44,45,20,111,48,67],slice:[54,47],arenaalign:28,poolmv2:[85,66],thereund:61,definit:[72,23,63,85,58,25,64,28,8,95,9,33,97,99,59,60,61,15,44,45,20,66,110,67],recomput:[11,38],legal:[25,37,15,11],moon:[112,40,20],pioneer:20,moor:[40,23],exit:[39,71,59,23,24,81,48,108,21,25,64,113,46],"0x00000001003f9a58":21,mps_fix2:[70,99,10,42,46,94,33,34,48],mps_fix1:[70,99,10,42,46,94,33,34,48],virtualalloc:[67,38],sus8gc:106,blocksiz:66,splaytreestruct:85,obj_pad:[46,48],immun:[73,81],nmr:28,compris:[50,23,56,8,88,64],power:[72,74,23,106,10,107,20,83,32,75,87,63,34,53],event_typ:17,sixth:48,garbag:[0,1,71,72,73,74,75,70,76,77,24,79,81,83,69,86,87,88,90,6,91,53,54,27,28,57,30,31,96,32,33,34,36,11,78,38,98,39,99,12,40,13,10,14,112,62,17,46,103,104,105,47,65,20,48,102,93,108,21,111,68,113,8,49],inspect:[23,43,81,21,67,25,5,46,38],indira:40,"0000178ea03f67b5":64,"0x00007fff9050ae2a":21,broken:[70,28,73,74,85,87,88,97,35],aquir:112,regexp:13,referr:81,s7m6mw:106,earlier:[0,87,72,22,74],rightreturn:85,acc:19,src:67,about:[0,72,73,74,23,24,79,81,83,85,86,51,88,90,25,17,54,28,75,93,30,64,94,58,32,33,34,78,38,98,39,99,59,97,14,61,101,44,45,46,47,53,65,20,102,108,109,66,113,48,67,49],mps_pf_xci3ll:106,greatli:[39,6,86,107],mps_mvt_size:93,arena_class_vm:38,joyner:[78,40],drag:40,acm:40,arenafin:100,degre:[61,63],wolf:40,stand:[83,39,28,15,32],wold:2,act:[54,73,78,97,44,90,25],johnston:[70,71,40,83,86,87,111,112],luck:[13,102,33],processor:[1,72,73,74,75,78,79,63,82,83,65,86,87,88,90,102,106,33,10,99,41,15,81,17,20,67],mps_message_type_en:[0,25,108,34],"001b":17,routin:[70,39,100,101,61],effici:[1,69,74,23,78,79,81,83,85,86,51,88,91,102,54,28,75,93,8,32,33,10,36,38,39,99,12,40,14,61,111,44,30,53,19,107,65,66,87,48],"001a":17,shaw:40,"00000001003fd000":17,wordindex:23,terminolog:[105,78,83,87,90,45,68],surviv:[54,69,28,72,47,75,78,14,20,65,33,90,25,48],dram:[72,87],fence_templ:2,btrangessam:23,cbsblocklimit:66,nikla:40,your:[1,71,84,17,6,64,57,95,41,38,39,99,13,34,62,53,104,102,108,21,42,48,49],snapout:28,stare:10,fmtdy:33,awlreclaim:11,certainli:[39,59],log:[41,64,17,66,53,6,67],unflip:100,area:[54,39,72,73,74,75,70,77,24,79,14,81,82,87,66,111,78,38],aren:[1,28,7,23,33,34,53,113,102],splaytreecheck:85,poolclassmrg:100,hex:[3,95],overwrit:[70,72,74,23,39,76,78,95,61,65,21,87,75,2,102],checkabl:8,amcsegstruct:28,start:[0,70,71,73,74,23,88,24,81,85,86,51,4,52,6,91,17,54,55,28,75,93,8,64,95,96,32,66,33,10,36,37,38,98,99,12,34,62,63,111,45,103,47,107,20,48,102,21,42,87,68,113,30,49],mps_os_li:106,"00000001003fd328":17,interfac:[0,50,72,73,74,23,70,76,77,24,100,80,81,69,84,85,86,4,5,25,26,91,45,27,28,75,56,93,8,64,58,9,33,10,35,36,37,38,98,39,99,59,12,40,60,13,101,66,14,43,61,15,16,17,88,1,103,97,105,63,52,53,41,106,107,20,48,102,108,42,110,111,113,30,67,68],low:[50,23,76,24,83,85,87,90,25,54,27,106,58,10,38,39,55,41,42,61,15,17,46,47,20,66,111,67],lot:[54,39,28,105,47,8,66,14,20,61,32,15,33,90],resum:[113,43],rightneighbour:85,strictli:[69,67,23,74],obj_skip:[21,46,48],repetit:[14,42],mps_message_gc_start_whi:[0,47],morrison:40,programmat:5,tupl:75,tomasev:40,regard:[32,72,73,78],alain:[40,20],aslr:21,amongst:105,leewai:42,allegro:20,procedur:[73,75,34,108,20,85,87,88,42,48,67,49],obj_t:[102,99,105,10,34,94,21,42,17,48],illus:[0,78,87],trickier:48,untag:10,faster:[0,39,78,14,20,69,87,16,42,53,102],notat:23,amcscannailedonc:21,table_ref:[105,34],"0000178ea03f57da":64,dirti:[72,73],sbrk:[76,87,74],possibl:[1,69,71,72,74,23,24,79,81,85,3,88,25,53,54,66,28,75,7,56,93,64,32,9,33,34,11,78,38,39,99,59,13,101,10,61,15,16,45,46,97,105,19,87,20,102,21,42,22,48,67,49],"default":[0,93,13,41,42,64,58,48,110,21,101,34,45,111,6,91,17,67,103],segtypep:28,bucket:[69,105,73,74,75,90,34,48],eq_hash:[105,34],unusu:[78,38,20],leftnod:85,manuel:40,embed:[40,29,41,66,20,110,85,81,42,25,48],deadlock:[8,79,59,108,56],powerless:1,pool_superclass:45,gone:38,addradd:[53,85],creat:[0,1,73,23,70,76,77,78,2,63,83,86,87,4,90,25,91,45,54,55,28,93,8,94,95,96,10,36,37,38,98,39,99,59,12,34,100,43,61,15,16,44,17,46,103,104,105,47,88,11,20,48,102,108,66,111,113,30,68],conundrum:48,pseudo:33,deep:9,messagetypefin:25,strongli:[69,40,90,20,83,87,88,34,111],quantum:11,intro:[50,23,24,85,25,5,64,54,55,28,29,8,9,97,35,59,43,61,15,101,53,66,45,67],decreas:[39,107,59,74,88],file:[70,78,63,82,3,88,5,6,17,7,29,32,33,34,38,39,60,41,97,64,20,108,21,87,48,67],type_str:[21,34],ecoop98:40,proport:[69,39,47,57,78,66,82,32,33,42,48],rearrang:[24,85],tv_sec:41,fill:[50,55,28,59,23,41,8,79,99,48,102,61,3,97,90,111,53,46,78],again:[54,55,105,74,23,70,41,78,90,14,85,69,102,61,32,34,45,108,48],fput:[39,101,48,41],"0x1003f9ba8":21,compel:39,nickb:11,reduct:[54,40],tight:[17,107,32,20,33],"0x00000001003fb000":21,reservoirsetlimit:50,compet:[81,38],copyright:[58,7,97],epdldebugpoolclassstruct:45,you:[0,1,70,76,63,83,69,3,88,25,6,53,54,28,7,57,30,64,94,109,96,32,66,33,34,36,11,38,98,39,99,12,87,13,10,14,61,62,16,111,17,46,105,47,37,41,102,108,21,42,51,113,48,67,49],coerceclass:45,freestand:[41,101],poor:[39,47,77,78,14,32,90,48],discours:73,resolut:[41,17],genuin:[59,39,11,48,42],registri:64,sigmod:40,config_var_df:67,sequenc:[99,73,23,53,107,8,2,64,86,21,22,42,51,45,11,46],symbol:[102,99,40,23,41,104,20,21,63,34,52,17,11,48,67,68],gnumak:6,docstr:64,lueh:40,wirth:20,string_:[21,48],briefli:[107,32,14,33],cbsfindlargest:66,peak:[48,38],nrevers:40,collectionstatslives:25,pool:[50,1,95,72,73,74,23,70,76,24,2,81,84,69,22,4,90,25,26,6,91,45,54,27,28,75,7,106,57,30,60,64,94,58,109,96,66,33,10,35,36,11,78,38,98,99,59,12,40,55,13,101,34,100,104,61,16,111,17,46,103,97,47,19,63,52,53,87,48,102,93,108,21,42,110,51,68,113,8,67,49],mps_arena_create_k:[37,48,38],reduc:[69,72,73,76,79,81,82,88,54,28,8,32,33,11,38,39,40,100,19,107,42,67],sac_o:16,circularli:87,"0x1003f9b48":21,symbol_pool:17,directori:[6,67],readership:[28,23,29,8,43,58,61,85,9,3,66,25,45,64],descript:[0,23,81,85,22,88,90,64,97,11,99,60,13,53,46,105,20,102,17,42,87,113,48],unseg:87,contraven:45,misleadingli:34,inevit:23,mimic:2,mass:78,potenti:[69,99,75,23,56,41,32,33,64,48,67],appl:[17,21,40,20,82],mps_chain_destroi:[47,48],degrad:[39,12,66],cpu:[69,39,72,106,78,79,14,6,38],scm:[57,21],represent:[69,70,105,23,40,77,8,65,81,83,84,85,86,87,88,33,66,78,38],all:[0,50,71,72,73,74,23,70,77,24,79,81,69,83,85,86,3,88,90,25,52,6,45,54,51,28,75,7,56,57,8,64,94,95,32,9,33,10,35,11,78,38,98,39,99,59,13,34,14,111,61,62,16,44,66,17,82,46,1,103,97,105,47,19,63,2,53,37,87,106,20,48,102,93,108,21,100,42,22,113,30,67,49],consider:[39,28,40,60,78,70,33,5,67],splaynoderefresh:85,metaphor:61,messi:67,mps_key_:[52,37],forbidden:43,lack:[41,78,11,20],dollar:101,io_o:41,ala:23,scalar:[75,79,84,3,25,87,46],extrapol:48,attrincr_wb:53,abil:[54,74,24,14,20,61,67],thingcheck:9,dish:87,follow:[0,50,73,23,24,81,85,86,3,88,25,45,54,55,28,7,29,8,64,109,32,66,10,37,78,39,99,59,13,34,14,62,16,111,17,46,97,63,53,11,87,56,107,20,48,102,21,42,51,30,101],perspect:[40,10],ruinou:57,resok:[23,43,85,97,53,45],abid:8,mps_ap_alloc_pattern_reset:62,accesswrit:[53,43],ron:40,tracefix:[8,97,17,19],equal:[28,73,19,40,74,53,41,83,66,6,46,38,23],discard:[0,70,28,47,66,108,62,16,34,25,73,102,46,38,49],codasyl:20,articl:48,cbsdelet:66,sml:[40,20],mvvararg:52,mps_arena_spare_commit_limit:[87,38],"10992f000":17,segclass:[55,24,45],swallow:90,neglig:[7,97],rootdestroi:59,introduc:[54,39,28,19,77,8,14,99,20,87,81,25,88],isresetrang:23,xiaohan:40,liter:73,splaytreedescrib:85,straightforward:[67,34],replic:[84,78,88,40,90],far:[54,39,23,56,76,64,14,81,21,33,34,53,48,38],mps_shift_t:53,mpm:[54,23,60,24,101,33,97,110,53],fat:67,util:[25,17,68,20,66],mpw:67,mps_class_amc:[30,37,48],verb:[78,23],mechan:[0,70,71,72,73,74,75,76,77,78,79,81,83,69,86,87,88,90,52,64,27,56,8,58,34,38,98,61,15,45,1,29,20,102,108,66,110,113],got:25,veri:[1,70,74,23,77,78,79,81,86,51,88,90,64,54,28,75,57,8,58,32,33,10,11,39,99,59,13,34,14,16,111,45,103,19,107,20,102,93,100,66,87,48,67,101],rebuild:17,condition:64,pthread_mutex_lock:56,pre:[6,28],interact:[0,39,40,23,41,78,79,14,81,32,87,34,17,107,38,68],distant:[39,21],parentnam:45,"0x0000000100005ff5":21,lisp:[69,39,28,73,75,40,78,14,20,82,83,84,86,87,81,17],rescommit_limit:[8,53],list:[0,50,71,72,73,74,23,70,24,80,84,69,86,22,88,52,64,55,28,7,56,32,109,10,37,78,38,98,39,59,40,13,97,61,16,111,17,106,107,20,102,21,66,87,48,67,68],mps_free:[1,98,12,103,93,30,102,96,16,10,111,36,91,46,78,49],arenapark:8,emul:[1,43,10],reset_mask:17,adjust:[72,76,79,85,81,61,32,86,87,97,11],mps_lib_get_stderr:41,mps_ap_alloc_pattern_begin:[62,88],stderr:[39,21,42,48,41],small:[1,69,71,73,23,77,78,79,81,85,86,87,88,26,102,54,27,28,75,57,8,58,32,33,11,38,39,59,12,66,14,61,16,64,103,47,107,20,42,48],tear:[41,48],amcbuf:28,kemeni:20,mvff:[55,27,78,2,111,66,26,91,49],lockreleaserecurs:56,finalizationref:25,inherit_class:45,mpsioan:41,ref_io:42,computation:84,ten:[57,70,17,86,73],ensuredebugclass:61,addrset:53,sync:43,past:[1,39,73,23,46,83,33,52,48,67,49],acycl:9,rate:[40,8,79,20,82,83,86,87,11,78],pressur:88,secondparamunsign:64,pass:[0,70,73,74,23,78,80,81,82,83,85,22,4,2,25,52,91,45,54,28,93,30,95,96,33,10,35,36,37,38,99,12,40,13,66,14,61,16,111,17,46,103,97,105,47,53,11,41,65,20,102,94,21,42,87,113,48,67,49],further:[0,39,28,105,73,8,65,46,99,32,33,42,25,17,102,24,38],suboptim:[47,48],mps_chain_creat:[47,48],awl:[27,72,23,10,83,94,34,26,49],mps_arena_class_vm:[37,48,38],unsuit:32,referencess:28,stood:39,sub:[50,74,23,85,66,45],richard:[40,8,95,66,52,64,112,11,53,67],clock:[0,73,41,8,95,21,87,34],diag:67,sum:[70,99,75,93,78,107,83,111,91,46,38],mps_pool_class_mv_debug:61,abl:[70,73,23,24,81,85,88,28,29,32,38,99,14,61,15,64,46,56,65,20,21,66,113,48,49],brief:33,overload:87,delet:[0,39,28,72,59,87,34,85,20,83,94,32,66,22,10,25,52,17,53,1],abbrevi:[87,79,80,34],version:[0,75,63,3,4,52,5,91,53,27,28,29,93,8,64,58,96,66,33,34,36,106,38,98,39,99,12,10,61,111,101,30,17,46,103,105,87,56,20,102,21,42,51,113,48,67],regnesentr:40,intersect:[19,66],consecut:[93,70,75],mps_build_mw:106,mps_build_mv:[67,106],runfinalizersonexit:108,"public":[69,70,71,72,73,74,75,76,77,78,79,81,83,84,65,86,87,88,90,6,39,13,63,102,20],contrast:[71,87,78,38,90],nodedescrib:85,millisecond:38,hasn:[25,69,17,11],amcgrei:[],themselv:[39,28,72,23,95,83,108,25,45,53],chunksiz:17,berkelei:[40,7],dylan_copi:11,variat:[107,32,87,78,88],sanctifi:53,sophist:[93,32,11,67],client_is_wait:38,behaviour:[102,55,28,56,13,8,66,64,108,58,84,61,85,63,42,45,17,24],modular:[13,78,61,20,39],unsurprisingli:28,procur:[7,97],box:[73,74,81,83,65,88],omiss:[52,67],solari:[6,106],excess:[52,11,20],mmsrc:19,method:[50,70,72,73,74,76,24,81,85,22,4,90,25,52,6,53,54,55,28,29,30,94,58,96,66,33,34,35,36,11,99,59,12,40,13,101,10,104,61,63,44,45,46,97,47,19,88,20,48,102,108,21,42,110,87,68,8,67,49],standard:[73,78,80,63,86,17,6,102,29,8,32,34,38,98,39,40,41,81,45,20,42,67],modifi:[70,47,23,29,24,85,20,61,32,22,81,73,87,37,8,78],pointeradd:53,valu:[0,70,71,72,73,74,23,24,79,81,83,84,85,86,22,88,90,45,66,28,75,106,8,64,95,32,9,33,10,35,37,78,38,39,99,59,13,34,16,17,46,97,105,19,63,2,53,41,65,20,102,94,21,42,87,48],serrano:40,arena:[0,50,95,73,23,88,24,2,63,84,65,22,4,90,25,52,91,45,54,27,28,75,57,8,64,58,96,33,10,36,11,78,38,98,99,59,12,55,13,34,100,61,15,16,44,111,17,46,1,103,104,105,47,53,37,48,93,108,21,66,87,113,30,68],search:[70,28,23,40,77,107,32,95,85,87,66,111,17,74],ahead:[28,73],garwick:40,fwd:[48,46,34],fstruct:48,removeadjacentrang:66,freeblockupdatenod:85,mac:[6,40,82],prior:[0,105,20,85,66,25,17],amount:[50,72,23,81,85,87,88,91,54,28,57,8,32,33,10,38,39,15,53,47,107,93,111,67],calder:40,testtre:85,sig:[59,40,24,95,110,9,3,25,52,45],pick:[45,65,40,34],action:[54,39,28,72,59,70,97,95,83,61,108,51,88,44,34,87,53,102,38],pauillac:56,mps_addr_fmt:[46,38],magnitud:[84,78,79,87],via:[50,24,2,63,85,86,88,90,25,91,17,28,7,93,30,64,96,9,41,36,11,78,38,98,39,99,59,12,13,10,14,16,45,103,97,105,20,48,102,100,66,111,113,8,101],depart:40,pin:[77,30,42,90],declin:[25,62],primit:[39,73,81,32,20,64],transit:[54,28,11],barringstruct:22,size_io:61,readili:[41,32],remap:90,ask:[54,27,28,48,73,39,100,20,31,15,16,98,46,38,49],mps_telemetry_get:17,fwd2_:48,inappropri:32,send:[83,64,109,113],mps_io_destroi:41,heurist:[76,73,20,90],demonstr:17,gratuit:23,decrement:[83,32,79,88],segmyseg:45,dangl:[54,78,72,14,2],select:[54,28,40,23,13,8,82,84,3,88,90,17,11,67,74],gudeman:[83,65,86,74,40],arch_align:110,hexadecim:[27,17,3,101,60],sparecommit:8,harlequin:[28,112,67,20,95],distinct:[70,74,29,76,106,14,81,84,85,87,33],liber:113,etc:[74,76,24,78,14,109,87,33,52,6,17,67],regist:[1,70,73,75,78,79,81,83,86,17,88,25,91,64,93,30,94,96,33,34,36,38,99,12,10,42,100,111,53,103,97,20,102,108,66,87,49,113,48,67,68],supposedli:75,coverag:23,workstat:[81,20],rhel:1,azaguri:[73,40],taken:[28,47,8,14,86,32,9,87,34,53,24,38],zorn:[39,73,74,40,20,112],minor:[0,64],more:[0,1,73,74,23,70,76,77,24,79,81,69,83,84,85,86,22,4,90,25,6,45,54,55,28,75,7,56,93,8,64,94,31,32,33,10,11,78,38,98,39,99,59,40,87,13,101,34,14,61,15,16,44,111,17,46,97,105,63,53,37,41,65,20,48,102,108,21,62,66,110,51,113,30,67,88],mps_reserv:[13,63,48,61,21,88,34,102,46],flat:[33,20],mellon:40,desir:[50,39,59,74,61,87,52,11],mps_alloc_dbg_v:61,hundr:[57,86,73],hyperspec:[73,20],brisl:[66,23,29],mps_sac_creat:[87,16],flag:[28,72,100,32,64,38],keystruct:52,reservoirensureful:50,stick:79,particular:[0,69,73,23,70,76,78,79,81,85,86,87,88,90,25,64,28,75,7,56,93,8,32,33,34,11,38,39,66,61,15,63,17,46,97,105,20,102,62,42,112,30,67],known:[50,69,71,72,73,74,75,70,76,77,24,79,80,81,82,83,84,85,86,3,88,90,45,28,7,93,8,92,32,34,11,78,39,59,97,14,63,53,1,105,87,107,65,20,102,108,22,113,48],splaytesttreemethod:85,cach:[72,73,23,24,79,82,83,85,86,87,88,91,27,75,93,8,58,96,32,33,10,36,11,78,98,12,40,14,16,103,111,49,30,68],mps_key_mean_s:[55,93,111,52,91,37],canterburi:40,placehold:[110,28,48],none:[54,105,23,13,8,46,102,85,67,10,17,37,45,38,49],mainli:[87,14,58,20],mps_class_mvff:[55,37,111],methodolog:40,hour:95,blah:28,damien:40,outlin:66,resresourc:[53,15],dev:[6,88],histori:[40,8,97,58,20,66,17,78],amcinit:28,rootstruct:53,remain:[102,70,73,24,83,86,87,90,64,54,28,32,34,38,12,97,53,107,17,108,66,48,67],sudden:64,den:[83,39,86,40],learn:[1,39,20],abandon:81,motiv:[15,75,20],btfindresrangehigh:23,dee:72,def:[28,23,8,110,85,15,22,44,66,25,53,24,67],stubborn:21,traceback:64,rootvar:53,bogu:[25,35],useabl:8,scan:[1,69,71,72,73,74,23,70,88,24,79,81,84,86,87,4,90,25,91,53,54,27,28,75,57,30,64,94,58,96,32,33,10,36,11,38,99,59,12,40,60,13,34,104,61,63,44,17,46,103,97,19,107,102,93,108,21,42,111,68,113,48,49],rodriguez:40,registr:[73,90,58,34,64,113,68],share:[73,76,78,84,86,17,6,45,56,8,58,32,34,24,38,39,59,40,14,61,64,20,21,42,87,113],templat:[61,2],pessim:93,splaysplai:85,prehistori:8,unreli:[39,14],"0x0000000100001947":21,partner:20,phrase:84,struggl:21,tracereclaim:11,resmemori:[50,53,15,66],condemn:[0,54,28,47,19,70,44,86,58,83,35,69,21,87,81,33,34,25,73,97,11],uncheck:[9,22],huge:[39,79,87,82],cours:[69,19,41,8,46,102,48,38],goal:109,awkward:10,divid:[69,64,71,73,74,23,70,41,78,107,14,83,86,32,75,87,53,48],rather:[69,70,72,73,23,76,79,80,63,85,52,102,54,28,93,8,39,13,81,17,20,21,48],anoth:[0,69,71,73,74,23,70,76,24,81,82,85,86,87,88,90,52,45,54,28,32,66,10,11,38,98,39,99,59,34,14,62,16,53,105,47,19,63,107,20,102,108,21,42,113,48,101],comfort:57,nwper96:40,commonli:[54,70,72,74,75,13,78,79,82,83,84,87,90],rapport:40,narrowli:69,daconta:[40,20],heck:40,compactifi:[73,40],eventdescrib:64,reject:[39,42],strong:[54,23,20,83,108,86,87,81,33,34,52,88],fencepost:[70,72,76,13,61,2,110],mps_fmt_create_auto_head:46,isn:[39,73,24,97,61,32,21,62,33,34,53,11,67],survivor:[28,47,30],arenaseri:8,resourc:[0,70,75,76,78,81,82,86,51,97,25,6,45,93,41,38,39,13,34,14,53,46,108,66,67],referenc:[69,70,72,73,75,77,78,79,84,85,87,90,102,28,30,96,32,9,10,36,11,12,53,108,21,48],algebra:[84,87,75],stroustrup:[39,20],mps_fmt_copy_t:46,blacken:[],minimum:[70,28,73,23,93,66,61,85,88,33,90,111,67],reflect:[74,40],config_var:67,okai:[25,35,28,53,58],"2fe1b0":64,type_t:[102,105,48,34],"__kill":[17,21],undergradu:20,rovner:40,varianc:46,associ:[0,50,75,78,80,81,83,85,86,102,28,56,8,34,24,39,59,97,16,17,105,65,20,108,66,67],unreserv:97,cmpf:34,circumst:[98,108,105,73,76,11,78,85,32,66,111,37,48,38],"short":[54,28,79,23,57,101,66,84,85,87,16,33,90,53,97,88],addr_method:37,mps_key_extend_bi:[55,111,52,91,37,103],confus:[75,87,101,25,53,48],"0x1003f9b58":21,mpseventtxt:17,ambigu:[71,73,75,78,65,87,88,90,102,54,28,8,96,33,34,35,36,11,38,99,40,10,30,53,108,42,49,48,68],mislead:28,callback:[85,58,66],splaytreefirst:85,chiefli:69,parti:67,leroi:[40,90],issubclasspoli:45,began:17,target_check_deep:9,rotat:[77,85],reservoir:[50,27,24,58,61,17],poolinitmf:64,root_o:99,soon:[54,99,72,73,44,90,108,81,48,32,33,42,6,46,38],mps_lib_memset:[41,53],amcbufclass:28,reachabl:[69,70,73,74,75,78,79,81,83,65,86,87,88,90,30,96,32,10,36,38,39,99,12,40,34,14,102,97,20,108,42,48],cook:40,scientist:20,through:[71,73,23,81,83,17,64,54,27,28,8,33,97,35,11,38,60,42,61,15,16,53,20,108,66,45,48,67],cbsalign:66,poolinitmv:64,hierarchi:[73,24,79,82,83,87,88,90,45,78],coerceinst:45,suffer:[39,79,70],kistruck:[112,11],tracescansegr:21,realiz:48,paramet:[102,73,23,76,24,81,85,17,97,52,45,28,93,30,64,96,41,36,11,99,12,60,13,10,43,61,15,16,53,46,63,20,66,111,113,48,67],"0x1003f9b70":21,typedef:[24,63,85,86,22,2,25,52,45,8,95,34,37,10,16,102,46,105,47,66,48,67],make_bucket:34,nhc:40,"0x1003f9b78":21,fri4gc:106,mps_pool_class_epdr_debug:61,late:[98,78,34],harmless:[61,62],classofpoli:45,pend:[25,97,66],rapidli:[57,20],stephen:[112,40],tractstruct:8,might:[69,70,72,73,23,76,77,24,81,83,84,85,87,88,90,25,52,17,54,28,57,94,32,66,33,10,37,78,38,98,39,99,13,101,34,61,16,45,46,105,47,19,63,53,11,41,107,102,108,21,42,113,48,67,49],mps_rank_exact:[71,10,99,96,87,88,34,48],mps_key_t:[52,37],finer:[24,59,88],wouldn:[32,14,34],good:[1,69,74,23,79,85,3,17,54,7,57,33,97,11,38,99,41,102,107,108,110,87,48],"return":[0,50,73,23,70,24,100,81,85,86,51,4,25,52,91,45,55,75,56,57,8,94,96,32,9,33,10,36,11,78,38,98,39,99,111,59,12,13,34,14,43,15,16,66,17,46,1,103,97,105,47,63,53,37,41,107,48,102,93,108,21,62,42,87,113,30,88],amelior:61,mps_ap_t:[75,10,96,62,51,34,102,48],segclassmixinnosplitmerg:24,timestamp:[17,64],pollut:[54,11],largest:[75,106,83,85,16,66],entry_interpret:21,inria:[40,56],symbol_t:102,framework:[54,27,58,40,20],cet:67,mps_rank_ambig:[99,87,48,75,88],arenaalloc:8,compound:[39,73],abi:[67,106],arbitr:78,detach:[28,97],complain:61,bigger:[57,73,46,23],feet:38,document:[1,23,76,24,63,85,86,3,95,25,5,6,53,54,51,28,7,29,8,64,58,9,33,97,37,78,38,98,39,40,60,13,61,62,101,45,11,87,20,102,66,22,113,67],job001658:11,jun:[17,21],weak_buckets_ap:34,osarct:[6,106],reinitialis:59,refresh:[85,72,87,66],mysteri:[39,72,20],easili:[1,105,75,7,79,20,61,32,53],average_s:[111,91],ecru:[76,71],tracescan:[19,97],type_pad:[21,48],"12th":40,found:[50,74,23,90,85,22,2,102,55,57,95,33,34,11,98,39,99,97,14,61,16,111,17,46,105,66,110,87,48,67],difficult:[39,72,75,70,78,108,20,32,21,95],out:[1,70,72,73,23,76,77,24,79,81,82,84,85,86,51,97,90,25,53,54,55,28,75,7,8,64,66,33,10,35,78,38,39,13,34,14,61,16,44,17,46,105,47,19,63,2,20,102,108,21,42,87,48,67],mps_telemetry_label:17,clamp:[8,73,65,38,90],leaf_pool:34,interleav:[1,70,78,73,4],"0x7fff5fbff7a0":21,weight:[72,23,40,83,32,88,74],"0x0000000100074106":21,arenaread:100,hard:[54,39,28,74,78,14,99,95,32,21,3,88,87,102,48],idea:[54,59,87,64,20,61,108,15,3,58,34,73,17,11,45],ifip:40,realli:[50,39,28,98,70,8,54,61,85,42,24],heavi:[39,64],linkag:67,undesign:54,cbsfinddeletelow:66,expect:[69,23,79,85,90,25,54,28,75,29,57,97,38,39,99,59,43,62,16,53,46,47,19,56,20,93,21,110,48,101],stabl:[93,40],mps_stack_scan_ambig:[102,99,48,88],longjmp:46,operation:83,beyond:[99,20,38,33,6,46,67],todo:34,event:[0,39,48,7,105,13,41,64,14,58,46,86,108,21,97,34,6,66,17,38,68],"0x00000001003f9c90":21,"000000019ef60010":101,ftp:6,architectur:[50,73,74,75,79,81,82,83,65,86,87,88,89,90,6,17,54,29,93,8,58,10,35,11,99,59,40,100,61,15,64,106,102,110,111,48,67],massiv:28,safeti:[27,105,59,56,58,113,68],uncollect:32,robert:40,mnemon:[53,79,87],publish:[69,109,67],research:[14,40,20],handl:[0,71,78,63,82,83,85,51,88,90,25,52,102,54,28,56,94,58,96,33,10,99,59,41,34,14,43,61,16,53,46,19,20,108,21,42,87,113,67,68],leftneighbour:85,bibop:[88,33,20,74],mps_arena_cr:[8,15,38],fmt_ah:46,arenareleas:8,cbsiteratemethod:66,benjamin:[39,112,40],difficulti:[0,90],type_pad1:[21,48],mps_lib_get_eof:41,belief:55,uncommit:[28,38],advanc:[27,104,74,40,39,77,10,14,20,34],mmu:[84,78,90],team:67,differ:[1,71,74,23,78,81,83,84,86,22,25,5,6,64,54,28,7,57,95,33,34,11,38,39,40,13,66,14,43,61,16,111,53,46,105,47,63,87,107,93,21,42,3,48,67,49],pair_:[21,48,42],controlpoolstruct:8,junction:77,mps_ap_creat:[12,93,30,96,10,111,36,102],reason:[102,23,81,85,87,88,90,53,55,28,75,7,8,33,10,38,39,99,59,13,66,101,44,64,46,97,19,41,107,20,108,42,111,49],base:[50,72,74,23,24,79,81,82,85,86,87,88,6,17,54,28,75,106,8,64,96,66,33,10,36,37,38,99,12,40,101,34,43,63,45,46,97,105,11,20,48,94,21,42,111,30,67,49],isymtab:48,believ:[85,72,86],suddenli:17,dirk:40,classnamestruct:45,canon:45,earliest:20,mps_alloc:[98,12,103,96,88,13,30,10,63,48,102,61,93,16,90,111,36,91,46,78,49],lag:40,basi:[32,64,23],mps_label_t:[17,63],director:112,kept:[54,28,72,73,56,13,34,100,94,32,66,88,42,107,48,67],mpsc:63,thread:[1,73,74,75,78,79,83,85,86,88,45,54,27,56,8,58,33,38,39,99,59,12,40,16,53,46,104,105,102,21,113,48,67,68],mpsa:63,worth:[39,28,87],exponenti:69,"_mps_fix2":33,mpsi:[13,21],mymp:6,perhap:[54,23,13,78,21,44,34,38],mps_ap:21,perman:[88,81],cbsstruct:66,lifetim:[69,71,72,40,76,77,30,79,14,20,82,93,87,81,33,34,48,78,88],entry_string_append:21,hasseg:8,simultan:[1,39,34,73,90],major:[54,39,72,73,7,30,107,20,61,69,97,64,78,38],dont:21,obviou:[28,23,8,61,85,53,64],upper:[93,63,67],feel:[61,48],exchang:109,misc:24,number:[0,69,72,73,74,23,70,76,78,79,83,84,65,86,3,4,90,25,52,6,45,28,75,56,57,8,64,95,33,34,36,11,38,39,99,12,40,87,13,101,66,100,16,111,17,97,47,53,41,107,20,93,21,42,22,48,67,88],evolut:59,globals_scan:48,mps_res_fail:[13,108,62,42],pop:[72,75,96,87,51,103],mps_message_typ:[0,25],done:[0,69,73,74,78,85,22,90,25,6,54,28,95,34,11,38,39,59,41,100,61,17,105,47,20,21,66,87,48],uninterest:[33,66],stdlib:39,indistinguish:28,implementor:[69,45],miss:[54,21,40,8,72,81,82,83,86,85,15,22,87,78],"000ae03973352375":17,fanci:61,gpl:7,guess:21,restor:[0,73,40,56,24,43,20,85,87,42,48,38],fuller:14,vararg:[52,101,61,60],mps_t_ulongest:[53,67,106],gpf:69,luiz:20,least:[0,70,73,23,77,78,63,83,85,86,87,90,17,55,28,75,8,33,97,11,38,39,42,61,15,16,64,103,105,47,102,66,48],mps_message_queue_typ:[0,25,78,34],checkpoint:29,paint:81,stori:[8,48],toi:[0,99,105,57,34,108,21,42,17,48],reclam:[83,108,40],statement:[63,22,102,11,64,67],relink:86,cornel:40,reentranc:59,scheme:[0,69,73,74,75,81,83,3,88,57,34,99,40,14,17,104,105,20,108,21,42,87,48,68],supernamestruct:45,store:[0,50,71,72,73,74,23,70,76,24,79,81,82,83,84,85,86,87,88,90,25,53,54,55,28,75,56,8,64,32,33,34,11,78,38,39,99,40,100,66,14,61,15,16,45,46,1,103,63,107,20,102,108,42,113,48,49],eql:84,win32:56,lii3gc:[6,106],alleg:42,assign:[102,39,75,23,107,78,64,20,83,86,16,53,17],parc:40,option:[28,8,97,64,63,48,61,111,87,24,66,52,36,91,37,17,38],table_delet:34,mps_thread_reg:[99,86,113,48],"0x7":42,similarli:[42,16,23,34],park:[98,99,73,8,65,90,30,38],pari:40,illeg:[2,95,15,51,97,11],part:[69,70,72,73,74,23,78,79,63,83,84,85,86,87,88,90,25,45,54,28,75,7,8,64,32,33,10,38,39,99,13,97,14,43,61,44,53,2,41,107,65,20,102,21,66,112,48,67],"0x1003fe820":21,mps_lib_fil:[41,85,101,66],fall:[69,105,59,40,93,13,20,32,16,53,64,88],induc:20,mps_message_pol:[0,25,78],ncc:40,eventu:[0,54,14,20,61,25],std:23,kind:[0,70,73,63,76,13,78,42,20,83,61,21,87,67,33,90,77,64,48,38,49],reservoircheck:50,grep:17,doubli:[72,10,83,86,22,34,87,102,68],mipspro:106,cyclic:[1,39,72,73,40,20,88],remot:[30,96,88,10,36,49],remov:[0,72,63,85,22,88,90,25,52,54,28,8,32,97,37,99,59,60,66,61,46,11,20,42,87,48],dant:40,prot_bar:67,niklau:20,ringstruct:[25,24,22,53,95],aver:[100,95,61,85,66,52,64,11],nevertheless:3,reus:[54,98,72,93,107,8,14,20,32,21,87,88,45,24],architect:112,mps_message_:95,sigcheck:13,corrupt:[39,72,75,13,95,61,21,2,17,64],arrang:[1,54,74,70,24,43,85,15,22,33,97,67],stale:[1,105,73,8,90,34,35,38,68],unalign:[99,74,75,78,65,97,111,102],grei:[54,69,28,24,58,101,44,97,11],randomli:14,cleaner:[69,14],"_set_":[],comput:[54,39,28,105,73,19,40,8,34,14,85,20,32,21,87,88,90,78,74],"0b00":33,deleg:42,grarup:40,defect:[22,95,60],packag:[6,72,88,20],overran:21,"000ae03973336e3c":17,perri:40,succeed:[53,13,24,48],maximum_s:[93,91],dedic:[113,20],justifi:[28,75,23,66],commonplac:74,imagin:[61,17,28],wilson:[69,39,71,73,74,40,70,77,79,14,81,83,75,87,107],xref:54,relationship:[84,24,20,61,9,45],equival:[69,70,28,53,30,66,107,42,45,6,37,24],reservoirstruct:50,ancillari:39,odd:73,lin:40,sos8gp:106,mps_res_param:[13,16],align_up:48,accessor:[25,45,59,66],count_max:23,build:[1,27,104,73,60,62,64,20,48,84,21,87,33,6,17,67],word_act:23,command:[0,13,20,21,95,6,17,67],analogu:86,brace:45,ecmascript:20,splai:[27,85,66,58,61],mktemp:17,pipelin:87,distribut:[1,69,72,47,7,40,57,79,20,83,32,81,97,88],exec:101,unsur:[65,75],kai:40,previou:[77,70,19,56,13,97,107,108,21,22,33,90,87,17,11],reach:[0,70,72,73,78,90,14,85,32,66,88,34,110,53,11],mixtur:[70,10,42,20,63,34,11],capitalis:3,plai:[28,40],amcnailboard:28,plan:[64,85,40,49],moss:[112,40,90],ringinit:[22,95],alpha:[6,89,106],splat:[10,34,94,83,108,87,2],getrusag:41,appear:[1,73,74,24,81,86,3,90,45,28,95,34,11,78,39,100,63,17,105,21,66,48,67],demand:[29,88,90],bug:[1,39,107,72,70,13,41,67,14,20,21,81,95,90,17,102,38],filesystem:[95,67],weak_table_t:10,reg_scan:99,init:[50,55,28,59,60,8,97,95,61,85,22,101,66,25,45,102],recherch:40,destruct:[39,24,58,44,97],dereferenc:[53,102,20],quadword:[72,89],ext:67,getter:8,abnorm:[17,14],clean:[45,72,20,90],resembl:[72,73,74,20,2],mpscawl:10,addr_io:61,blend:20,microsoft:[1,73,106,20,6,67],awesom:28,mysegclass:45,"9c0d8":64,think:[102,99,20,61,32,16,95,53,17],"0x000000010000d75f":21,job001811:28,carefulli:[39,77,100,86,90,67],pooltriv:[110,97],xcode:[6,67],memorandum:40,lispwork:20,"4kib":33,faq:[39,20],mps_class_mvt:[93,37],particularli:[39,72,73,23,14,65,81,85,86,90,45],cdr:[21,48,42],dimension:[87,20],fine:[78,21,59,108],find:[0,1,72,73,74,23,70,76,79,69,85,86,3,88,25,6,17,54,28,8,32,66,33,34,11,38,39,99,40,60,10,61,45,105,47,107,42,87,48,49],reservoirpermit:45,impact:[64,11,67],buckets_fmt_:34,dosser:40,coerc:45,pretti:33,wish:[24,28,85,56],thoma:40,writer:20,solut:[39,71,64,8,66,14,20,61,32,58,90,6,48],"0x0000000100008ca2":21,protset:43,peculiar:88,ambig:[54,28],rangessam:23,tag_mask:99,mps_message_finalization_ref:[25,108,100,34],segment:[50,69,74,23,24,79,81,83,17,88,90,91,64,54,27,28,75,8,58,33,97,11,78,55,43,61,15,111,53,103,19,45,87],mps_fmt_create_:46,unobtrus:[39,40],iec:[63,41,73,40,20],pooldebugmixinstruct:61,sure:[39,71,61,21,87,42,48,67],writef:[27,53,85,58,101],boulder:40,remedi:90,hit:[54,74,78,79,82,21,88,90,113,19],unus:[39,73,74,23,75,78,107,85,21,87,67,44,2,46,38],caus:[70,74,76,77,24,2,81,84,85,86,87,88,90,25,54,28,7,93,8,32,33,34,78,38,98,39,59,40,13,97,14,43,62,16,108,21,66,110,111,48,68],"__file__":61,express:[23,78,63,6,53,55,75,7,106,9,97,11,40,34,81,102,107,20,21,42,45,67],protcanstepinstruct:43,cheaper:[39,74,70,76,78,85],deliber:[78,48],nativ:[88,106],mainten:[45,67,66],fastest:[87,102,73,42],liabl:[17,7,97],cgi:20,cbsfindfirst:66,findlongresetrangehigh:23,obligatori:45,morgan:40,mps_build_lc:106,arenawrit:100,whenev:[28,105,23,29,76,85,20,83,32,9,53,99,48],someclassstruct:45,"0000178ea03c332c":64,"0x1003f9b68":21,"0x100001b80":21,baker:[73,74,40,76,79,20,84,86],common:[70,71,72,73,74,75,77,78,79,81,83,85,86,3,90,52,102,28,8,31,32,39,13,66,14,45,46,107,20,94,21,42,87,113,48,68],mps_chain_t:[47,30,4,36,37,48],fuzzi:14,unmaintain:20,"0x0000000100068050":21,hinder:[59,11],"0x1234":64,crl:40,tr99:40,"0x1003f9b88":21,set:[50,69,71,73,74,23,70,76,24,79,81,83,84,85,86,51,88,52,6,45,54,55,28,75,56,57,8,64,58,32,33,34,35,11,78,38,39,99,40,41,66,43,16,44,17,46,97,105,47,19,53,20,102,93,21,42,87,67,101],art:[78,20],fputc:[41,101],btcreat:23,sep:67,"0x1003f9b80":21,extant:96,vinc:40,"00000001078c85b8":17,mutabl:[78,59,81,56],seg:[54,55,28,53,13,8,64,21,101,45,17,24],isfinalpool:8,see:[0,2,3,4,5,6,8,9,10,11,12,13,15,17,19,20,21,22,23,24,25,28,29,30,32,33,34,36,37,38,39,41,42,44,45,46,47,48,49,1,51,53,54,55,56,57,59,61,63,64,65,66,67,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,105,107,108,110,111,113],sed:95,argstruct:52,arg:[24,4,2,52,91,45,55,93,30,96,10,36,37,38,98,12,34,102,46,103,111,48],reserv:[73,74,75,76,78,63,84,65,87,88,102,28,7,93,97,11,38,39,99,59,13,15,16,53,48],harri:40,"1003fd000":17,arm:74,analog:[41,78,38],barn:[112,40],"_win32":67,hess:40,expert:[39,112,14,49],misalign:[78,65],nailed:24,someth:[54,39,99,13,8,100,20,61,16,33,97,53,67],"2fe374":64,particip:97,struct:[50,76,24,63,85,22,2,25,52,64,28,8,95,34,37,99,41,10,100,43,110,15,16,53,46,105,47,102,66,45,48,67],topmost:[87,47],"case":[0,50,73,75,70,76,24,81,69,85,51,88,25,6,45,55,28,106,57,8,32,66,33,34,36,11,38,39,99,59,40,13,10,100,61,15,16,111,17,46,1,97,105,63,53,62,20,102,93,108,21,42,87,113,48,67],restructur:85,mutex:56,honour:28,experi:[39,67,109,48,40],ringremov:22,type_link:102,altern:[98,70,28,75,40,41,66,85,16,34,102,38,88],signatur:[27,59,23,60,8,95,110,9,3,25,52,45],mpsevent:17,chain_o:47,disadvantag:[32,86,14,48,74],numer:[64,65,20,10],complement:39,sole:84,isol:66,mps_ap_destroi:[102,48],res_v:[102,16],awl_pool:[96,10],incident:[7,97],matthia:40,beown:56,valuabl:112,consumpt:70,distinguish:[69,70,28,73,74,30,65,48,83,85,86,22,33,3,46],"0000178ea03f6827":64,contain:[102,70,71,73,74,23,88,24,2,81,83,85,86,22,4,90,25,52,6,91,45,54,28,75,7,29,93,30,94,96,32,66,33,10,36,37,78,38,39,99,59,12,101,34,14,61,63,44,111,17,46,103,97,105,47,53,56,48,108,21,42,87,8,67,49],mps_ld_add:[105,34],classnam:45,"1003ff000":17,"0x000000010002b399":21,messageclass:[25,95],mps_pool_create_v:98,both:[102,72,73,23,24,81,85,3,88,2,25,53,55,28,56,8,64,32,66,33,10,38,101,34,14,61,15,63,111,45,20,48,17,108,42,87,30,49],teco:20,cryptic:97,last:[72,23,65,22,45,54,55,28,8,95,33,34,39,64,105,47,107,85,21,66,87,48],delimit:[99,46,42],linuxthread:[113,56],retent:[28,87],hint:[39,47,75,93,62,16,111,73,91,48,67],alon:88,algol:[73,14,40,20],isomorph:86,globalsinit:64,xleroi:56,context:[108,73,75,56,43,20,46,32,3,66,87,102,48,67],forgotten:21,oopsla97:40,let:[76,13,61,21,101,48],maclisp:[74,40],fermin:40,whole:[54,69,28,2,75,23,90,20,83,97,67,33,34,36,102,38],elsevi:40,ecma:20,load:[39,59,74,88,79,20,87,81,33,6,17,38,68],songworm:40,simpli:[70,73,75,83,85,87,88,25,53,28,23,56,95,38,39,41,14,61,62,16,45,15,66,67],"00000001003fe000":17,point:[0,1,73,74,75,70,76,24,2,81,83,69,86,51,88,90,25,52,91,53,54,28,56,57,30,94,96,32,33,34,36,11,78,38,98,39,99,59,12,13,10,61,62,16,111,17,46,103,105,47,63,41,65,20,48,102,93,108,21,42,87,68,113,8,49],instanti:[61,8,66],schedul:[0,79,47,12,40,57,41,30,10,78,108,62,75,34,17,36,38,68],hudson:[73,40],sweep:[27,47,40,23,2,74,13,73,79,20,32,87,97,77,26,36,78,49],arbitrarili:[85,16,48],header:[70,73,74,76,79,63,82,86,87,88,5,6,28,30,58,96,10,36,12,66,81,64,46,42,49,48,68],fashion:[78,11,108,20],hangov:23,suppli:[50,107,105,75,56,41,24,66,14,20,61,85,3,81,34,45,46,49],church:21,lar:[112,40],mistak:[102,21,16,75],gavin:[112,40,66],poolclassam:23,connexion:28,coincid:[61,28],topla:40,prot_:67,bits_act:23,stamp:[41,17],help:[39,70,11,78,2,48,21,33,42,25,17,112,37,45,38],devic:[78,14,75,90],due:[1,54,28,73,19,70,76,78,97,20,82,93,108,87,88,90,102,11],empti:[0,50,28,74,23,107,24,100,54,85,69,22,25,52,53,37,48],destructor:[39,72,73,40,70,20],clocks_per_sec:41,arenapol:[8,21],newcom:34,arenapok:100,dup:64,threaten:[86,73,40],frobr:22,devis:[78,86,3],obj_u:48,walter:112,anthoni:112,invis:[61,10],ram:[72,75,78,14,15,87,88,90,48,38],versa:[54,8,10,20,34,24],tracefindgrei:11,"0x0000000100067ca1":21,fire:[61,64,85,2],caleb:40,imag:[39,87,88,23],notori:20,convert:[23,41,8,66,61,22,97,42,52,17,11,53,67],unnecessarili:[87,34],gap:[61,82,11,46,48],fund:8,understand:[40,14,33,34,25,64],irix:[76,6,106],func:16,weak_array_find_depend:10,cbsdescrib:66,chatter:[0,68],vulner:[39,49],dequ:[22,60],base_address:37,henriksson:40,mergerang:66,strictest:69,look:[0,50,73,23,70,77,24,85,88,52,17,8,95,32,33,34,37,40,13,10,14,45,46,105,102,94,21,42,67,49],mpscmvt:93,solid:36,typecheck:9,straight:[61,33],erron:19,batch:20,segfre:28,durat:[54,72,75,20,87,46,38],"while":[0,72,78,81,86,87,90,28,95,32,10,38,98,39,99,59,34,14,61,102,19,20,94,21,42,48,67],leftreturn:85,unifi:61,ought:8,abov:[102,74,23,24,85,51,6,91,17,55,28,7,8,32,10,36,37,98,39,97,14,15,16,64,46,11,66,111,48,67],error:[102,70,72,74,75,76,24,2,81,85,22,88,90,25,52,53,27,28,30,58,66,33,34,36,78,38,98,39,99,13,10,100,62,16,17,46,97,105,47,63,41,65,21,42,87,48,67,68],fun:[23,8,100,61,9,25,53,67],mutandi:85,immobil:90,suceed:85,loos:[69,87,74,20],loop:[70,105,73,23,93,108,32,22,33,34,102,11,48,38],pack:[74,46,48],subsect:25,propag:[45,48,33],malloc:[1,39,74,75,8,14,20,48,78],untag_s:34,mem_top_down:38,clinger:40,readi:[8,95,97,45,37,48],technolog:[39,73,40,84],rit:11,therefor:[70,28,73,75,93,66,108,48,99,32,86,87,88,42,25,53,82,46,38],rip:20,willi:40,mps_arena_start_collect:38,itself:[72,73,81,82,83,85,22,88,90,6,17,28,56,8,9,33,34,11,39,59,14,61,16,45,105,29,65,108,21,42,110,87],spong:101,race:[13,45,102],virtu:77,limit:[0,50,72,73,74,23,76,24,79,95,85,87,88,52,17,28,7,93,8,58,32,66,33,34,11,78,38,99,13,10,14,43,16,45,46,97,47,53,20,102,94,42,112,48,67,101],rid:28,arenar:8,pedagog:[53,97],chase:[74,40],weakref:20,debug_opt:[111,36,91,2],"null":[24,63,85,87,52,28,8,10,37,39,99,34,97,61,101,102,46,105,94,21,66,48],irrelev:59,hypothesi:[69,30,81],grant:87,belong:[0,50,73,75,70,24,51,88,90,91,93,8,96,34,36,38,98,99,12,10,111,16,30,102,46,1,103,105,47,42,87,113,48,49],shorten:67,x64:[6,67],instal:[39,104,43,28,6,17],shorter:[102,48],oldkei:85,stefanov:40,decod:[75,17,88,33,6,64,68],mps_res_t:[51,88,2,91,93,30,94,96,33,34,36,37,38,98,99,12,13,10,61,62,16,102,46,103,47,41,108,21,42,111,113,48,4],rejoin:85,sqlite3:6,mps_bool_t:[0,98,105,34,63,61,16,42,111,102,37,46,38],deploi:[1,101,95],conflict:[8,59],higher:[70,28,41,8,99,81,20,64,48],vmcreat:[17,15],x86:[1,6,106,17,74],lie:[55,24,73],optim:[70,73,79,84,65,6,8,33,34,11,38,39,99,40,16,64,104,19,85,108,42,48],median:64,target_check_shallow:9,wherea:[73,78,51,84],entireti:28,dimm:72,segbufclass:28,moment:[53,100,101,34],segprefhigh:55,temporari:[61,75,40],user:[0,64,76,84,57,41,8,78,14,20,61,81,97,10,17,45,38],coercion:45,bartlett:[78,87,40,20],robust:[39,72,23,14,85,111,64,37],yuan:40,specialis:[64,67],transitori:66,recent:[70,99,73,75,77,8,79,51,33,90,64,67],sunpro:[6,106],travers:[39,8,72,85],task:[39,76,78,14,81,20,42,48],net:20,lib:[6,101,67],older:[69,39,28,73,106,77,78,71,46,32,87,88,90,64,48],entri:[71,105,59,23,88,24,34,14,20,81,33,10,25,112,113,8,49],mps_ld_:[53,105,34],yehudai:40,spent:[78,38],diwan:40,person:40,mps_lib_memcmp:[41,53],epdlpoolclassstruct:45,expens:[54,39,71,72,59,74,70,78,87,73,67],withdraw:50,traceend:28,cedar:70,johan:20,insidepol:8,spend:[0,39,59,78,14,86,38,73,67],poolclassawl:23,propos:[39,40,58,61,66,64],explan:[54,39],violat:[69,74,13,78,90,108,81,83,85,87,88,66,53,67],"000ae0397334df9f":17,ipc:64,epcor:[23,29,61,15,66,11],table_:[105,48,34],obscur:[28,16,74],"0x00000001003fb148":21,"__int64":67,relianc:63,shape:[25,73,85,3],collectionstatsnotcondemneds:25,messageclassstruct:25,mysql:7,love:49,fflush:41,mps_key_arena_cl_bas:[37,38],lockclaim:56,simm:72,stoutamir:112,cut:11,isfwd:[46,34],cup:38,scenario:[102,28,45],restructuredtext:[97,66],theoret:[39,73],failnextmethod:45,eager:[75,66],mps_message_type_gc_start:[0,78,47],"0x10012a000":21,appli:[54,99,7,78,43,81,83,61,85,87,16,33,97,25,102,11,48,67],snap:[35,28,86,87],input:[69,75,13,63,108,87,34,17,38],unlik:[28,73,20,87,33,48,103],usefulli:28,brainstorm:64,useless:17,indentifi:86,tag_siz:34,xcodebuild:6,march:40,obsolet:[48,106,46,34],nextnod:22,format:[1,70,71,73,74,75,76,79,81,86,87,4,90,6,91,53,54,27,28,93,30,64,96,2,33,34,36,37,38,39,99,59,12,60,13,10,104,61,101,17,46,103,97,88,11,20,102,21,42,111,68,48,49],big:[54,28,74,57,14,85,87,38,103],single_act:23,mps_class_ams_debug:[36,37,2],"0x1003f9bb8":21,alias:[45,33],bag:74,mps_arena_reserv:38,cierniak:40,insert:[66,61,85,22,101,33,90,102,11,67,68],c89:73,tracefinish:11,bit:[1,70,95,72,73,74,23,76,78,79,81,83,85,86,88,89,90,6,17,54,27,28,75,106,8,64,58,32,66,33,10,99,40,34,43,61,101,53,46,97,105,42,48,67],characterist:[83,55,93,70],bip:22,formal:[3,20],varp:48,xcodeproj:6,lost:[61,85,102,20],semi:[70,73,74,40,39,78,86,75,87,66],rossum:20,signal:[43,21,87,2,17,113,46,68],resolv:[39,53,86],manifest:[21,95],heart:[70,28,73,74,97,87,88,42,35],collect:[0,1,71,72,73,74,75,70,76,77,78,100,81,83,69,86,51,88,90,25,91,53,54,27,28,106,57,8,58,31,96,32,33,34,35,36,11,38,39,99,59,12,40,13,10,14,112,62,111,17,46,103,104,105,47,41,65,20,48,102,93,108,21,87,68,113,30,49],princip:[20,66],pithi:97,mps_debug_option_:[111,36,91],gavinm:[53,64,66],patrick:40,popular:[20,90],variant:[55,95,12,77,30,10,20,48,96,85,87,88,44,42,36,46,67,49],mpsacl:38,eec:40,mps_pool_class_epdl_debug:61,setrang:23,sketch:25,mps_gen_param_:[47,48],often:[69,70,72,73,74,23,77,78,79,80,81,83,84,86,87,88,90,28,75,8,95,32,97,11,39,13,14,107,20,21,42,48,67],comparegreat:[53,85],spring:87,fake:24,some:[0,1,71,72,73,74,23,70,76,24,79,81,69,83,84,85,86,3,88,90,25,52,6,45,54,55,28,75,56,8,64,94,58,32,33,34,11,78,38,98,39,99,59,40,13,101,66,14,61,15,16,44,17,82,46,97,105,47,63,53,37,41,107,65,20,102,108,21,62,42,110,87,113,48,67,49],back:[102,74,75,76,24,84,85,87,88,90,64,28,29,93,58,34,11,78,38,59,100,42,14,61,15,53,105,66],global:[39,97,59,56,53,8,90,64,99,48,104,21,87,88,33,34,6,112,45,67],understood:88,strongest:88,unspecifi:[88,23],sampl:[41,61],"0x1003faf30":21,rankmax:24,insur:28,sizeof:[102,55,97,105,47,74,23,106,53,10,42,94,63,85,21,16,34,111,45,66,48],surpris:39,obj_fwd:[46,48],fragmentori:28,scale:[39,78,20,83,87,53],laru:40,iji:3,weaksplat:28,though:[28,23,78,108,20,65,21,33,90,46,38],mps_awl_find_dependent_t:10,per:[102,28,59,40,23,41,24,14,43,20,33,66,25,17,113,64,78],prop:85,block_on_client_with_timeout:38,mps_ap_frame_pop:[96,51,75],substitut:[52,9,97,7,42],mathemat:[83,23],larg:[69,70,71,72,74,23,78,79,81,82,83,85,86,87,88,90,55,28,75,57,8,58,32,33,10,39,12,40,14,61,15,16,53,46,107,20,93,62,66,111],undon:100,recognis:[52,95],leftmost:[75,23],prod:67,reproduc:[39,21,97,7,70],worst:[69,55,28,75,40,70,107,83,108,10,111],mps_message_discard:[0,25,108,47,34],link_t:102,machin:[102,72,74,75,78,79,81,83,86,87,88,90,53,28,106,11,39,99,40,13,14,17,20,67],intial:28,run:[0,1,72,74,23,70,76,78,79,81,82,86,87,88,6,17,54,55,75,7,57,8,64,95,32,33,34,38,39,59,40,13,10,14,104,45,46,97,105,53,20,102,108,21,42,113,48,67,68],mps_fmt_t:[12,96,13,30,48,61,4,10,36,37,46],epdrpoolclassstruct:45,pietro:40,step:[1,23,42,86,43,95,102,61,32,21,33,34,36,48,67],identif:67,reservoirinit:50,vmreturn:15,santa:40,not_condemn:[0,21,34],mps_pool_walk:61,frob:[22,67],subtract:[0,39,75,87,33,42,46],impos:[51,108,72,11,23],sigbu:[21,113],mps_class_mvff_debug:[111,37,2],proven:[70,65],most:[1,69,73,74,23,77,24,79,63,82,83,85,86,87,88,90,25,6,64,54,28,75,57,8,32,9,33,10,11,78,38,39,99,59,13,34,14,62,16,44,53,105,41,107,20,48,102,108,21,42,112,113,30,67,49],row:64,proce:[1,54,105,13,81,86,33,42,111,11,38],traceabl:[8,97],prove:[69,28,75,76,108,95,65,86,97,48],lieberman:[71,40],vmalloc:40,idl:[47,38,68],mean_siz:93,needn:11,alfr:40,amclargesegpag:28,slot_high:111,abstractarenaclass:8,"r\u00f6jemo":40,uncach:8,napier88:40,predat:67,cutoff:62,compactli:[84,87,74],real:[54,39,40,78,100,20,84,32,87,16,81,90,53,11,88],colorado:40,primarili:[8,79,45,33,97],mps_ap_create_v:102,sigusr1:113,intl:40,within:[1,70,72,73,23,24,86,22,88,90,53,55,28,95,32,9,33,78,38,98,39,99,13,66,61,64,46,42,87,48,67,49],programat:46,toft:[40,20,88],mpmst:[110,97],protstepinstruct:43,myseg:45,rankweak:[53,33],mps_message_clock:0,obj_:48,ensur:[50,72,74,75,24,81,83,85,86,87,17,28,8,95,32,33,34,38,39,99,59,12,41,10,43,101,45,46,107,20,102,108,42,48,67],chang:[69,72,73,23,78,79,81,83,85,86,3,90,25,52,6,53,54,28,29,8,64,58,32,33,34,35,11,38,98,99,59,40,100,97,14,61,63,44,17,105,47,107,66,87,48,67,49],mps_args_add:[2,12,93,30,10,48,96,4,34,111,36,91,37,46,38,103],artifici:40,mps_key_rank:[96,34,37,10],redesign:[64,20],trampolin:113,occupi:[54,23,78,81,65,21,88,33,38],inclus:[93,28,48],span:[1,70],mps_format_cr:33,carnegi:40,zig:85,mythic:75,fledg:9,megabyt:[69,78,86,48,74],"0xfdfdfdfd":61,fast:[1,72,73,74,23,79,85,87,17,75,93,33,39,59,40,42,110,102,47,107,66,45,48],custom:[99,40,34,20,66,67],adjac:[50,39,72,73,74,70,107,15,16,89,66],reserve_depth:93,arithmet:53,includ:[1,69,71,72,73,74,23,70,88,77,24,81,83,84,85,86,87,4,25,6,91,45,28,75,7,106,93,8,64,96,32,9,10,36,37,78,38,39,12,40,13,101,34,14,43,61,63,17,46,103,97,105,19,53,41,107,20,48,21,66,111,30,67,49],suit:[88,20],forward:[70,73,74,23,76,81,3,4,90,45,28,30,96,10,36,12,61,102,46,104,19,87,48],nepot:77,datastructur:[23,8,43,85,66,24],superpag:[87,82],busytrac:8,record:[0,54,28,72,73,75,23,70,41,8,79,20,83,105,87,33,17,113,92,38],weak_array_scan:10,properli:[41,61,87,16,17,38],obj_unus:34,repeatedli:[70,93,79,61,87,38],subgraph:87,canstep:43,subsidiari:[61,66],mpscmf:103,teach:20,twenti:73,decomposit:23,navig:14,msg:64,dgc:72,state:[0,72,73,75,24,81,65,22,88,90,45,54,28,56,8,58,33,97,11,78,38,98,99,59,41,66,61,15,63,30,53,46,19,20,42,87,113,48,68],link:[50,70,72,73,24,83,85,86,22,88,90,25,26,6,102,27,29,34,52,39,40,10,14,17,20,94,5,66,87,68,67,49],translat:[75,40,84,8,58,61,86,81,33,90,78],newer:[64,11],atom:[54,39,59,75,40,56,8,79,45,113,102],sun:[40,20],line:[54,66,34,20,102,61,85,21,97,33,10,52,6,111,17,67],mitig:[39,28],mminfo:[97,66],ismm:40,sdk:6,info:54,concaten:29,jonathan:40,contamin:40,consist:[50,69,72,73,78,2,89,90,45,54,29,95,32,33,106,38,98,99,59,13,61,53,46,104,56,102,21,66,48,67],confusingli:[88,20],myseginit:45,pool_debug_opt:37,caller:[59,76,100,81,85,97,25,52,11,48,67],pkg_add:6,adequ:38,tightli:48,unlock:45,mps_roots_stepper_t:99,highlight:[102,40,34],mps_defin:[108,100,34],btsize:23,similar:[69,70,71,72,73,74,75,24,79,81,82,83,84,65,86,3,88,90,45,7,93,8,34,78,38,99,59,41,100,101,53,20,102,87,48],clear:[39,105,74,23,76,90,83,85,21,87,88,34,17,42,53],impl:[55,59,19,23,29,53,24,56,64,43,61,85,9,97,66,45,8,67,101],w3i3mv:[6,53,106],caught:113,vmunmap:15,constant:[99,59,23,106,13,73,66,81,61,85,21,3,63,95,41,52,67,88],curs:67,obviat:61,mps_end:61,doesn:[50,73,23,78,85,87,25,52,64,54,57,8,32,33,34,11,38,39,10,110,16,44,53,105,102,45,30,49],repres:[102,70,71,73,74,23,24,79,63,82,84,85,86,3,88,90,25,64,28,75,8,34,37,39,99,40,42,43,61,44,53,46,105,65,17,108,66,87,48],poolasm:97,proper:39,incomplet:[76,41,53,63,61],poolinit:[8,64,17,97],dconfig_var_df:67,aggrav:39,flexowrit:17,btx:23,getthreadcontext:1,singli:66,minsiz:66,oberon:20,w3i6mv:[6,67,106],sequenti:[70,28,74,40,93,78,81,86,87],water:74,sheetal:40,invalid:[0,74,81,83,85,51,88,90,102,54,8,95,34,38,98,99,13,44,53,19,66,87],setsparecommitlimit:8,appendic:27,"000ae03973361d5a":17,priori:[93,48,88],gonthier:[40,90],librari:[1,74,78,63,87,90,5,6,27,29,58,33,39,40,41,101,17,46,104,20,21,67,68],buckets_t:34,retract:8,coordin:[61,78],mps_scan_end:[99,10,42,46,94,33,34,48],messagetyp:25,nice:61,btdestroi:23,draw:[71,87],llvm:[1,106],users:17,gigabyt:[69,86,74],actual:[0,50,71,72,73,74,70,24,81,82,51,89,90,54,28,56,8,95,32,34,11,78,38,39,99,97,14,43,61,45,111],lii3eg:106,mps_rm_prot:[99,90],w3i3m9:106,william:40,meaning:[8,9,17,19],wrongli:2,eval:[108,21,34],unwind:100,vigil:33,alloc_pattern:62,param:[55,64,67],deserv:[61,3],lang:[20,83,87,88,90,45],pmo:40,necess:38,infrequ:[32,79,88],postedclock:95,algorithm:[69,39,28,47,23,40,107,78,86,20,82,83,32,75,87,81,111,73,88],vice:[54,8,10,20,34,24],ams_is_invalid_colour:13,seginit:24,bateman:112,discrimin:[53,86,95],depth:[59,40,93,24,79,48],appendix:[17,108],unconnect:82,dot:17,leak:[0,39,40,78,79,14,20,69,87,16,25],mps_arena_unsafe_expose_remember_protect:38,fresh:97,hello:101,prototyp:[52,67,23,20],unclamp:[65,73,38,90],"0000000000109ae0":101,code:[102,70,72,73,74,23,76,24,79,81,84,85,51,88,90,25,52,6,17,54,28,75,7,56,8,64,95,33,34,11,78,38,98,39,99,59,12,60,13,101,66,14,61,62,16,45,46,97,47,63,2,53,106,107,20,108,42,87,68,113,48,67,49],partial:[39,73,19,23,93,58,75,87,45,102],edg:[69,77,71,86,87],mps_arch_al:106,scratch:[32,102],cbsfinddeletenon:66,fclose:[41,34],gmake:6,mps_prod_str:29,mps_fmt_fencepost_wrap:61,gmk:6,attrbuf_reserv:53,gcstart:11,mps_arena_spare_commit_limit_set:[8,87,38],holdout:39,searchbas:23,mps_builder_:67,cbsinsertisolatedrang:66,compact:[54,72,73,74,40,78,79,20,82,65,87,88],root_scan:99,privat:[8,87,102,63,34],simon:40,pthread:56,secur:[78,20,90],ringissingl:95,quarterli:40,tracecondemn:97,elsewher:[105,29,33,53,46,67],young:[69,30,73,71],built:[39,99,72,73,106,24,20,63,33,6,48,67],mps_arena_step:[47,38],granular:[8,28,38,82],"0x0000000100005e30":21,tricolour:[83,86,87],evolv:59,becam:[108,75,67],visitor:[84,87],aris:[70,72,7,97,85,42,46],eventbuff:64,fatal:17,sent:[13,17],amcbufferfinish:[],amcbufferempti:28,pekka:[54,28,19,40,100,61,44,97,25,53,112,11,67],random:[70,21,87,88,95],mainstream:70,btreturn:23,bobrow:[72,40,20],amcss:[6,64,53],electron:[78,14,67,40],theori:[78,75,74,7,97],disast:28,pun:[68,86,48,63,42],untouch:[13,53,23],implicitli:[45,79,22,78],popl:40,relev:[69,70,71,72,73,74,23,78,79,81,82,83,84,85,86,87,88,90,25,75,99,14,48,67],tri:[54,69,73,74,13,78,66,81,82,83,61,65,86,87,16,33,10,53],mps_ld_t:[105,34],mps_ld_isstal:[79,105,34],magic:[52,95],salad:87,question:[1,27,73,7,39,13,20,31,61,109,6,48,38,49],complic:[28,23,61,88,90,64,67],joel:40,scalabl:[54,45,87,40],michael:40,blockquot:28,fewer:[14,85,11,23,39],mps_io_creat:41,"try":[1,39,28,55,56,99,95,54,61,32,87,67,33,10,17,48,38],poolclasslo:23,session:[64,38,34],maxsiz:[55,85],attrgc:53,freed:[50,39,28,72,73,74,75,70,93,8,79,14,32,87,16,90,102,48,78],rdoss:40,pleas:[1,7,13,14,63,109,21,6,113,102],app:6,impli:[39,28,59,7,70,76,8,20,85,87,97,17,64,67],smaller:[28,73,19,2,74,79,107,61,87,90,111,53,49],fortun:[54,84,32,40],readabl:[25,17,64,68],weslei:40,"0x3":99,natur:[54,28,72,74,75,106,93,13,103,20,61,16,89,10,77,111,53,91,64,49],inconsist:[113,81],memset:[41,53,21],elisp:20,mps_message_type_t:[0,78,47,108,34],crop:20,va_arg:[52,24],jump:97,fold:61,compareequ:[53,85],s7ppac:106,"0x1003f9be8":21,download:[6,48],hyper:[69,28],spaghetti:[87,73,67],rivera:40,append:[64,21,22,60],mps_ss_:63,compat:[7,64,58,89,25,52,45,53],mps_tramp_t:113,poke:25,lockclaimglobalrecurs:56,compar:[39,73,40,23,41,8,85,20,82,32,15,88,66,53,74],mainlin:67,segsplitmethod:24,"1003fc000":17,han:[112,40],"00000001003ff000":17,access:[0,69,72,73,74,23,76,78,79,81,82,83,84,85,86,87,88,90,25,5,6,45,28,75,56,30,32,10,11,39,99,59,12,41,34,14,43,61,15,16,44,17,46,97,105,47,63,53,65,20,102,108,21,100,66,113,67,49],squeez:82,experiment:[23,20,106],chilimbi:40,mps_clock:[0,41,95,63],cele:20,mps_key_extend_s:91,journal:40,deduc:[54,64],whatev:[73,41,61,38,33,64,67],penalti:88,ierusalimschi:20,led:[64,23],chose:86,boolcheck:53,compareless:[53,85],inlinedescriptors:66,"__assert_rtn":21,mps_args_non:[52,102,37,48,34],mps_message_type_gc:[0,78,47],closur:[73,75,40,97,20,82,85,44,66,67],waldemar:20,mps_res_ok:[63,88,2,108,33,41,38,98,99,34,13,10,62,16,102,46,47,94,21,42,113,48],ubuntu:1,"0x1003fb130":21,segsiz:[24,28],"0x0000000100003ea6":21,becom:[0,70,72,73,78,81,69,22,88,90,28,32,33,34,38,98,39,99,14,16,44,102,19,65,20,108,66,87,112,48],sinc:[1,69,72,74,23,70,76,78,83,51,25,53,54,55,28,8,64,32,33,34,11,38,39,99,41,15,44,45,46,103,105,47,19,107,20,102,21,87,113,48,67],obsolesc:85,mps_arena_commit_limit:38,attralloc:[13,53],great:[28,72,79,33,64,67],survei:[14,40],convers:[25,61,8,63,20],overcommit:[76,78],traceflip:11,hilfing:40,conceiv:67,larger:[70,72,73,74,23,77,79,86,87,88,57,33,38,39,14,15,16,46,105,47,107,20,93,66,48],genr:28,oldsiz:66,later:[0,39,28,105,47,34,14,1,32,87,33,90,73,38],resurrect:[102,108,88],epdl:[55,45],epdldbg:45,bufferdestroi:[59,97],earli:[39,23,40,24,20,75,87,81,33,95,78,67],typic:[69,70,71,72,73,74,23,76,78,79,81,83,84,85,86,51,88,90,25,45,54,75,7,106,93,8,64,32,10,38,39,99,59,13,97,14,16,17,46,105,63,41,107,65,20,102,66,87,48],perform_client_act:38,chanc:[61,28,113],mps_alloc_dbg:61,"0x00000001000014e3":21,marc:40,calibr:41,mpsclo:12,kurtz:20,clark:[76,40],nearest:[85,87],forbid:43,mps_lib_fputc:41,approxim:[54,39,99,72,47,19,75,70,8,79,69,88,53,24],foundat:54,sqlite:[6,17,68],apt:6,"0x1003f9bc8":21,rampmod:28,immut:[84,78,81,20,34],endsig:25,validli:[102,108,85,94,46],w3almv:106,greg:40,microcod:20,tailor:40,fee:[7,97],from:[0,1,2,3,6,7,8,9,10,11,12,13,14,15,16,17,19,20,22,23,24,25,28,29,30,32,33,34,35,36,38,39,40,41,42,44,45,46,48,49,50,51,52,53,54,57,59,61,62,63,64,65,66,67,69,70,71,72,73,74,75,76,77,78,79,81,83,84,85,86,87,88,90,91,93,94,96,97,98,99,100,102,103,105,106,107,108,110,111,113],unallocat:50,zip:6,mps_ap_alloc_pattern_end:[62,88],doubl:[69,72,47,74,40,93,95,65,75,16,33,90,25,53,64,38],arenacreatevm:17,next:[1,69,73,23,70,77,24,84,85,22,102,54,28,93,8,33,34,11,38,59,66,14,62,16,45,46,104,47,107,21,42,87,48],few:[1,39,73,74,23,76,107,79,14,20,63,86,69,21,16,33,34,52,38,101],dconfig_plinth_non:[41,6],doubt:7,usr:6,protic:40,lesli:40,simpler:[0,39,48],postpost:2,remaind:[70,28,11,107],sort:[0,39,28,105,74,87,53,78,64,71,95,54,3,88,5,17,46,67],mps_ap_create_k:[96,102,34,48,10],dash:34,clever:[61,19],freetre:85,tag_data:61,fillmutators:8,poolisvalid:59,benchmark:57,mps_root_t:[99,48,88],classes_count:16,cbsfinddeletehigh:66,formatcr:59,insensit:20,basetractreturn:50,b0084kai:67,central:[87,64,73],rusage_self:41,structu:2,epdldebugcheck:45,interven:[62,16],gcsegclass:28,mps_pf_:[67,106],account:[54,28,73,8,32,34],hoard:40,retriev:[0,47,23,100,84,108,87,38],augment:[25,76],cannarozzi:40,alia:[102,99,105,76,13,63,86,88,41,45,53],chief:[112,38],annot:[59,58,20,33,64,67],larch:40,plinth:[0,27,53,41,64,63,90,6,17,68],obvious:[61,45],arenacommitlimit:8,meet:[23,8,85,44,66,64,46],tracescanseg:21,withdrew:67,aliv:[77,39,28,79,12,75,57,13,10,94,81,83,96,108,42,87,88,34,11,48],proof:13,"0x0000000100003f55":[17,21],config_var_hot:[13,67,82],weaker:90,bitmap:[73,74,81,86,87,17],operator_:48,grace:64,process:[69,72,73,74,75,78,81,82,83,84,85,86,87,88,90,6,92,54,29,57,32,33,34,38,39,40,13,10,43,15,17,19,107,20,108,42,48,67],lock:[1,27,28,105,59,56,53,13,8,79,58,48,102,108,44,45,113,46],loci:54,"9c14c":64,"0x00000001003f9ae0":21,mvffinit:55,high:[39,28,72,47,40,23,55,24,66,86,20,85,75,87,81,42,111,17,78,74],protix:21,accesssetempti:24,fprintf:[41,101,21,48,42],mps_arena_commit_limit_set:[13,73,38],thirti:40,locu:54,mps_mv_free_siz:91,serial:[41,8,53,40,101],mps_capac:47,giusepp:[112,40],everywher:[48,74],gcc:[1,23,106,21,6,48,67],"0x7fff5fbff0a0":21,iwooo:40,minlength:23,link_:102,six:[55,40,106,85,88,6],smoothli:[47,48],"0x10012a5a0":21,georg:40,"0x1003fa7d0":[17,21],preformat:11,mps_thread_dereg:[99,113,48],fence_s:2,fulli:[73,63,9,87,97,45],btresrang:23,fencealloc:61,mps_pf_xci3gc:106,l979:40,circular:[77,86,22,40],nonew:28,delai:[93,108,21,11,40],msdn:67,"_addr":[48,42],constraint:[108,72,47,75,77,8,14,65,58,32,86,16,34,46,38],overridden:[8,45,67],"1078c85b8":17,interchang:[71,88],watch:78,bufferfinish:97,protocolsomeclassstruct:45,inst:45,amcheaderfix:28,attent:39,attenu:66,redund:90,btfindlong:23,enshrin:67,physic:[39,75,84,57,77,78,81,76,65,86,87,88,90],mps_arena_releas:[65,21,38],buffercommit:59,alloc:[50,1,71,72,73,74,23,70,76,77,24,79,81,69,83,85,86,51,4,90,25,91,45,54,27,28,75,113,56,57,8,64,94,58,31,96,32,66,33,10,36,11,78,38,98,39,99,59,12,40,55,13,101,34,14,104,61,15,16,111,17,82,46,103,97,47,63,88,53,37,62,107,20,48,102,93,108,21,100,42,87,68,2,30,49],drop:[83,28,32,92],essenti:[0,59,76,20,85,87,90,11,48],reservoiravail:50,mps_fix:[46,33,42],light:39,jin:40,counter:17,chapman:40,element:[28,73,8,79,86,85,21,22,16,66,87,37,48],issu:[74,23,78,14,58,108,75,87,25,5,113,68],findlongresrang:23,stavro:[112,74],unaccept:[39,87,81,55],freebsd:[1,6,113,67,106],mps_class_am:[36,37],fallback:[67,66],mps_key_arena_s:[37,48,38],longest:[53,67],mps_tag_a_:61,elif:67,neglect:[0,13,20],creation:[55,79,73,74,75,66,100,58,61,108,51,44,34,52,17,48,38],larson:40,ouput:38,berger:40,train:40,solv:[39,40,78,34,32,87,66,48],move:[1,70,71,72,73,74,23,77,78,79,81,82,86,87,88,90,52,91,102,54,28,93,8,58,96,32,33,10,35,36,11,38,12,34,16,30,53,46,103,97,105,20,108,42,111,48,49],microsystem:20,downgrad:59,cbsblockbas:66,mps_root_creat:[99,73,48,90],notabl:[54,53,72,75],uniprocessor:40,jni:90,callabl:[8,59],"2fe2c4":64,perfect:[47,74,90],pai:[39,28,33],famili:[106,67,20,74],movabl:[49,90],outer:110,event_wd:64,brian:40,chosen:[54,77,107,85,65,32,3,33,87,48,38],mps_os_so:106,him:39,omit:[9,21],whether:[0,69,73,23,70,76,24,79,81,85,88,90,25,53,54,55,28,7,106,8,64,95,32,33,34,35,11,38,39,99,66,100,43,61,44,45,46,97,105,102,42,111,48,49],mps_addr_t:[75,63,86,17,88,102,30,94,33,34,37,38,98,99,10,61,16,53,46,105,108,21,42,48],poolclassmf:59,splaynodestruct:85,mps_os_su:[67,106],mps_class_lo:[37,12],peyton:40,symbol_:[102,48,34],trace_max:[53,8,11,24],uninitialis:90,cbsfinddelet:66,factor:[39,78,86],crash:[64,14,108,38],pure:[1,69,72,34],python:[39,14,20,90],avgsiz:55,overal:[59,23,29,57,33,11,48],innermost:62,cover:[54,28,79,14,99,63,87,42,102,48,38],wastag:50,chenei:[69,86,73,40],mention:20,mps_root_create_reg:[102,99,86,113,48],snake:90,commun:[0,72,73,40,78,20,83,61,32,81,66,35,46,88],instead:[102,72,73,23,79,63,83,85,86,17,88,25,52,91,53,54,8,32,9,33,34,36,38,98,39,12,13,10,100,61,16,45,41,20,21,42,87,67],front:[70,79,47,38],arenadestroi:[100,59],scatter:[32,71,64,40],strive:[8,105],mps_arena_clamp:[73,38],type_pair:[17,21,48,42],mps_arena_formatted_objects_walk:[30,87,46,38],config_plinth_non:41,anyth:[1,39,28,55,99,95,54,70,61,32,33,42,6,11,48,67],edit:[8,29],iglio:40,tran:[8,3,95],myunnoteseg:45,dominiqu:40,mode:[0,69,28,73,93,24,66,43,20,99,61,21,88,90,53,48,68],truth:42,poolr:24,poolxxxstruct:110,stock:[40,20],walgenbach:40,cbsfinddeleteentir:66,whiten:97,subset:[54,99,19,23,93,97,87,88,66,64,48],societi:40,"__gc":20,accessnon:53,eventlast:64,arenaringinit:8,freetreealloc:85,chunk:[50,38],amcfixemerg:28,mps_os_fr:106,"002d":17,predic:[84,45,78],synthes:40,pad1_:[21,48],bim:22,grai:[69,73,74,76,81,83,86,87],"static":[0,1,72,73,75,82,86,87,88,25,52,64,56,8,58,33,34,39,99,59,40,61,53,105,20,21,42,45,48],lfp:40,fluctuat:[93,16],our:[59,8,14,63,101,34,25,17,11,53,49],mps_res_commit_limit:[13,16],mps_arena_collect:[30,21,38,90],mps_fmt_isfwd_t:[46,81,48],special:[1,70,71,73,74,75,76,24,79,63,85,51,88,90,45,28,7,8,58,96,10,39,13,66,14,44,111,53,97,107,20,17,108,100,42,87,48],obj_gen_param:48,variabl:[102,72,73,75,76,78,79,63,22,88,2,26,91,17,27,56,93,30,64,58,96,32,33,34,36,38,98,39,99,12,40,55,41,10,14,61,111,45,97,20,66,87,68,48,49],eqv:[0,108,21,34],rootcreat:59,"th\u00e9se":40,contigu:[70,74,23,76,8,79,81,61,85,15,87,33,66,24,78],busi:[7,8,10,100,20,97],influenc:[85,73,20],pointless:[44,103],rep:28,req:[59,23,8,100,61,85,110,66,25,45,64,67],sizereturn:85,facto:96,"0000178ea03f4ec8":64,categori:[28,59,17,88,53,64,68],indepd:52,pooldescrib:[59,97],mps_key_mfs_unit_s:[37,103],suitabl:[50,70,74,23,78,79,81,85,17,55,75,7,56,10,36,39,99,41,16,64,46,1,107,66,48,49],sever:[70,72,73,23,77,79,87,90,102,54,28,57,8,33,38,39,66,14,61,45,2,107,20,93,42,111,48,67],wether:28,hardwar:[54,71,72,73,74,40,78,14,20,31,86,32,75,87,58,81,90,46,38],iam4cc:106,ref:[23,24,81,83,85,87,88,90,25,64,54,28,56,94,33,34,35,99,100,53,17,108,42,48,67],alter:[51,67],old_symtab:48,nailboard:28,franc:40,unfixedsummari:19,mergedsegreturn:24,insid:[50,98,28,47,40,23,30,81,21,33,42,25,59,113,46],parenthesi:63,fmt_a:46,frank:40,manipul:[39,59,23,24,79,43,20,46,83,9,87,66,25,113,8],wherev:53,detlef:40,powerpc:[6,81,106],control:[1,70,71,72,73,23,78,81,86,87,88,17,54,55,28,75,8,64,58,32,9,38,98,39,99,59,40,41,14,61,63,53,103,20,102,21,66,113,48,67,49],arena_class:38,"0x1003f9bd8":21,york:40,transliter:[27,3,60],usual:[0,1,71,72,73,74,23,70,77,24,79,81,82,83,84,69,86,3,88,90,25,102,54,55,28,75,32,33,34,78,38,39,13,97,14,16,111,45,46,105,19,87,107,20,108,42,22,48,67],releas:[39,97,47,29,13,8,56,108,63,70,2,67,34,25,59,6,99,113,24,38],mps_fmt_create_a:[48,46,34],mps_mortal:47,queri:[17,78],likelihood:28,afterward:[99,42,38,34],refset:[53,54,8,24],reslimit:53,septemb:40,walker:[61,97],jacqu:40,tru64:[6,106],unwant:[64,20],could:[71,23,76,78,100,82,85,86,22,88,6,45,54,28,58,32,36,11,38,99,59,13,66,14,61,44,53,105,20,17,42,48,67],lexer:48,leftchild:85,segreg:[70,71,74,79,87,4,91,27,93,30,96,34,36,98,12,10,16,103,104,42,111,49,48,68],timer:17,keep:[74,81,83,85,86,87,88,90,54,28,56,8,94,32,33,10,11,38,39,12,34,42,14,61,101,47,107,20,108,109,66,48,67],counterpart:[102,2],length:[0,28,105,47,23,53,34,64,42,48,102,21,3,101,10,17,11,45],enforc:[113,67],wrote:[13,41],outsid:[54,39,28,59,76,71,61,11,49],mps_class_snc:[96,37],retain:[39,28,72,73,7,93,97,14,58,3,81,66,87],"universit\u00e9":40,scarc:[70,108],austin:40,softwar:[54,27,72,73,40,7,29,39,20,58,97,5,38,74],isbn:40,suffix:67,traceband:11,bame:101,qualiti:41,port_clos:34,echo:17,date:[54,19,29,85,58,32,25,48],strategi:[54,55,59,75,40,56,61,32,87,73,11],haskel:[14,40],amcsegscan:[],owner:24,shortcut:28,facil:[54,55,28,56,41,8,61,66,45],buckets_find:[105,34],suffic:34,ecoop:40,prioriti:66,ancient:64,dump:[61,64,3,95],strict:[69,73,74,7,97,87,88,66,59,45],unknown:[0,1,55,93,13,83],mps_arg:37,perfectli:39,system:[1,69,72,73,74,75,70,76,78,79,80,81,82,83,84,86,87,88,90,5,6,45,54,27,7,56,57,8,64,95,31,32,66,109,33,10,11,38,98,39,99,12,40,60,13,34,14,43,15,16,17,46,97,19,63,52,41,106,107,20,102,108,21,104,42,113,48,67],messag:[0,70,75,78,83,95,25,17,27,58,34,11,38,98,39,41,100,101,64,47,20,102,108,109,45,68],arenadescrib:59,uninsur:28,attack:78,poolcheck:9,btcopyinvertrang:23,termin:[102,70,75,23,13,41,66,85,86,42,25,17,64],"final":[0,1,70,83,86,88,90,25,91,54,27,28,93,8,94,58,96,33,34,35,36,37,39,12,40,10,100,101,30,53,103,104,11,20,108,111,68,48,49],poolreclaim:[11,97],rightnod:85,genear:28,shell:17,ferrit:73,uneras:28,deregist:[99,100,108,113,48,38,49],"__del__":20,obj_quot:48,juli:40,shallow:9,accompani:[67,7,97],lockreleaseglob:56,enqueu:[83,87,88,90],qualifi:[79,20],diminish:57,edeadlk:56,exactli:[69,28,72,73,23,76,24,10,14,43,63,61,66,90,25,45,79,53,67,49],steel:[54,74,40],resist:101,unmap:[70,78,84,65,15,87,88,38],holland:40,cpython:20,bloat:[25,39],initalis:59,couldn:[28,47,99,46,61,34,11,48],"0x1003f9948":21,roberto:20,emac:[0,13,69,20],structur:[50,1,95,72,73,74,23,70,76,24,2,80,81,69,85,86,22,88,90,25,52,53,54,27,28,75,29,8,64,58,32,9,33,10,37,78,38,98,39,59,40,60,13,34,14,61,15,16,66,45,82,46,103,97,105,47,63,41,56,20,102,21,62,42,110,87,113,48,67],epdrinit:45,claim:[59,56,13,8,86,45,113],dai:[54,39,28,23,95,101,10,67],myformat:6,mps_res_resourc:[13,16,38],sens:[70,73,74,79,84,85,87,34,48,49],mps_arena_commit:[78,38],seriou:[1,39,88],dubiou:[65,23],exp:21,spaceaccess:97,stdio:39,bet:61,busili:32,exhibit:[79,74],weiser:[69,39,73,40,20],"0x00007fff91aeed46":[17,21],freefre:2,mps_root_destroi:[99,48],linker:87,deprec:[23,63,51,4,52,91,17,93,30,96,10,36,38,98,99,12,102,103,108,42,111,113,67],mps_pf_align:[103,106,93,77,8,10,91,67,49],correspond:[50,70,74,23,78,69,86,51,88,53,56,8,94,96,33,34,37,38,99,10,100,62,101,64,46,97,106,108,66,113,30,67],arenaaccess:8,tom:[112,95],dimens:[84,87,67,40],scientif:20,usenix:40,have:[0,1,2,22,6,8,9,10,11,12,13,14,15,16,17,19,20,21,23,24,25,28,29,30,32,33,34,36,37,38,39,41,42,43,44,45,46,47,48,49,50,51,53,54,56,59,61,62,63,64,65,66,67,69,70,71,72,73,74,75,76,77,78,79,81,83,84,85,86,87,88,90,91,92,93,94,96,97,98,99,100,102,103,105,106,107,108,109,111,112,113],ari:40,need:[0,50,71,72,73,74,23,70,76,77,24,79,81,69,83,85,22,4,90,52,6,45,54,55,28,75,56,30,64,94,96,32,33,10,36,11,38,39,99,59,12,87,13,101,34,14,61,16,111,17,82,46,1,97,105,47,19,63,88,53,37,41,20,48,102,108,21,100,42,51,113,8,49],wakel:40,amcscannail:21,turn:[54,69,79,47,2,34,61,21,87,97,42,73,17,46],tidi:[0,104,48,67],flip_mask:17,optimis:[64,67,33],runciman:40,lazili:[100,73],sdram:[72,87],depict:71,mpscamc:[30,4,63,48],min:[8,67,66],diverg:28,mib:28,mid:[24,28],"0x1003cbe38":21,accuraci:[83,53,11],mix:45,unawar:90,discret:[46,97],"0x7fff5fbff7d0":21,which:[0,3,6,7,8,9,11,13,14,15,16,17,19,20,21,22,23,24,25,28,29,32,33,34,35,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,59,61,62,63,64,66,67,69,70,71,72,73,74,75,76,77,78,79,81,82,83,84,85,86,87,88,90,92,93,94,95,97,98,99,100,101,102,103,105,106,107,108,110,113],mps_message_type_fin:[0,70,78,108,34],mip:[6,106],addison:40,type_charact:34,singl:[1,69,72,73,23,70,76,24,79,85,22,88,25,54,28,75,56,57,8,58,32,33,10,36,37,78,59,43,61,15,44,45,107,20,21,66,87,113,48,67],uppercas:63,btisresrang:23,radioact:40,unless:[69,75,63,90,25,91,17,55,28,93,30,32,10,36,39,59,12,34,42,14,43,61,15,64,103,102,66,111,48],rove:[77,107],combat:10,deploy:[1,13,17],quantifi:40,lockfinish:[59,56],licens:[1,27,7,58,97,6],discov:[73,57,13,86,61,94,21,34,25,48,38],mortal:[69,28,47,40,57,30,20,81,36,48],arenacr:[8,59],rankambig:[35,28,53,33],amcsegclass:28,eight:[83,28,67],typenam:45,intern_str:34,advic:[104,21,16,38],bjarn:[39,20],nostop:21,config_var_:67,why:[0,39,28,21,47,23,41,108,9,34,53,102,49],morrisett:40,make_port:34,lee:40,placement:[28,23,40,8,58,75,90],brad:40,won:[50,54,55,8,14,48,87,16,33,25,102,24,88],mps_pool_t:[98,55,48,2,12,103,96,93,30,10,46,102,61,16,90,111,36,91,34,4],instig:0,splaynodefinish:85,request:[1,69,73,74,23,70,78,81,82,83,87,90,52,91,102,54,55,28,75,29,8,109,34,11,38,98,13,97,14,43,61,15,16,53,103,107,20,21,66,111,48,49],coexist:90,face:[87,78,14,75],inde:[8,46,42,45,78,67],attrbuf_alloc:53,deni:97,snazzi:101,snapshot:[83,87,81],"9c080":64,determin:[0,69,72,73,75,70,24,79,81,82,83,84,85,86,87,88,90,25,5,64,54,28,29,8,94,58,32,66,33,34,35,11,38,98,39,99,10,43,61,44,53,46,97,105,65,20,102,108,42,111,48,67,49],occasion:[28,33],constrain:[55,28,24,61,66,53,64],stichnoth:40,fact:[69,70,71,23,24,79,63,86,88,25,45,94,95,33,78,38,99,14,16,53,105,20,108,21,42,48],"000000010992f000":17,arenacheck:8,guei:40,gen_count:47,vmtractofaddr:11,text:[74,75,58,87,20,97,17,64],verbos:17,"0x100002130":21,minski:[40,20],poolaccess:97,connect:[69,71,73,76,41,30,14,108,32,22,88],bring:[85,38,23],"0x000000010000447d":21,base1:85,empir:40,totalreturn:[28,21],parentclassnam:45,discoveri:28,trivial:[28,19,8,66,110,102],anywai:[28,56,45,105,34],untermin:52,duck:20,redirect:28,insertisolatedrang:66,textual:[85,97,66],locat:[0,70,71,73,74,23,76,78,79,81,83,85,51,88,90,53,27,28,75,56,93,8,58,32,66,10,38,98,99,13,34,14,61,16,44,45,46,104,105,47,63,41,107,102,108,100,42,87,68,113,48,49],segbas:24,materi:[39,7,97],print:[0,53,66,64,108,20,85,21,97,34,17,48,38,101],youngest:69,correl:93,rash:[73,75,13,82,84,88,67],should:[0,50,23,70,24,81,83,85,86,3,88,2,25,6,91,45,54,28,57,8,64,95,96,9,33,34,35,36,37,78,38,98,39,99,59,40,13,101,10,43,61,15,16,17,46,97,105,47,63,53,11,41,102,93,108,21,62,66,110,48,67,49],mps_ld_merg:105,held:[8,66,59,16,56],smallest:[69,28,73,74,93,107,87,16,66,111,53],suppos:[35,99,16,23],preturn:97,splaytrivupdatenod:85,messagetypecollectionstat:25,"0x00007fff90509df0":21,various:30,"0x1003fad48":21,local:[70,72,73,74,75,77,78,79,81,84,85,86,87,88,6,102,56,32,9,33,39,99,40,41,14,63,45,46,107,42,48,67],minnow:11,inferior:67,invalu:95,meant:[70,87],protstruct:67,softrefer:[87,88],mps_fmt_pad_t:[48,46,90],contribut:[54,112,19],mps_block_siz:16,lii4gc:106,findfirstbefor:66,tract_of_addr:8,make_str:[21,34],simplest:[102,55,59,24,85,86,6,48],memcpi:[41,53,21,11,102],bear:57,neighbour:[85,66],joint:40,mps_arg_:[98,80,52,102,37,48,38],lockinit:[59,56],lockix:13,tbl:[105,34],cbsblockdescrib:66,increas:[50,70,73,76,24,83,69,88,64,28,38,39,59,13,100,62,16,17,19,107,85,67],debugpoolcheckmethod:45,cbsgl:66,thomson:112,obj_fmt:[48,46,34],nmake:[6,67],nocopi:11,extract:29,dissimilarli:75,enabl:[0,13,41,10,64,48,108,87,34,25,17,45],organ:[39,28],whilst:[28,11,85,97],underscan:[36,21,104],caudil:40,stanford:40,symtab:[99,48,34],mpscam:36,perl5:3,base2:85,stuff:[28,11,67],mps_sac_destroi:16,integr:[1,54,75,106,53,13,78,20,63,61,22,67,95,34,36,48,38],partit:[28,40,77,8,58,85,88,11],"__mode":20,grab:111,btfindlonghigh:23,btfindlongresrangehigh:23,view:[1,54,59,74,75,56,8,81,70,61],typereturn:25,conform:[73,23,41,63,45,67],legaci:[52,6,60],modulo:105,disastr:25,inexplic:75,poolalloc:[55,53,59,97],pointer:[0,70,71,72,73,74,23,76,77,78,2,81,82,83,85,86,22,88,90,64,54,66,28,75,106,8,94,95,96,32,9,33,10,36,11,38,98,39,99,59,12,40,41,101,34,14,61,15,16,44,53,46,103,97,105,47,63,107,65,20,48,102,108,21,42,87,113,30,49],knowledg:[93,107,14,87,66,45,48],bty:23,writefa:101,packet:64,writefc:101,veljko:40,temporarili:[25,62],writefx:101,now:[0,70,73,23,78,85,90,17,28,33,34,37,98,39,59,97,100,15,102,11,20,48],wors:[70,28,107],writefu:101,writefw:101,writefp:101,modulu:23,mps_add_fencepost:61,mps_pf_fri6gc:106,polymorph:[45,53],statu:[39,64,66,106,10],"0x1003f9c08":21,buckets_scan:34,correctli:[105,59,75,42,81,97,45,102],reform:67,mps_os_xc:106,boundari:[55,73,23,40,79,81,85,75,87,111],misus:22,below:[1,73,23,85,97,25,6,17,28,56,57,8,58,32,66,34,38,39,99,13,10,14,43,61,45,47,106,107,102,108,21,42,48,67],mps_ap_:[102,63],tend:[74,23,14,83,42,67],favor:39,written:[1,72,73,23,86,88,2,25,52,17,54,95,33,10,39,59,41,14,64,107,20,94,66,45,112,48,67],luc:40,entrant:[88,13,85,46,66],mpseventsql:[104,6,17],mps_fmt_auto_header_:[46,42],crude:76,progress:[54,69,28,47,40,79,58,109,90,73,17,11,38],neither:[98,99,72,90,83,9,66],amortis:85,tent:61,verifi:28,locksiz:56,javascript:[14,20],patholog:28,amen:53,lamport:40,appopri:16,mps_res_unimpl:13,job:[39,30,14],entir:[39,28,23,57,78,10,14,85,20,97,32,66,22,81,33,90,87,64,65,38],mps_fmt_a_:[48,46,34],rankset:24,splayfindlast:85,poolclassmv:59,argument:[0,73,23,24,80,63,83,22,4,2,25,52,91,53,54,27,93,8,60,64,95,96,66,10,36,37,38,98,99,12,40,55,13,34,16,30,45,46,103,102,42,111,113,48,68],poorer:85,swift:73,problem:[69,70,72,75,78,95,82,86,3,88,90,17,54,28,8,58,31,32,10,39,40,34,14,61,53,87,107,20,108,66,22,48],addit:[102,72,73,74,23,76,24,85,86,17,54,28,93,30,96,32,33,10,36,38,39,12,14,61,16,45,46,103,107,20,108,111,48],mps_fix_cal:[46,42],attrpm_no_writ:53,drum:[87,74],bucket_:[105,34],mps_class_mv:[91,37],unformat:[93,61,111,49],obtrus:32,mps_arch_pp:106,ramp:[28,47,58,62,88,68],eventkindenum:64,jersei:20,mps_pool_creat:[98,12,93,30,96,4,10,111,36,91,103],thereaft:[28,15],summarysofar:19,tricolor:[83,86,87],instanc:[70,74,75,78,81,83,86,87,25,53,55,28,93,8,33,97,11,99,59,41,61,15,45,66],grain:[69,28,59,77,8,83,66,24],equat:74,committe:20,mps_class_mf:[91,37,103],section:[54,66,105,56,13,34,14,58,86,42,22,33,10,6,11,48,67,49],freeli:[46,7,97],prot_foo:67,cactu:[87,73],suno:[6,106],mps_sac_t:16,boyer:[40,23],"0x00000001003f9b40":21,comment:[0,28,42,3,97,33,66,112],unimpl:53,unmark:[78,87],english:[47,73,3],reservoirwithdraw:50,bufferreserv:59,guidelin:[45,64,58],rarer:72,arriv:83,arena_high:111,walk:[61,46,97],distil:20,arenastruct:25,ucb:40,commenc:[64,38],clash:[45,63],respect:[54,105,74,23,56,13,24,86,20,48,85,75,87,66,53,8],leftblock:66,traceset:[53,8,24],seligmann:40,mailto:7,quit:[50,39,99,73,75,70,77,64,20,83,61,32,86,52,17,48,67,49],slowli:17,ring_for:22,mps_build_eg:106,reg:64,addition:[39,23,78,63,85,62,45,38],decent:49,accumulatorreset:53,compos:[107,40],insuffici:[102,66,51,20,90],compon:[54,39,7,29,8,20,15,88,97,6],mps_pf_w3i6mv:106,plezbert:40,treat:[28,72,10,34,71,108,105,97,90,11],tactic:48,popul:[93,16,20,23],inv:[24,44],"0x000000010002d020":21,freeblocktestnod:85,field:[50,70,71,73,74,23,76,24,79,81,85,86,22,88,90,25,45,54,28,8,64,95,9,10,35,37,59,34,14,43,61,44,53,46,97,19,20,102,87,48,67],set_mask:17,memcmp:[41,53],unpreserv:28,amcrampend:28,presenc:[105,59,75,79,61,32,10],decai:[69,40],forestal:90,assert:[0,73,75,82,88,2,28,23,9,33,41,13,97,101,17,48,21,42,110,34,67,68],zero:[0,72,2,75,88,77,24,79,83,4,90,26,53,27,28,64,92,32,66,33,10,37,39,99,12,13,101,34,16,17,97,52,41,20,42,48,49],togeth:[69,70,47,75,23,93,107,24,14,48,61,88,82,46],colnet:40,shire:112,reinhold:40,pig:90,plausibl:[39,23],present:[54,69,56,41,34,14,86,62,87,97,42,25,53,11,48,67,49],statist:[17,47,28,33,38],determinist:21,multi:[1,39,28,40,7,56,8,79,86,102,15,75,90,64,113,48,78,88],cbsinit:66,obj1:45,plain:23,align:[50,69,2,74,23,77,24,79,81,83,65,86,97,90,91,102,55,28,75,106,93,8,58,96,66,33,10,36,11,38,99,12,13,101,34,61,16,30,53,46,103,63,37,21,42,110,111,48,67,49],event_intern:17,corrigendum:40,fmt_b:46,foster:20,cursor:33,defin:[0,70,73,74,23,77,24,81,82,85,86,3,88,25,52,45,28,56,64,95,9,41,106,99,59,13,34,100,61,63,44,53,97,29,108,21,42,87,48,67,101],deem:38,talpin:[40,20,88],rightblock:66,glossari:[69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,65,86,87,88,89,90,92,27,39,14,18,112],s7ppmw:106,blockbas:66,observ:[69,39,74,75,79,108],april:40,mps_os_o1:106,layer:[87,14,107],purchas:28,conclus:[39,28],incapacit:17,cell:[76,83,73],almost:[50,39,75,20,83,61,22,102,48,1],mps_chat:0,site:[39,109,70],bodi:[69,79,109,22,52,45],roll:[],mps_args_add_field:37,mps_pool_class_t:98,archiv:[6,109],cbsinsert:66,attrfmt:[53,97],substanti:[32,72,88,20],buckets_fmt:34,r2000:106,protspong:67,revis:[73,66,11,40,34],tempor:[27,93,66,26,102,49],pda:87,greater:[28,23,41,95,84,85,87,66,53,38],parent:[77,81,85,9,51,22,45,53],buckets_skip:34,trap:[90,40,78,97,66,102],mutat:[50,70,72,73,75,24,79,81,83,69,86,87,88,90,54,28,8,58,32,11,78,38,59,43,44,53,19,65,20],mps_arch_:67,mps_mvff_size:[55,111],eliot:[112,40],"0x00000001003f9b80":21,referenti:70,satisfi:[98,70,72,75,23,93,107,46,85,87,90,102,82,48,49],cross:73,arglistcheck:52,yuasa:40,member:[72,73,106,8,20,85,86,63,95,42,53,112],matthew:[112,40,66],anachronist:[28,81],mps_reserve_block:[102,63],auto:[12,30,10,96,42,36,46,49],domain:[39,20],failur:[66,72,13,24,34,86,110,85,21,97,41,25,45,53,78,105],inc:40,infer:[75,20,85,87,88,3],optarg:61,afterrampgen:28,competit:93,spell:95,http:[6,97,67,56],charact:[39,74,106,41,48,85,87,4,33,34,6,17,67,101],denot:[6,74,23],expans:[13,53,63,23,29],heapsort:82,maxlength:23,upon:[63,83,84,85,34,45],effect:[0,70,73,74,23,24,81,85,25,17,54,28,75,57,96,32,11,78,38,39,99,40,61,15,16,64,105,63,62,107,102,21,66,45,48,67],coffe:38,handi:[83,87,67,90],mps_pf_lii6gc:106,limit2:85,sooner:[39,21,38,33],student:20,dealloc:[69,70,72,75,76,78,90,81,82,85,87,2,91,28,93,30,96,10,36,39,12,13,97,16,102,103,20,66,111],customalloc:40,decoupl:67,blocklimit:66,expand:[106,13,63,22,20,45,53],ringappend:22,mordechai:40,swizzl:40,off:[28,73,56,76,107,86,71,61,21,87,97,64,11],eventkindcontrol:64,cbsmayuseinlin:66,firstli:[8,78,64,33,20],com:[1,7,109,97,6,67],builder:67,obj_ap:[21,48,34],well:[0,70,74,23,24,79,63,84,85,93,51,25,6,53,54,57,95,32,66,34,36,78,39,59,10,14,61,16,45,46,105,107,20,102,17,42,87,49],morri:40,thought:[17,59,53],action_find_set_bit:23,exampl:[0,1,95,72,73,74,23,70,76,24,79,81,69,83,84,85,86,22,4,90,25,52,6,91,45,54,28,75,7,29,93,8,64,94,58,113,96,32,9,33,10,36,11,78,38,39,99,59,12,41,101,34,14,104,61,16,111,17,82,46,103,97,105,47,63,88,53,37,106,107,65,48,102,108,21,42,87,68,2,30,67,49],frombt:23,achiev:[99,72,59,93,8,85,81,32,87,101,25,64,78],mpseventcnv:[6,64,17],choos:[69,73,75,85,86,88,26,45,54,27,28,57,94,33,11,38,61,102,104,93,108,48,67,49],undefin:[39,23,41,8,108,63,85,86],amctopgen:28,colour:[54,73,23,13,24,58,83,86,87,44,53,38],btfindshorthigh:23,meter:67,sibl:85,latest:[0,41,20,87,6,17],test1:23,tunabl:28,test2:23,bye:0,paus:[39,47,73,57,8,14,81,32,88,59,78,38],less:[69,72,73,74,23,85,87,88,90,91,102,28,93,8,33,34,38,39,41,14,16,53,47,107,108,66,111,48],conv:[53,23],hybrid:[69,78,75,58,66],pitfal:32,protsetup:43,obtain:[0,28,73,7,13,78,107,20,84,87,97,25,53,38],tcp:64,metrowerk:[6,67,106],topic:[27,104,10,14,63,34,48],trust:88,amcwhiten:28,amcbufferfil:28,heavili:[39,66],increasingli:62,paul:[112,40],zoneshift:8,systemat:[28,72],platform:[1,69,23,77,79,63,83,17,88,90,6,91,64,27,29,93,60,41,15,101,53,103,104,106,20,66,111,49,113,48,67,68],brainpow:33,seghi:24,mps_args_don:[2,12,93,30,10,48,96,4,34,111,36,91,37,46,38,103],web:[109,20],adt:[50,53,85,23,56],rapid:[85,40,20,66],fopen:41,idiom:[52,87],dylan_scan_contig:33,close:[1,39,73,75,7,70,93,90,108,69,34,67],alloct:61,makefil:[6,67],drawback:32,hall:40,script:[6,3,20],add:[102,85,86,3,25,6,64,54,32,34,37,39,99,13,61,16,45,105,19,11,107,20,17,21,66,22,48],lower:[63,8,86,78,38],bibliographi:[27,14,40,39],mps_telemetry_control:[41,17,86,64,38],polici:[1,70,72,73,74,23,79,81,83,69,86,87,90,25,55,28,75,93,8,33,98,40,63,45,107,111,68,48,16],exempt:7,mps_pool_destroi:[98,108,48],ado:33,mps_build_gp:106,match:[39,28,82,61,85,62,16,34,53,37,49],"0x00000001003fb0a0":21,jython:20,freetreeinit:85,branch:[28,73,87,33,102,11,67],mps_message_gc_condemned_s:47,dest:41,"002b":17,hpl:40,multiprocess:40,smart:[87,40,20,88],mps_key_format:[2,12,30,10,48,96,4,34,36,37,46],punctuat:3,allen:40,five:[54,28,74,93,78,99,32,33,46],know:[1,69,71,73,23,76,24,63,82,84,85,90,45,54,28,32,33,37,38,39,99,13,14,61,16,53,46,19,11,21,42,48,49],burden:69,nointersect:66,press:40,somewher:[39,99,15,44],cbsblock:66,tick:11,recurs:[39,59,75,40,56,8,20,82,9,87,58,73,45],"000000019ef60100":101,mps_arena_destroi:[108,17,48,38],motorola:106,resid:[54,72,73,74,83,84,87,88,45],like:[50,69,72,73,23,70,78,81,22,4,52,6,91,45,54,28,75,7,93,8,64,96,32,66,33,10,36,37,38,39,59,12,13,34,14,61,62,63,111,17,103,97,47,53,11,107,20,48,102,94,21,42,51,30,67,88],success:[1,69,24,79,63,82,22,88,53,56,41,38,13,66,14,15,16,64,46,105,20,102,17,108,42,45,51,113],incred:[101,95],errror:99,corpor:40,resio:53,lose:[70,72,76,95,87,66],roth:40,stagger:72,ref_p:108,necessari:[102,70,73,81,82,85,86,17,97,53,56,8,64,32,34,35,38,39,10,43,61,63,30,45,105,29,108,42,113,48,67],subsystem:40,mps_pf_w3i3mv:[67,106],async:[54,44],abysm:66,soft:[25,83,87,88,20],page:[72,73,74,23,78,79,81,82,83,84,65,86,87,88,90,6,28,75,8,58,33,38,39,99,59,40,43,17,46,20,48],amd:106,provok:[13,85,21,39],unreach:[1,69,28,72,73,70,78,97,14,108,20,99,65,21,88,90,98,48,38,49],exceed:[53,13,8,16],revers:[0,39,23,70,24,64,85,86,87,45,48],unit_s:103,captur:73,"0x7fff5fbff3e0":21,mps_os_:67,yarsun:40,linux:[1,56,106,21,10,6,113,67],hain:40,conservat:24,self:[70,85,86,40],certain:[70,72,74,79,83,84,86,87,88,90,25,55,28,32,97,11,38,39,42,14,62,64,107,20,15,66,67],logarithm:106,"_msc_ver":67,superclass:[61,24,45],flush:[0,28,41,24,64,87,16,25,17,48,38],piec:[39,73,56,107,58,32,86,2,38],guarante:[70,74,76,81,83,88,28,56,93,8,32,33,38,39,99,59,41,61,16,46,105,108,66,48,49],contig:8,peter:40,type_weak_t:10,transport:[86,87],proxi:70,kei:[69,72,10,14,94,20,83,61,85,66,3,95,33,34,52,37,105],subramanian:40,amcgen:28,leaf:[27,79,12,75,70,57,42,84,87,4,33,34,26,46,49],borland:20,lead:[72,47,74,75,76,107,78,79,86,21,87,111],broad:53,avoid:[0,69,72,73,74,77,24,79,81,82,22,4,90,25,52,53,55,28,7,56,57,8,33,34,11,38,39,59,60,101,66,100,61,15,63,45,107,17,108,42,87,48,67,88],mps_res_memori:[13,99,16,38],thank:112,overlap:[54,99,41,62,97,38],mutatorfaultcontextstruct:43,mps_arena_park:[30,38,90],leav:[39,28,72,74,23,70,41,61,32,87,33,52,38],disciplin:[88,20],overlai:88,launch:12,speak:[46,74],pollthreshold:8,mps_os_s7:106,mynoteseg:45,"0x1003fe928":21,encourag:[78,107,33],investig:[69,39,36,95],"11a":85,fromspac:[76,70,86,87],firstparampoint:64,slight:[28,93,20,85,22,67],aitr:40,mps_build_cx:106,"enum":[52,66],usag:[47,74,29,78,58,82,85,17,48,38],hosk:[112,73,40,90],facilit:[87,20],paper:[39,17,86,14,85],host:41,formatdestroi:59,obei:[48,88],although:[70,73,75,76,24,81,85,86,87,45,23,56,8,32,9,34,78,39,14,61,63,53,20,66,49],offset:[97,87,46,23,90],ssw3i6mv:67,java:[69,39,40,70,14,20,82,83,108,87,88,90],strlen:34,sigabrt:[17,21],stage:[54,60,85,87,33,42,17,67],divis:[73,74,40,20,83,87,67],mps_fix12:[63,42,46,48,10],rare:[69,79,73,75,13,8,66,86,3,16,90,87,102,48],fri6gc:[6,106],world:[78,14,40,38],ansi:[1,39,73,74,56,41,24,64,63,101,6,17,67],column:[17,64,106],freedom:[84,39,20,61],pedictor:11,justif:[23,60,24,3,25,45],tracer:[54,27,8,58,44,53,11,24],amcinitcomm:28,jouannaud:40,rule:[60,95,108,34,53,48,67],alignof:48,constructor:[39,72,73,75,20,48],fals:[0,55,105,98,23,53,8,66,64,63,48,102,35,85,16,42,25,111,45,46,38],simpl:[73,74,23,88,24,85,86,87,4,6,28,75,56,93,95,32,33,34,11,59,40,41,10,15,101,64,103,107,20,21,42,111,48,67,49],hypothet:45,disabl:[0,25,8,33],conflat:66,sleepycat:7,amcfil:[],successor:85,own:[50,1,73,24,84,86,22,88,6,45,54,56,8,95,41,38,39,99,13,34,14,61,101,53,107,20,102,87,48],absolut:[95,16,75,90],roughli:33,unbox:[74,81,65,87,42,48],around:[74,77,78,85,102,28,56,32,33,10,39,59,41,34,61,64,47,53,65,20,48,49],"0000178ea03c2825":64,tag:[73,74,75,76,63,83,85,86,87,88,90,9,33,10,39,99,34,61,81,102,46,65,20,21,42,48,67,68],eventdef:[17,64],automat:[1,69,72,73,75,88,78,2,81,82,83,51,4,90,26,6,91,27,28,93,30,31,96,32,66,10,36,38,98,39,99,12,40,13,34,14,61,62,16,111,102,46,103,97,47,63,20,94,42,87,113,48,49],assess:28,oop:[21,40],guard:[108,8,45,34],refer:[0,1,71,72,73,74,23,70,76,77,24,79,81,83,69,86,87,4,90,25,26,91,45,54,27,28,75,93,88,30,64,94,58,31,96,32,33,10,35,36,11,78,38,98,39,99,59,12,40,60,13,34,14,112,61,63,44,17,46,103,97,105,19,52,53,113,107,65,20,102,108,21,100,42,92,111,68,95,48,67,49],awhil:16,lund:40,scanner:[27,99,19,60,79,58,33,42,67],tito:40,lockreleasempm:56,hysteresi:[93,8,58],forget:[38,34],mere:[54,79,73,105],merg:[28,105,73,23,24,97,107,58,85,66,64],supernam:45,reg_root:[99,48],mps_fmt_b_:46,behavior:[39,73,40,14,20,87],van:[95,20],obj1struct:45,val:[52,9,37],pictur:[1,54,11],foreign:[70,49,12,90],transfer:[78,79,87,90],construct:[39,72,73,23,14,48,45,37,46,67],findlongresetrang:23,intellig:[79,40,33],poolcreatev:59,trigger:[84,28,90],lockreleaseglobalrecurs:56,inner:[73,23],define_alias_class:45,"var":[45,67,49],protocolclasssuperclasspoli:45,reservoirdeposit:50,"function":[0,50,95,72,73,23,70,76,24,79,80,81,69,83,84,85,22,88,90,25,52,45,54,27,100,75,56,8,60,64,58,9,33,10,35,11,78,38,98,39,99,59,12,40,55,13,101,34,14,43,61,15,16,44,66,17,82,46,1,97,105,63,53,37,41,20,48,102,108,21,62,42,51,87,113,30,67,68],btissetrang:23,north:40,currrent:64,unexpect:[21,48,20,42],unwrap:[83,65,88],refio:28,subsum:54,findlastaft:66,message_typ:0,middleblock:66,mps_debug_class:61,tv_usec:41,collectionstat:25,backtrac:[13,64,21],spuriou:[54,28],grate:112,munro:40,eas:[39,20],highest:[55,111,38,23,88],buf:[13,28,41],poolmark:97,"0x1003f9bf8":21,mps_assert_str:67,count:[69,70,72,23,76,77,78,79,83,87,88,64,28,75,56,95,31,32,34,37,38,39,99,40,61,53,20,92],also:[0,1,71,72,73,74,23,70,76,77,24,79,80,81,69,83,84,85,86,22,4,89,90,25,6,45,54,55,28,75,7,56,8,64,95,92,32,9,33,34,35,78,38,39,99,59,12,40,97,14,43,61,15,16,111,17,82,46,105,47,19,63,2,53,87,107,65,20,48,102,108,109,66,110,51,30,67,88],dmb:74,made:[50,72,74,23,81,82,85,87,45,28,75,29,8,33,34,11,38,39,13,97,61,17,105,19,56,20,102,66,112,67],wise:[76,39,72,40,112],bef:28,clearli:[8,21],lofix:33,o1alcc:106,sac:16,displai:[0,64,14,95,29],troubl:[39,72],asynchron:[0,75,14,48,86,21,87,25,46,38],flip:[54,70,28,74,113,8,58,102,86,44,17,11,53,38],btfindlongresrang:23,supplant:20,scienc:[14,40],indefinit:[28,72,73,75,79,81,82,52],mps_headers:46,fetch:[39,73,33,90],otherwis:[0,1,71,74,23,70,24,83,85,87,4,25,17,54,28,7,56,8,64,33,34,11,38,98,99,59,66,14,62,16,53,46,97,105,47,19,102,108,42],ramsei:40,messagecheck:95,tracesetismemb:8,succe:[0,39,28,8,61,102,11,38],amcreclaimnail:28,attrfre:53,what:[0,1,73,23,70,88,25,52,53,54,28,75,57,8,64,32,33,10,38,39,99,60,13,97,14,61,16,44,45,46,104,47,107,102,21,42,113,48,67,101],block:[0,50,71,72,73,74,75,70,76,77,24,79,81,69,83,85,86,51,4,90,91,64,54,27,28,57,8,94,58,96,32,66,34,36,37,78,38,98,39,99,59,12,55,13,10,14,61,15,16,111,17,46,1,103,105,47,63,88,41,107,20,48,102,93,108,21,62,42,87,2,30,67,49],weakli:[10,20,83,87,88,90],multipli:38,vleck:95,begun:28,evalu:[40,34,81,63,21,16,42,53,102],pascal:[14,20],"int":[70,28,23,87,53,13,8,100,64,99,63,22,101,41,25,52,45,37,48,67],mask:[99,23],dure:[0,70,72,73,23,76,77,24,2,81,83,85,22,88,90,102,54,28,56,8,32,97,11,78,38,39,59,66,61,45,46,105,42,87,48,67,49],year:[73,40],memoiz:[78,73,67],xerox:40,resparam:53,multic:[78,95],sptab:48,implement:[0,50,71,72,73,74,23,70,76,24,79,81,69,83,85,86,51,88,90,25,6,53,54,55,28,75,7,29,93,8,64,58,109,32,9,33,10,35,11,39,111,59,40,60,13,101,34,14,43,61,15,16,66,45,82,1,103,97,105,19,63,41,56,20,102,108,21,100,42,110,87,68,48,67,49],erik:[0,20],ind:28,mistaken:[102,34,10],ing:20,resunimpl:[53,43],eric:40,probabl:[54,39,28,23,70,13,24,64,99,69,83,85,86,87,88,33,25,53,48,38],tricki:[25,28,53,42],zvi:40,sizenews:66,nonetheless:102,allow:[0,50,72,73,74,23,70,78,82,69,86,87,88,2,25,52,6,45,54,55,75,29,8,64,95,32,66,33,34,35,36,11,38,39,99,59,13,10,61,15,16,17,46,97,53,65,20,102,94,109,42,48,67,101],estim:[70,59,20,33,47,11,38],minim:[54,23,40,84,78,20,61,86,16,45,48,67],detail:[1,69,73,23,76,78,81,84,85,87,17,54,55,28,56,58,66,33,34,39,10,14,61,15,63,44,64,105,102,108,42,45,48],virtual:[75,76,78,79,81,82,83,84,65,86,87,88,90,52,27,106,8,58,32,38,39,40,13,14,15,16,102,63,20,48,67,68],mps_fmt_check_fenceposts_t:61,ultrasparc:81,other:[0,1,71,72,73,74,23,70,76,77,24,79,81,69,84,85,86,51,88,90,5,6,45,54,55,28,75,7,29,57,8,64,94,58,96,32,9,33,10,36,11,78,38,98,39,99,111,59,60,13,34,14,43,61,15,16,66,17,46,103,97,105,47,19,63,53,113,56,107,65,20,48,102,93,108,21,42,110,87,95,30,67,49],lookup:[105,74,23,78,81,82,21,101,33,34],futur:[50,69,73,74,75,79,63,83,85,25,52,17,28,58,33,41,11,39,99,59,13,97,62,101,53,47,108,66,45],rememb:[69,70,71,73,23,81,83,87,88,54,56,32,33,11,38,39,99,59,40,53,20,49],varieti:[73,75,24,79,82,84,88,6,17,23,29,11,39,60,13,61,64,20,21,49,67,68],milutinov:40,tightest:107,siginvalid:[8,95],"0x000000010000341f":21,messagedeletemethod:25,"0x00000001003f9a80":21,kent:[112,40],naggum:[0,20],segstruct:[24,28],repeat:[28,105,78,2,61,108,86,34,102,48],attardi:[112,40,20],foostruct:[22,97],"class":[50,1,95,72,73,74,23,70,88,24,2,81,69,83,84,85,51,4,90,25,26,6,91,45,27,28,75,93,30,60,94,58,96,33,10,36,11,38,98,39,99,59,12,55,13,34,100,104,61,15,16,111,17,46,103,97,19,63,52,53,37,20,48,102,108,42,110,87,68,113,8,49],pooldestroi:[59,11,97],june:40,consequenti:[7,97],neeli:40,type_symbol:[102,21,48,34],"9c1e0":64,throughout:[23,107,63,83,86,87,64,48],singleton:[25,24,22],mps_objects_step_t:61,mps_collect:38,vein:75,stai:[75,10],multithread:40,splaynodedescribemethod:85,philipp:40,eof:41,eqv_hash:34,refsig:97,pdp:[89,74,40],reliabl:[1,39,99,105,98,20,54,32,21,67,34,102,48,38],martin:[112,40],indirectli:[45,39,24,32,83],comparison:[53,66,85,105,34],pool_class:46,gdbinit:[17,21],portion:[28,73,23,15,88,90,38],emerg:[28,8,34,58,108,33,66],rhsk:[28,11],auxiliari:[88,81,44,49],suballoc:[39,76,107,14,81,31,87],decemb:40,invari:[28,81,13,24,100,58,83,86,87,20,44,97],emeri:40,mps_io_flush:[41,17]},objtypes:{"0":"std:option","1":"std:envvar","2":"c:function","3":"c:macro","4":"c:type"},titles:["12. Messages","1. Overview of the Memory Pool System","18. Debugging pools","3. Transliterating the alphabet into hexadecimal","5. AMCZ (Automatic Mostly-Copying Zero-rank)","27. Software versions","2. Building the Memory Pool System","Memory Pool System Kit Open Source License","1. Arena","4. Checking","7. AWL (Automatic Weak Linked)","24. Tracer","8. LO (Leaf Object)","3. Error handing","1. Overview","28. Virtual mapping","15. Segregated allocation caches","19. Telemetry","Memory Management Glossary","19. The generic scanner","4. Memory management in various languages","4. Debugging with the Memory Pool System","5. Ring data structure","2. Bit tables","20. Segment data structure","10. Client message protocol","Pool reference","Memory Pool System","13. AMC pool class","26. Library version mechanism","4. AMC (Automatic Mostly-Copying)","Introduction to memory management","3. Recycling techniques","2. The critical path through the MPS","6. Advanced topics","8. The generic fix function","6. AMS (Automatic Mark and Sweep)","2. Keyword arguments","4. Arenas","5. Frequently Asked Questions","Bibliography","21. Plinth","8. Scanning","15. The protection module","18. Root manager","16. Protocol inheritance","7. Object formats","11. Garbage collection","3. Garbage collecting a language with the Memory Pool System","1. Choosing a pool class","17. The low-memory reservoir","17. Allocation frames","4. Keyword arguments in the MPS","25. General MPS types","6. Collection framework","14. Manually-Managed Variable-Size First-Fit Pool","9. The lock module","5. Tuning the Memory Pool System for performance","Old design","23. Thread safety in the MPS","Design","11. Debugging features for client objects","16. Allocation patterns","1. Interface conventions","22. Telemetry","Memory Management Glossary: U","3. Coalescing block structure","1. MPS Configuration","Reference","Memory Management Glossary: G","Memory Management Glossary: F","Memory Management Glossary: E","Memory Management Glossary: D","Memory Management Glossary: C","Memory Management Glossary: B","Memory Management Glossary: A","Memory Management Glossary: O","Memory Management Glossary: N","Memory Management Glossary: M","Memory Management Glossary: L","Memory Management Glossary: K","Memory Management Glossary: I","Memory Management Glossary: H","Memory Management Glossary: W","Memory Management Glossary: V","21. Splay trees","Memory Management Glossary: T","Memory Management Glossary: S","Memory Management Glossary: R","Memory Management Glossary: Q","Memory Management Glossary: P","10. MV (Manual Variable)","Memory Management Glossary: Z","12. MVT (Manual Variable Temporal)","20. Weak references","6. Signatures in the MPS","13. SNC (Stack No Checking)","5. Pool class interface","5. Pools","10. Roots","7. Finalization","29. The WriteF function","6. Allocation","9. MFS (Manual Fixed Small)","Guide","14. Location dependency","22. Platforms","2. Allocation techniques","13. Finalization","Contact us","12. Pool and pool class mechanisms","11. MVFF (Manual Variable First Fit)","Acknowledgements","9. Threads"],objnames:{"0":["std","option","option"],"1":["std","envvar","environment variable"],"2":["c","function","C function"],"3":["c","macro","C macro"],"4":["c","type","C type"]},filenames:["topic/message","guide/overview","topic/debugging","design/guide.hex.trans","pool/amcz","design/version","guide/build","copyright","design/arena","design/check","pool/awl","design/trace","pool/lo","topic/error","mmref/begin","design/vm","topic/cache","topic/telemetry","glossary/index","design/scan","mmref/lang","guide/debug","design/ring","design/bt","design/seg","design/message","pool/index","index","design/poolamc","design/version-library","pool/amc","mmref/index","mmref/recycle","design/critical-path","guide/advanced","design/fix","pool/ams","topic/keyword","topic/arena","mmref/faq","mmref/bib","topic/plinth","topic/scanning","design/prot","design/root","design/protocol","topic/format","topic/collection","guide/lang","pool/intro","design/reservoir","topic/frame","design/keyword-arguments","design/type","design/collection","design/poolmvff","design/lock","guide/perf","design/old","design/thread-safety","design/index","design/object-debug","topic/pattern","topic/interface","design/telemetry","glossary/u","design/cbs","design/config","topic/index","glossary/g","glossary/f","glossary/e","glossary/d","glossary/c","glossary/b","glossary/a","glossary/o","glossary/n","glossary/m","glossary/l","glossary/k","glossary/i","glossary/h","glossary/w","glossary/v","design/splay","glossary/t","glossary/s","glossary/r","glossary/q","glossary/p","pool/mv","glossary/z","pool/mvt","topic/weak","design/sig","pool/snc","design/class-interface","topic/pool","topic/root","design/finalize","design/writef","topic/allocation","pool/mfs","guide/index","topic/location","topic/platform","mmref/alloc","topic/finalization","contact","design/pool","pool/mvff","mmref/credit","topic/thread"]})
\ No newline at end of file
+Search.setIndex({objects:{"":{mps_ap_frame_select:[7,2,1,""],mps_ap_alloc_pattern_reset:[131,2,1,""],mps_arena_roots_walk:[120,2,1,""],ReservoirLimit:[63,2,1,""],MPS_SAC_CLASS_LIMIT:[19,3,1,""],SplayTreeFirst:[103,2,1,""],ArenaSetTotalLoci:[24,2,1,""],"-d":[21,0,1,"cmdoption-mpseventsql-d"],SplayTreeInit:[103,2,1,""],"-f":[21,0,1,"cmdoption-mpseventsql-f"],AllocFrame:[7,4,1,""],"-l":[21,0,1,"cmdoption-mpseventtxt-l"],"-o":[21,0,1,"cmdoption-mpseventsql-o"],"-i":[21,0,1,"cmdoption-mpseventsql-i"],mps_sac_create:[19,2,1,""],mps_arena_step:[45,2,1,""],"-t":[21,0,1,"cmdoption-mpseventsql-t"],mps_telemetry_flush:[21,2,1,""],"-v":[21,0,1,"cmdoption-mpseventsql-v"],"-p":[21,0,1,"cmdoption-mpseventsql-p"],"-r":[21,0,1,"cmdoption-mpseventsql-r"],CONFIG_VAR_RASH:[14,3,1,""],SplayNodeInit:[103,2,1,""],MPS_ARCH_I3:[132,3,1,""],mps_root_create_table:[120,2,1,""],mps_class_ams:[43,2,1,""],mps_sac_t:[19,4,1,""],mps_pool_debug_option_s:[2,4,1,""],MPS_WORD_WIDTH:[132,3,1,""],mps_tramp:[140,2,1,""],mps_class_amc:[37,2,1,""],LockReleaseGlobalRecursive:[70,2,1,""],MessageClass:[32,4,1,""],SplayTreeSearch:[103,2,1,""],mps_arena_create:[45,2,1,""],Rank:[66,4,1,""],BufferOfAP:[107,2,1,""],AMCScan:[35,2,1,""],Ring:[27,4,1,""],BTFindShortResRangeHigh:[29,2,1,""],Res:[66,4,1,""],ThreadRegister:[118,2,1,""],MPS_PF_W3I3MV:[132,3,1,""],mps_io_write:[49,2,1,""],Ref:[66,4,1,""],mps_arena_class_vm:[45,2,1,""],BTCopyInvertRange:[29,2,1,""],mps_ap_set_frame_class:[7,2,1,""],MPS_PF_XCI3LL:[132,3,1,""],mps_amc_apply_stepper_t:[37,4,1,""],mps_rank_weak:[120,2,1,""],mps_clock:[49,2,1,""],mps_ss_t:[84,4,1,""],mps_arena_unsafe_restore_protection:[45,2,1,""],mps_free:[125,2,1,""],Arena:[8,4,1,""],ThreadRingResume:[118,2,1,""],AMCBufferFill:[35,2,1,""],MRGScan:[57,2,1,""],mps_clocks_per_sec:[49,2,1,""],MPS_RES_OK:[14,3,1,""],SplayNodeStruct:[103,4,1,""],mps_message_gc_live_size:[58,2,1,""],Reservoir:[63,4,1,""],MRGCheck:[57,2,1,""],PThreadext:[52,4,1,""],MPS_PF_STRING:[132,3,1,""],Serial:[66,4,1,""],mps_addr_fmt:[55,2,1,""],mps_lib_telemetry_control:[49,2,1,""],mps_rank_t:[120,4,1,""],BufferFill:[107,2,1,""],PThreadextResume:[52,2,1,""],"-h":[21,0,1,"cmdoption-mpseventcnv-h"],LockReleaseGlobal:[70,2,1,""],mps_frame_class_t:[7,4,1,""],mps_telemetry_get:[21,2,1,""],Bool:[66,4,1,""],MPS_TELEMETRY_CONTROL:[21,1,1,"-"],mps_ld_merge:[128,2,1,""],BufferArena:[107,2,1,""],ProtSet:[51,2,1,""],COMPATLVALUE:[69,2,1,""],PThreadextInit:[52,2,1,""],AWLSegAlloc:[141,2,1,""],Count:[66,4,1,""],mps_io_receive:[74,2,1,""],BTSetRange:[29,2,1,""],SplayTreeCheck:[103,2,1,""],PoolSetFrameClassMethod:[7,4,1,""],mps_fmt_fwd_t:[55,4,1,""],MPS_ARGS_BEGIN:[44,2,1,""],AllocFrameClass:[7,4,1,""],BTFindLongResRange:[29,2,1,""],MutatorFaultContext:[51,4,1,""],ProtCanStepInstruction:[51,2,1,""],BufferSegMethod:[107,4,1,""],mps_sac_class_s:[19,4,1,""],BTSet:[29,2,1,""],mps_arena_unsafe_expose_remember_protection:[45,2,1,""],MessageFinish:[32,2,1,""],awlSegFinish:[141,2,1,""],mps_arena_t:[45,4,1,""],mps_ld_reset:[128,2,1,""],LockFinish:[70,2,1,""],mps_root_create_fmt:[120,2,1,""],MPS_SCAN_BEGIN:[84,2,1,""],mps_arena_committed:[45,2,1,""],MPS_ARCH_I6:[132,3,1,""],mps_arena_commit_limit_set:[45,2,1,""],mps_pool_create:[119,2,1,""],MPS_RES_RESOURCE:[14,3,1,""],MPS_ARGS_END:[44,2,1,""],mps_frame_t:[64,4,1,""],mps_telemetry_intern:[21,2,1,""],loSegReclaim:[28,2,1,""],mps_thread_dereg:[140,2,1,""],AWLFinish:[141,2,1,""],MessageInit:[32,2,1,""],TraceId:[66,4,1,""],Attr:[66,4,1,""],BufferAttach:[107,2,1,""],BufferInitMethod:[107,4,1,""],BTResRange:[29,2,1,""],mps_lib_fputs:[49,2,1,""],MPS_BUILD_LL:[132,3,1,""],mps_fmt_class_t:[55,4,1,""],RING_FOR:[27,2,1,""],Pointer:[66,4,1,""],ProtocolClassSuperclassPoly:[54,2,1,""],BTRes:[29,2,1,""],LOReclaim:[28,2,1,""],mps_telemetry_reset:[21,2,1,""],SplayTreeNeighbours:[103,2,1,""],ThreadRingSuspend:[118,2,1,""],mps_lib_memset:[49,2,1,""],SplayTreeDelete:[103,2,1,""],mps_io_destroy:[49,2,1,""],ReservoirFinish:[63,2,1,""],LockInit:[70,2,1,""],mps_definalize:[135,2,1,""],AWLDescribe:[141,2,1,""],MPS_FIX12:[84,2,1,""],mps_class_mv_debug:[109,2,1,""],PThreadextStruct:[52,4,1,""],mps_reserve:[125,2,1,""],mps_addr_t:[79,4,1,""],mps_class_lo:[13,2,1,""],SplayTreeFinish:[103,2,1,""],mps_rank_exact:[120,2,1,""],mps_key_t:[44,4,1,""],mps_ap_s:[125,4,1,""],mps_chain_create:[58,2,1,""],ShieldRaise:[15,2,1,""],mps_ap_t:[125,4,1,""],IsSubclassPoly:[54,2,1,""],mps_reg_scan_t:[120,4,1,""],mps_rank_ambig:[120,2,1,""],AMCFix:[35,2,1,""],AWLSegCreate:[141,2,1,""],mps_arena_clamp:[45,2,1,""],mps_gen_param_s:[58,4,1,""],mps_arena_formatted_objects_walk:[55,2,1,""],VMDestroy:[18,2,1,""],MPS_T_WORD:[132,3,1,""],mps_fmt_create_auto_header:[55,2,1,""],mps_lib_FILE:[49,4,1,""],MPS_FIX2:[84,2,1,""],mps_message_clock:[0,2,1,""],mps_fmt_put_fencepost_t:[77,2,1,""],ReservoirCheck:[63,2,1,""],mps_mvt_size:[112,2,1,""],AWLGrey:[141,2,1,""],MPS_RES_MEMORY:[14,3,1,""],mps_root_create_table_masked:[120,2,1,""],mps_sac_free:[19,2,1,""],mps_stack_scan_ambig:[120,2,1,""],mps_ld_s:[128,4,1,""],mps_arena_collect:[45,2,1,""],BufferDestroy:[107,2,1,""],mps_sac_alloc:[19,2,1,""],mps_message_type:[0,2,1,""],mps_peak_describe_pool:[24,2,1,""],mps_lib_assert_fail_t:[49,4,1,""],mps_arena_spare_commit_limit_set:[45,2,1,""],mps_arena_create_v:[45,2,1,""],mps_alloc_pattern_t:[131,4,1,""],BufferFinishMethod:[107,4,1,""],Word:[66,4,1,""],BufferTrip:[107,2,1,""],mps_class_awl:[11,2,1,""],LockReleaseRecursive:[70,2,1,""],ReservoirEnsureFull:[63,2,1,""],mps_commit:[125,2,1,""],mps_message_t:[0,4,1,""],mps_alloc:[125,2,1,""],mps_message_type_enable:[0,2,1,""],mps_arena_class_cl:[45,2,1,""],MPS_WORD_SHIFT:[132,3,1,""],mps_lib_fputc:[49,2,1,""],TractOfAddr:[8,2,1,""],BTCopyOffsetRange:[29,2,1,""],mps_pool_check_free_space:[2,2,1,""],mps_fmt_create_A:[55,2,1,""],mps_fmt_create_B:[55,2,1,""],SplayNode:[103,4,1,""],AWLCondemn:[141,2,1,""],AWLReclaim:[141,2,1,""],Addr:[66,4,1,""],Index:[66,4,1,""],mps_message_queue_type:[0,2,1,""],SegSplit:[30,2,1,""],MVFFInit:[48,2,1,""],MPS_PF_W3I6MV:[132,3,1,""],mps_roots_stepper_t:[120,4,1,""],mps_lib_get_stdout:[49,2,1,""],SegMergeMethod:[30,4,1,""],LockReleaseMPM:[70,2,1,""],AccessSet:[66,4,1,""],mps_pool_create_v:[119,2,1,""],mps_fmt_scan_t:[55,4,1,""],ClassOfPoly:[54,2,1,""],MPS_RES_IO:[14,3,1,""],mps_thread_reg:[140,2,1,""],LockClaimGlobal:[70,2,1,""],mps_message_get:[0,2,1,""],mps_message_gc_condemned_size:[58,2,1,""],LocusCreate:[24,2,1,""],BTIsResRange:[29,2,1,""],SplayRoot:[103,2,1,""],MPS_ARGS_ADD:[44,2,1,""],BTSize:[29,2,1,""],mps_pool_create_k:[119,2,1,""],MPS_SAC_ALLOC_FAST:[19,2,1,""],Seg:[30,4,1,""],mps_lib_assert_fail:[49,2,1,""],mps_message_type_gc:[58,2,1,""],MPS_RES_COMMIT_LIMIT:[14,3,1,""],MPS_OS_XC:[132,3,1,""],mps_ap_frame_push:[64,2,1,""],BufferCommit:[107,2,1,""],MPS_ARGS_DONE:[44,2,1,""],mps_message_type_disable:[0,2,1,""],PThreadextCheck:[52,2,1,""],mps_thr_t:[140,4,1,""],BufferDescribeMethod:[107,4,1,""],ThreadScan:[118,2,1,""],PThreadextSuspend:[52,2,1,""],BTCopyRange:[29,2,1,""],PoolFramePushMethod:[7,4,1,""],mps_peak_destroy:[24,2,1,""],mps_class_ams_debug:[43,2,1,""],MPS_BUILD_MV:[132,3,1,""],"(RingInsert)":[27,2,1,""],mps_mv_size:[109,2,1,""],CONFIG_VAR_HOT:[14,3,1,""],mps_tramp_t:[140,4,1,""],mps_ap_frame_pop:[64,2,1,""],mps_fmt_t:[55,4,1,""],mps_class_mfs:[126,2,1,""],DEFINE_CLASS:[54,2,1,""],RingInit:[27,2,1,""],MPS_PF_XCI6LL:[132,3,1,""],BTFindLongResRangeHigh:[29,2,1,""],MRGDescribe:[57,2,1,""],mps_pool_t:[119,4,1,""],SplayTreeDescribe:[103,2,1,""],MPS_RES_LIMIT:[14,3,1,""],mps_fmt_destroy:[55,2,1,""],mps_message_poll:[0,2,1,""],mps_fmt_fencepost_wrap:[77,2,1,""],ProtStepInstruction:[51,2,1,""],ShieldResume:[15,2,1,""],Fun:[66,4,1,""],ACT_ON_RANGE:[29,2,1,""],AWLDependentObject:[141,2,1,""],mps_clock_t:[79,4,1,""],mps_fmt_A_s:[55,4,1,""],MPS_OS_W3:[132,3,1,""],Byte:[66,4,1,""],mps_ap_alloc_pattern_begin:[131,2,1,""],mps_fmt_pad_t:[55,4,1,""],mps_alloc_frame_class_stack:[7,2,1,""],SplayNodeFinish:[103,2,1,""],mps_fix:[84,2,1,""],ACT_ON_RANGE_HIGH:[29,2,1,""],mps_arena_start_collect:[45,2,1,""],BufferReserve:[107,2,1,""],mps_sac_destroy:[19,2,1,""],AMCFinish:[35,2,1,""],MPS_T_ULONGEST:[132,3,1,""],LockClaimGlobalRecursive:[70,2,1,""],mps_lib_get_EOF:[49,2,1,""],mps_mvff_size:[138,2,1,""],mps_chain_t:[58,4,1,""],mps_root_create:[120,2,1,""],ReservoirWithdraw:[63,2,1,""],MPS_RESERVE_BLOCK:[125,2,1,""],MPS_PF_XCI3GC:[132,3,1,""],mps_arena_has_addr:[45,2,1,""],mps_formatted_objects_stepper_t:[55,4,1,""],MPS_RES_UNIMPL:[14,3,1,""],Epoch:[66,4,1,""],TraceSet:[66,4,1,""],LockSize:[70,2,1,""],mps_sac_flush:[19,2,1,""],BufferRankSetMethod:[107,4,1,""],ReservoirAvailable:[63,2,1,""],ShieldSuspend:[15,2,1,""],mps_arena_reserved:[45,2,1,""],MPS_RES_PARAM:[14,3,1,""],mps_fmt_auto_header_s:[55,4,1,""],ReservoirSetLimit:[63,2,1,""],mps_ld_add:[128,2,1,""],Accumulation:[66,4,1,""],mps_ap_destroy:[125,2,1,""],SplayNodeDescribeMethod:[103,4,1,""],SplayCompareMethod:[103,4,1,""],mps_class_mv:[109,2,1,""],CHECKD:[10,2,1,""],CONFIG_PLINTH_NONE:[49,3,1,""],AMCReclaim:[35,2,1,""],ShieldLower:[15,2,1,""],mps_fmt_isfwd_t:[55,4,1,""],CHECKU:[10,2,1,""],COMPATTYPE:[69,2,1,""],CHECKS:[10,2,1,""],mps_arena_destroy:[45,2,1,""],mps_io_create:[49,2,1,""],SplayTreeInsert:[103,2,1,""],MPS_BUILD_GC:[132,3,1,""],MPS_RM_PROT:[120,3,1,""],mps_arena_spare_committed:[45,2,1,""],SUPERCLASS:[54,2,1,""],RefSet:[66,4,1,""],MPS_OS_LI:[132,3,1,""],SplayNodeRefresh:[103,2,1,""],MPS_TELEMETRY_FILENAME:[21,1,1,"-"],RING_ELT:[27,2,1,""],mps_pool_check_fenceposts:[2,2,1,""],MPS_RM_CONST:[120,3,1,""],mps_peak_create:[24,2,1,""],mps_arena_extend:[45,2,1,""],AWLScan:[141,2,1,""],mps_collections:[45,2,1,""],MRGRegister:[57,2,1,""],mps_arena_commit_limit:[45,2,1,""],BufferIsReady:[107,2,1,""],Align:[66,4,1,""],mps_mv_free_size:[109,2,1,""],CHECKL:[10,2,1,""],mps_objects_step_t:[77,2,1,""],MPS_RES_FAIL:[14,3,1,""],mps_arena_spare_commit_limit:[45,2,1,""],SplayTreeStruct:[103,4,1,""],mps_ap_create_v:[125,2,1,""],mps_align_t:[79,4,1,""],mps_arena_expose:[45,2,1,""],AMCBufferEmpty:[35,2,1,""],mps_ap_alloc_pattern_end:[131,2,1,""],mps_ap_create_k:[125,2,1,""],ProtocolClass:[54,4,1,""],mps_lib_memcpy:[49,2,1,""],Size:[66,4,1,""],MPS_FIX1:[84,2,1,""],BTCreate:[29,2,1,""],MessageEmpty:[32,2,1,""],mps_message_type_finalization:[135,2,1,""],LockClaimRecursive:[70,2,1,""],PThreadextFinish:[52,2,1,""],SplayTestTreeMethod:[103,4,1,""],ULongest:[66,4,1,""],PoolFrameSelectFromAddrMethod:[7,4,1,""],mps_root_destroy:[120,2,1,""],SplayFindFirst:[103,2,1,""],mps_word_t:[79,4,1,""],SplayUpdateNodeMethod:[103,4,1,""],MPS_FIX_CALL:[84,2,1,""],mps_arena_class_t:[45,4,1,""],mps_res_t:[14,4,1,""],mps_bool_t:[79,4,1,""],BufferPool:[107,2,1,""],mps_fmt_adjust_fencepost_t:[77,2,1,""],BufferCheck:[107,2,1,""],mps_ld_isstale:[128,2,1,""],BufferDetachMethod:[107,4,1,""],mps_addr_pool:[119,2,1,""],mps_fmt_skip_t:[55,4,1,""],mps_io_t:[49,4,1,""],RingAppend:[27,2,1,""],mps_ap_trip:[125,2,1,""],SegSplitMethod:[30,4,1,""],MPS_ARGS_ADD_FIELD:[44,2,1,""],mps_lib_memcmp:[49,2,1,""],MPS_PF_FRI3GC:[132,3,1,""],mps_root_create_reg:[120,2,1,""],RingFinish:[27,2,1,""],MPS_OS_FR:[132,3,1,""],SegMerge:[30,2,1,""],BT:[29,4,1,""],ReservoirInit:[63,2,1,""],LockClaim:[70,2,1,""],PoolAddrInFrameMethod:[7,4,1,""],mps_lib_get_stderr:[49,2,1,""],mps_pool_destroy:[119,2,1,""],MPS_TELEMETRY_DATABASE:[21,1,1,"-"],mps_message_type_gc_start:[58,2,1,""],mps_ap_create:[125,2,1,""],mps_telemetry_control:[21,2,1,""],DEFINE_ALIAS_CLASS:[54,2,1,""],SplayTree:[103,4,1,""],MRGInit:[57,2,1,""],BTFindResRangeHigh:[29,2,1,""],mps_ap_frame_select_from_addr:[7,2,1,""],Thread:[118,4,1,""],PoolFramePopMethod:[7,4,1,""],SplayTestNodeMethod:[103,4,1,""],SplayNodeCheck:[103,2,1,""],GCSeg:[30,4,1,""],BTIsSetRange:[29,2,1,""],mps_awl_find_dependent_t:[11,4,1,""],MPS_SCAN_END:[84,2,1,""],AWLFix:[141,2,1,""],MPS_SAC_FREE_FAST:[19,2,1,""],MPS_PF_LII3GC:[132,3,1,""],INHERIT_CLASS:[54,2,1,""],"(BufferAP)":[107,2,1,""],ProtSetup:[51,2,1,""],ProtSync:[51,2,1,""],VMCreate:[18,2,1,""],mps_class_amcz:[4,2,1,""],mps_message_finalization_ref:[135,2,1,""],mps_lib_assert_fail_install:[49,2,1,""],mps_args_none:[44,3,1,""],ArenaFinalize:[121,2,1,""],mps_arena_park:[45,2,1,""],Shift:[66,4,1,""],mps_mvff_free_size:[138,2,1,""],mps_message_discard:[0,2,1,""],ProtTramp:[51,2,1,""],mps_message_type_t:[0,4,1,""],mps_alloc_pattern_ramp_collect_all:[131,2,1,""],mps_root_scan_t:[120,4,1,""],BufferIsReset:[107,2,1,""],mps_pool_walk:[77,2,1,""],ThreadDeregister:[118,2,1,""],mps_root_t:[120,4,1,""],mps_class_mvff_debug:[138,2,1,""],mps_ap_fill:[125,2,1,""],COMPATFIELD:[69,2,1,""],mps_ap_addr_in_frame:[7,2,1,""],mps_telemetry_label:[21,2,1,""],Message:[32,4,1,""],mps_message_gc_not_condemned_size:[58,2,1,""],PoolFrameSelectMethod:[7,4,1,""],mps_mvt_free_size:[112,2,1,""],mps_arena_walk:[77,2,1,""],MPS_PF_ALIGN:[132,3,1,""],COMPATFIELDAPPROX:[69,2,1,""],MRGFinish:[57,2,1,""],BTFindResRange:[29,2,1,""],MessageStruct:[32,4,1,""],mps_class_mvff:[138,2,1,""],mps_label_t:[79,4,1,""],MPS_PF_FRI6GC:[132,3,1,""],AWLInit:[141,2,1,""],BTDestroy:[29,2,1,""],mps_class_snc:[115,2,1,""],mps_message_gc_start_why:[58,2,1,""],BTFindShortResRange:[29,2,1,""],MRGDeregister:[57,2,1,""],mps_alloc_pattern_ramp:[131,2,1,""],RootVar:[66,4,1,""],mps_amc_apply:[37,2,1,""],mps_debug_class:[77,2,1,""],BufferSetRankSetMethod:[107,4,1,""],mps_arena_release:[45,2,1,""],Compare:[66,4,1,""],AWLBufferFill:[141,2,1,""],ReservoirDeposit:[63,2,1,""],mps_io_send:[74,2,1,""],"(RingRemove)":[27,2,1,""],MessagePost:[32,2,1,""],mps_class_t:[119,4,1,""],BTGet:[29,2,1,""],mps_fmt_B_s:[55,4,1,""],BufferCreate:[107,2,1,""],mps_ld_t:[128,4,1,""],mps_peak_close:[24,2,1,""],mps_fmt_check_fenceposts_t:[77,2,1,""],BufferDetach:[107,2,1,""],WriteF:[123,2,1,""],mps_finalize:[135,2,1,""],LOFix:[28,2,1,""],AWLBufferEmpty:[141,2,1,""],MPS_PF_LII6GC:[132,3,1,""],awlSegInit:[141,2,1,""],mps_arena_create_k:[45,2,1,""],BufferAttachMethod:[107,4,1,""],mps_chain_destroy:[58,2,1,""],CONFIG_VAR_COOL:[14,3,1,""],SplayTreeNext:[103,2,1,""],mps_arg_s:[44,4,1,""],mps_telemetry_set:[21,2,1,""],mps_rm_t:[120,4,1,""],mps_class_mvt:[112,2,1,""],mps_io_flush:[49,2,1,""]}},terms:{scriptwork:[48,85],circuitri:96,prefin:57,orthogon:[47,62],messagefinalizationrefmethod:32,interchang:[89,106],four:[46,35,57,92,29,83,104,120,134,101,82,10,106,107,109,141],prefix:[69,92,8,79,80,6,85],ru_utim:49,payoff:[35,72],find_depend:11,mpsioan:49,freeblocktesttre:103,mps_telemetry_flush:[49,21,45],underwrit:[77,2],prot_foo:85,digit:[34,47,68,96,132,72,3,83,124,6],mps_thr_:118,pageretstruct:35,addrstruct:66,lastcollect:141,wasold:57,factori:106,terabyt:[104,92],p_o:[125,26,19],mps_lib_get_stdout:[49,80,50],cxref:132,second:[125,96,99,103,27,107,21,35,132,71,9,40,41,12,45,76,49,50,80,24,118,54,105,141,61,62],type_fwd:61,p_v:[125,19],ap_o:[115,125,11],amcgenstruct:35,mpscmvff:138,mps_ss_t:[120,11,84,55,113,105,40,41,61],singhal:[47,108],ongo:130,avert:[54,69,114],splinter:[77,8],here:[0,29,97,103,107,32,6,125,67,35,69,36,71,8,72,40,41,117,12,45,74,120,14,130,77,18,20,21,81,56,128,58,24,135,26,84,141,61,85,62],mps_message_type_dis:[0,32],basereturn:[63,35,103,29,141],norsk:47,keysig:65,bufferattach:107,brought:72,unix:[87,34,69,92,68,94,14,96,117,51,72,52,105,106,114,49,124,6,140,66,85],mps_class_am:[43,44],map_shar:78,txt:[21,52,85],unit:[67,35,61,91,92,83,94,24,8,49,55,90,106,40,108,20,66,141,30,96,126],buckets_find_depend:41,"0x1003fb148":26,collectionstatscondemneds:32,until:[0,63,91,93,88,94,95,99,103,104,105,116,107,108,35,70,8,9,114,39,41,117,45,119,46,120,13,130,15,121,52,131,19,125,55,128,58,23,24,135,84,61,141],buddi:[88,90,92,47,46,133,99,38,101,105],relax:[107,41],traceseggreyen:141,relat:[87,88,89,90,91,92,93,94,95,96,97,98,99,101,102,82,104,21,106,107,108,80,35,72,39,10,118,46,50,16,52,20,66,55,128,23,25,54,105],notic:[47,29,59,24,79,27,108,32,20,12],exce:[46,58,29,112,8,21],mps_pf_string:[132,85,36],harmless:[77,131],hole:24,hold:[0,88,89,92,29,96,99,27,106,6,80,35,7,70,8,41,45,119,120,130,78,19,66,55,127,58,24,105,125,135,64,140,62],featru:85,generalis:[123,141],btsetrang:29,mccaughan:139,conceptu:[18,130],arenafinish:8,jelica:47,caution:[120,11,135,41,33,125,55,86],fibonacci:[88,133,92],want:[63,1,29,30,87,103,106,107,108,32,6,66,67,69,8,80,39,41,44,45,74,46,120,50,14,15,77,18,19,20,21,81,55,56,24,49,61,26,118,37,141],mysegclass:54,mps_key_mvt_reserve_depth:[112,44],type1:69,type2:69,classifi:[88,108],revisit:[24,47],how:[0,1,90,91,92,29,88,30,130,114,103,104,27,106,107,32,134,67,35,69,59,8,9,72,39,40,11,117,119,96,45,74,46,120,50,75,47,76,14,41,16,52,77,18,19,20,21,55,56,57,58,24,133,61,60,26,84,3,141,28,85,62],hot:[91,14,100,102,21,106,40,49,6,80,85],symposium:47,perspect:[47,11],some_pool_class:65,"0x0000000100011ded":26,diagram:[74,91,103,72,9,107,125,73,28],rightneighbour:103,wrong:[46,127,58,112,14,16,114,26,27,40,138,75,66,109,61],typep:35,isvalid:[20,75],mps_fmt_a_:[61,55,41],alias:[54,40],type_:[61,11],finalis:[116,70],finaliz:[57,101,42,135,106,41,32],feedback:[34,35,50,130,72,60,136],murali:47,appar:[69,56],vari:[46,91,88,71,112,103,105,40,12,85],shieldmod:123,fit:[87,88,89,90,2,92,29,95,30,97,99,101,105,106,108,33,109,125,67,34,35,93,59,71,38,96,46,47,48,18,20,66,126,57,24,133,134,112,131,138,141,85,62],fix:[0,63,90,91,93,88,97,99,105,106,108,33,134,80,67,34,35,69,7,11,8,76,72,39,40,41,42,12,118,46,120,68,14,15,16,77,122,141,21,55,1,126,116,57,23,24,61,125,113,26,84,137,86,28,85,62],sunos4:78,fig:[69,103,27,85,134],hidden:[39,121,120,25],easier:[67,46,75,133,16,123,20,141],poolclass:[75,137,107,116,54,66,21],nygaard:25,proce:[1,67,128,14,52,99,104,40,84,138,12,45,141],poolfix:[137,57,40],interrupt:[74,46,59,15,52,9,20,56],itanium:132,mps_messag:50,codewarrior:[6,85,132],queuer:114,accommod:[87,24,57,19,55],dest_ld:128,timeout:74,debug:[0,90,93,103,104,21,114,2,6,109,54,34,7,70,37,80,72,39,49,43,45,74,14,41,16,77,19,66,55,127,125,26,118,138,61,85,86],vmcreat:[78,21,18,124],resum:[15,140,51,118,52],btfindshortresrang:29,pool_superclass:54,dsm:12,adapt:[1,47,24,103,136,65,139],thw3:118,protocolclass:54,freeblock:103,shieldent:[117,15],navig:16,given:[89,90,93,94,96,99,101,103,2,32,21,67,35,39,41,44,46,120,49,121,52,77,18,19,80,24,54,61],omiss:65,renegoti:24,mps_commit:[125,26,61,41],atc:[104,93],epvm:[39,7,29],ringinsert:27,unabl:[37,45],"__int_64":[79,132],bufferstruct:116,confus:[93,105,123,107,32,66,61],tracestart:[50,12],clariti:[14,66,120],wast:[35,75,29,71,133,15,16,99,19,108,126],wash:74,instruct:[125,68,2,92,47,96,97,16,51,25,136,82,104,105,99,40,11,66,61,56],contextreturn:52,wasn:[35,69,7,14,19,40],splaytreedelet:103,flagella:[47,25],evolut:75,signext:[81,56],similarli:[84,19,29,41],hewitt:[89,47],amsblacken:39,mps_fill_fencepost:77,tractofaddr:[8,12],recherch:47,mps_clock_t:[0,49,79],technic:[1,67,127,47,50,138,55,62],outlaw:39,lvalu:[125,69,19],tree:[34,93,88,8,72,100,60,77,103,105,99,6],project:[1,127,47,25,136,6,61,85],mpmtype:[66,123,29],selectframeofaddr:7,searchlimit:29,buffercommit:[75,107],uniniti:[30,114,39,107,125,61],entail:[57,91,9,18,40,55],stream_fputc:50,increment:[1,87,91,92,88,96,97,99,101,104,105,106,107,108,66,67,35,8,9,39,11,12,45,46,47,14,15,130,80,116,25,125,141,140,61,62],infring:[20,59],splaynodeinit:103,logroup:28,irrevoc:24,pretenur:47,eagerli:7,simplifi:[1,87,57,92,29,88,84,104,114,77,39,93,4,41],shall:[69,59,29,24,8,79,134,20],object:[0,1,2,27,4,6,7,8,9,10,11,12,13,14,15,16,18,19,21,23,24,25,26,28,29,30,32,33,34,35,36,37,38,39,40,41,42,43,45,46,47,50,52,53,54,55,56,57,58,60,61,62,63,66,67,48,69,70,71,72,77,78,79,80,81,82,84,86,87,88,89,90,91,92,93,94,95,96,97,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,118,120,121,122,125,126,127,132,133,134,135,137,138,141],specifi:[0,63,61,91,29,88,2,99,87,103,4,107,108,32,65,109,80,48,35,69,8,113,115,11,43,44,119,46,120,13,68,14,15,51,77,18,19,37,124,21,55,1,126,116,58,24,131,28,60,135,78,134,138,41,62],letter:[79,80,3,85,47],breakpoint:20,dummi:[125,24,8,35],teco:25,caml:25,detriment:57,bateman:139,came:[94,85],none_fd:124,superset:67,cheapli:[24,90],minimum_s:112,figueiredo:25,layout:[69,24,91,84,16,72,26,105,40,41,20,55,85,141],menu:6,busi:[59,8,121,25,107,11,20],rich:[46,80,25],plate:[20,105],ceil:29,mps_variety_str:36,patch:79,amcsegstruct:35,respond:[133,16,19,7],fair:29,specialist:80,accumulatorscal:66,result:[0,88,91,29,128,96,99,103,27,106,107,108,32,54,35,69,7,112,8,40,11,43,12,45,119,46,120,105,14,41,77,78,19,20,21,55,56,116,57,58,79,66,49,82,61,125,135,26,131,84,64,141,140,28,85,86],respons:[1,119,90,91,93,30,99,103,107,108,67,48,69,7,70,8,9,116,12,96,45,74,46,18,19,54],fail:[125,90,29,30,130,79,64,107,78,21,48,93,111,71,8,80,9,39,40,14,12,45,46,49,41,121,52,77,18,19,54,81,55,56,57,58,66,24,131,25,26,105,61,85],ringjoin:27,sizealigndown:66,best:[1,88,92,93,99,101,87,105,107,108,32,112,39,41,45,46,47,52,66,24,133,25,84,138,61,85],dahl:[47,25],size_io:77,splaynodefinish:103,delphi:25,gen_count:58,shenker:47,figur:[1,67,69,134,77,39,27,125],glasgow:47,pad_:61,inabl:[88,89],extend:[92,29,30,107,32,65,67,69,93,8,39,40,116,45,11,20,54,57,24,25,136,61],sram:105,extens:[87,91,29,30,100,34,69,7,71,72,96,45,120,14,16,52,54,24,25,61,85,62],extent:[89,90,91,93,7,24,97,16,99,100,135,105,25],toler:[101,35,104,130,11],accident:[20,66,57,96,65],logic:[35,97,29,94,50,25,102,106,40,20,85,62],rehash:[128,61,41],mrgsegpaircr:57,threadregist:[75,118],mps_arena_destroi:[135,21,61,45],vmmap:[78,21,18],"__kill":[21,26],diff:20,assum:[63,87,91,95,30,101,54,67,68,35,69,7,9,39,11,12,74,120,14,52,77,18,19,66,81,56,134,125,135,61,85,141],summar:[8,78,62],duplic:[67,91,92,8,16,52,82,103,12,85],mps_lib_fput:49,fre:25,union:[67,57,69,23,93,65,8,79,61,104,114,41,20,66,44,30,128],much:[0,1,90,92,29,96,87,104,107,6,67,68,35,71,9,72,39,40,12,45,74,46,130,50,16,18,19,57,58,24,131,133,28,135,78,84,61,85,123],mps_arena_unsafe_restore_protect:45,mrgderegist:57,messagecheck:114,life:[57,47,112,97,72,41,32,12],retrospect:47,suspendedscp:52,lifo:[88,97,105,93],telnet:[74,50],enosr:74,lift:29,child:[10,7,99,103,78,27],emploi:97,commerci:[1,20,59,46],arenasetcommitlimit:8,toolkit:47,bim:27,segmergemethod:30,mps_word_t:[120,128,66,79,26,40,84,21,44,61,45],format:[1,88,89,91,92,93,94,97,99,104,105,4,107,108,6,109,66,67,34,35,69,7,11,37,80,115,39,40,41,43,44,45,74,46,120,50,75,13,76,14,15,127,77,123,141,20,21,55,126,116,106,12,25,61,125,112,26,84,138,86,2,28,62],thingi:141,split:[88,90,92,29,24,30,97,16,103,72,101,77,39,105,5,21,133],european:47,bufferfil:[77,57,75,107],fairli:[89,12,106],refil:[125,35,140,39,107],refio:[35,28,141],refin:[67,91,24,25,9,106],tune:[74,46,35,47,34,71,24,37,127,61,26,65,55,96],char_bit:132,bewar:[125,26],mps_lib_assert_fail:[14,49],mmdevel_poolam:23,arenasetsparecommitlimit:8,unchang:[56,2],greyr:30,act_on_rang:29,previous:[74,135,57,23,93,70,24,49,52,40,103,78,107,41,42,21],easi:[74,80,120,57,75,29,37,50,16,25,61,101,26,27,123,65,6,140,55,85],had:[0,46,57,69,23,15,121,52,25,67,77,26,106,41,65,21,100,138,61,56,92],define_class:54,fortran:[16,25],match:[46,35,130,100,77,103,131,19,107,41,20,66,44,62],preserv:[74,68,35,57,7,24,116,104,101,39,90,105,40,95,80,28,118],birth:[112,57],shadow:134,rhsk_2007:[50,12],"0x000000010000ea40":26,heapifi:7,measur:[74,57,107,47,24,96,72,105,40,84,66,45,92],specif:[125,91,29,30,97,106,107,108,32,65,66,67,35,69,93,70,8,38,40,116,42,117,12,96,45,119,46,120,47,16,52,77,53,21,57,58,24,25,134,118,28,85,141],bufferinit:[80,57,141,107,116],src_ld:128,colmerau:25,underli:[69,16,134,135,78,105,107,41,91,80,81,56],right:[47,46,29,59,71,24,30,15,16,79,61,77,103,84,20,66,28,62],old:[87,88,91,92,93,94,95,30,97,103,104,3,106,108,32,125,34,35,132,8,72,9,41,12,96,74,46,66,81,55,56,128,25,27,61],extendbi:[20,57,48],addrcomp:66,"0x0000000100003f55":[21,26],uniq:114,bottom:[68,120,11,114,103,26,41,20,61],fox:47,subclass:[35,57,92,76,30,72,28,77,39,27,107,54,8,141],tracestart_diag:50,bruggeman:47,foo:[69,50,79,26,27,19,107,116,20,21,85],arg_define_kei:65,rampgen:35,sensibl:[73,12,116],mps_frequenc:19,traceidmessagesdestroi:130,slightli:[35,75,8,78,106,40,41,12,141],despair:62,old_symtab_s:61,coars:80,mps_key_pool_debug_opt:[138,43,109,44,2],sol:[80,75,134],soo:47,mps_io_rec:74,"0x00000001003f9b70":26,kakkad:47,suffici:[87,35,57,69,7,29,112,133,30,80,52,25,39,104,103,20,54,61],support:[0,63,90,91,92,29,88,30,130,79,100,103,93,64,106,107,108,5,6,109,66,67,48,35,47,7,70,112,8,80,9,115,39,128,141,11,43,138,96,118,74,46,120,50,13,41,68,14,123,15,104,52,77,18,19,53,37,124,54,81,55,56,126,127,57,24,49,132,133,25,61,125,1,135,78,131,113,84,137,105,86,140,28,85,62],tracemessag:130,happi:85,avail:[63,1,91,92,29,88,96,99,102,104,105,106,108,32,6,80,35,93,59,71,49,45,74,46,14,50,16,52,20,21,81,56,57,119,23,24,133,25,134,125,112,26,140,41,85,141],width:[93,76,132,20,66,12,85],spring:105,overhead:[67,46,35,75,93,29,112,8,16,103,99,134,102,9,104,40,54,12,96,62],offer:[87,7,24,25,101,77,39,105,108,56],poolno:[137,116],splaytreenext:103,mps_amc_appli:37,oopsla:47,rattl:46,linuxthread:[140,52,56,70],qin:47,mps_arch_m2:132,proven:[88,82,57],exist:[0,90,29,96,79,103,105,32,5,54,67,35,69,73,8,80,9,39,40,42,117,44,46,130,77,78,19,141,124,21,55,56,57,58,66,24,12,139,61,123],role:[88,61,85],presum:[57,69,70,8,107,32],smell:103,legitim:84,notif:[32,57,121],intend:[29,128,94,30,103,3,4,107,66,35,7,70,112,37,80,10,49,45,74,120,13,14,50,122,20,54,81,55,56,116,57,25,61,60,84,140,28,85,106],asterisk:20,intens:[90,12,47],intent:[29,24,104,79,18,32,21,141,66,130],aslr:26,event_kind:21,culprit:14,phantomrefer:[106,108],locusattr:24,time:[0,2,3,6,7,8,9,11,12,14,15,16,19,21,23,24,25,26,28,29,121,32,35,36,37,39,40,41,44,45,46,47,49,50,52,53,54,55,57,58,59,60,61,62,1,66,67,48,69,70,71,74,75,77,78,79,80,82,85,86,87,89,90,91,93,94,96,97,99,100,101,102,103,104,105,106,107,108,112,113,114,118,120,130,125,128,133,135,131,138,140,141],push:[57,7,93,105,15,64,3,97,118,126],mrgguardianfre:57,mps_ap_alloc_pattern_reset:131,chain:[0,87,90,92,93,88,95,96,97,101,103,105,4,2,35,71,37,39,41,43,44,45,15,52,20,54,81,127,57,58,133,82,61,86],oss:[18,15],awlseginit:141,ost:47,osi:59,addrcopi:[66,15],excl:125,event_foocreate_param:80,osf:[124,6,132],millisecond:45,decid:[91,29,105,108,125,67,35,7,39,40,116,45,74,46,16,77,19,66,58,24,61,62],decim:123,arch_align:137,decis:[58,40,29,24,114,113,93,64,107,49,61],mps_sac_t:19,"1003fe000":21,exact:[88,89,91,93,96,79,104,105,106,107,108,125,35,132,37,115,39,40,11,43,12,118,120,14,41,66,57,141,61,62],"0x1003fe278":26,weak_buckets_ap:41,tear:[74,49,61,72],unsupport:[30,80,7],team:85,setup:[74,35,57,51,72,81,56,141],o1algc:132,prevent:[0,135,35,75,23,47,91,24,8,15,52,113,9,104,53,19,40,11,20,66,106],sign:[65,8,114],mps_fmt_a_t:69,unprotect:[90,120,15,75,11],relocat:100,bufferseg:[107,141],lazili:[121,57,91],awlgrei:141,segprefgen:24,amcheaderfix:35,failobj1:54,vector_:[61,84],honour:[24,35,81,56,134],modif:[91,29,59,25,77,9,105,106,20,6,12],address:[0,88,89,90,92,29,128,94,95,30,97,99,100,101,102,103,104,105,106,107,108,78,134,66,48,35,44,69,93,7,71,8,80,72,39,40,11,12,96,45,74,46,120,68,14,41,124,18,19,37,20,21,55,56,57,119,79,24,133,82,25,61,125,26,84,138,141,140,28,123],along:[63,35,57,91,14,30,116,133,114,39,95,41,54,12,66],finalizationmessag:32,queue:[0,57,91,130,96,121,114,101,135,105,106,40,41,32,86],weak_array_:11,bufferdetach:107,sigxcpu:140,reclaim:[0,1,90,91,88,95,97,99,101,87,104,64,106,108,32,109,110,67,35,113,7,11,37,9,72,115,39,41,43,12,119,120,13,14,15,130,77,138,66,126,116,57,23,2,25,28,125,112,135,105,141,61,62],ourselv:[81,56],chalmer:47,love:62,santa:47,pentium:90,prefer:[48,92,24,8,9,40,6,44,66,56,141],type_uniniti:125,fake:[129,34,30,72],instal:[46,35,49,51,117,127,6,81,21,56],sigbu:[26,140],cmp_t:[128,41],poolinitam:39,scope:[69,40,105,3,27,25,107,114,20,54],tightli:[20,61],afford:[67,46,40],peopl:[0,46,91,96,50,98,25,136,104,105,20,139],claus:[20,59],stackbot:[68,118],visual:[1,91,132,25,20,6,85],appendix:[21,135],mps_arena_step:[58,45],behalf:[46,57,52],pretend:16,descriptor:[88,35,111,24,8,124,107,116,20,30],whatev:[57,91,49,134,77,85,40,80,45],validli:[125,135,103,113,55],encapsul:[128,8,108,101,18,105,106,41,32,45],unallocat:63,seglimit:[30,141],recycl:[87,88,91,93,96,97,99,104,105,106,2,67,34,37,38,9,40,116,45,120,16,122,57,133,25],mps_pf_xci6ll:132,exit_cod:120,mps_frame_t:[64,7],mps_assert_str:85,mps_telemetry_intern:[21,104],parameter:85,controlalloc:[8,130,54],suffer:[46,97,88],eventlast:80,remap:108,jacqu:47,"1993a":[102,106],date:[67,57,23,36,103,72,9,32,61],data:[63,1,90,91,92,29,88,94,30,97,130,99,100,101,102,87,104,27,106,107,108,134,54,34,125,93,59,70,8,80,9,72,39,10,40,41,96,45,74,46,120,75,13,47,76,14,50,16,52,77,131,19,20,21,81,114,56,57,2,66,24,49,82,25,61,60,26,84,105,141,140,28,62],stress:[6,39],mps_arena_:[94,8,79],stdio:46,freefre:2,callabl:[75,8,69],untest:74,ordinarili:35,thomson:139,thr_o:140,mps_os_xc:132,"0x000000010006631f":26,mps_key_align:[48,44,138],jin:47,torn:114,leftchild:103,tort:[20,59],message_o:[0,74],mmqa:29,smarter:123,therebi:[87,117,130,29],arenasettotalloci:24,predefinit:85,didn:[87,23,93,25,77,103,56],revert:67,type_vector:84,separ:[89,91,29,94,96,97,79,102,27,106,107,6,54,67,80,9,39,40,41,45,46,15,75,50,16,77,18,19,53,138,20,66,81,56,126,57,24,78,105,85],mps_fmt_put_fencepost_t:77,confid:[9,43,41],compil:[1,88,90,91,92,29,94,96,97,99,100,102,82,104,105,106,108,32,5,6,80,69,59,36,72,9,40,114,12,74,46,120,47,14,50,21,127,132,25,125,26,84,61,85],receipt:74,dramat:[71,87],seghireturn:30,mps_args_add:[2,13,112,37,11,61,115,4,41,138,43,109,44,55,45,126],suballoc:[46,94,133,16,99,38,105],spacesig:3,internet:74,mps_alloc_pattern_t:131,occupi:[67,29,96,99,134,82,26,106,40,45],freeblockstruct:103,million:[71,61],seventh:61,krishnan:47,"byte":[87,91,92,29,96,98,101,102,82,104,105,107,2,32,109,66,35,93,112,8,116,45,74,120,49,77,18,19,80,126,24,133,25,28,125,84,138,141,61,123],unpredict:46,mps_key_min_s:[112,65,44],reusabl:54,kaufmann:47,punc:3,unavoid:35,recov:[46,131,69],neglect:[0,14,25],oper:[0,1,90,7,92,29,88,30,99,87,101,102,103,93,27,106,107,108,91,6,134,66,67,35,47,59,70,112,8,39,72,38,104,9,10,40,11,117,96,45,74,46,120,75,13,41,14,15,16,51,52,77,18,100,19,20,21,81,55,56,128,119,23,79,24,105,132,133,25,61,125,26,118,84,78,140,28,85,123],onc:[1,91,29,97,99,105,106,107,66,67,35,40,41,12,45,74,46,75,47,11,130,51,52,77,19,54,57,79,25,125],resultreturn:[26,51],reopen:24,symmetri:29,mps_arena:45,open:[1,88,29,6,34,69,59,113,40,41,45,47,49,11,51,20,80,24,25,135,85,62],convent:[46,89,90,69,29,34,94,91,76,72,79,104,27,99,108,20,54,68,85,86],bite:24,conveni:[0,46,120,57,91,29,73,14,8,84,49,25,67,101,103,107,41,65,54,44,61],gcseg:[30,141],mps_res_io:[74,14],programat:55,weak_array_t:11,floppi:[96,92],mps_frame_class_:7,mps_align:28,structure2:69,structure1:69,sai:[67,46,66,24,49,108,16,96,114,134,125,104,105,106,41,65,6,55,56],blockstruct:20,obj_empti:[26,61],argument:[0,91,29,30,98,79,101,27,4,107,2,32,65,109,66,67,34,69,112,8,76,80,114,115,39,41,43,44,45,119,120,13,47,48,14,11,130,78,19,20,54,81,55,56,126,24,61,125,84,138,141,140,37,86],alleg:84,ravenbrook:[1,59,17,136,107,65,20,6,139,12,85],sat:[21,26],buffercr:[75,107,116],destroi:[119,90,29,94,30,99,103,105,106,107,2,32,125,35,7,112,72,39,114,12,45,74,46,120,130,116,121,18,19,53,20,21,55,57,58,24,25,28,78,61,141],note:[0,3,6,7,8,9,11,12,13,14,15,18,19,20,21,23,24,25,27,28,29,30,32,35,132,37,39,40,41,43,44,45,46,47,121,50,52,53,66,55,56,57,58,49,61,62,64,67,69,71,72,74,76,77,131,79,80,81,83,84,85,87,88,90,91,92,93,94,96,99,101,102,103,104,105,106,107,112,113,116,119,120,130,123,125,128,133,134,135,137,138,140,141],take:[125,88,61,91,29,97,99,104,27,116,107,109,54,67,48,93,7,112,8,80,9,114,115,39,10,40,11,43,44,45,119,46,120,75,13,14,41,16,52,77,19,138,21,126,128,58,79,24,133,25,28,135,26,84,105,141,37,85,62],unfix:[86,84],noth:[102,2,109,21,67,35,70,39,41,117,118,51,66,81,56,57,58,23,28,45,138,61,62],mutatorfaultcontext:51,printer:[21,25],buffer:[63,92,29,30,99,102,104,105,107,21,34,35,69,93,7,8,80,72,39,116,74,75,13,48,49,50,123,66,24,125,138,140,28,141],compress:[105,91],poollo:29,abut:30,abus:27,addrref:7,drive:80,axi:107,messageempti:[32,130,121],merit:77,unfinish:141,varp:61,slot:[125,48,7,88,11,65,54,28,141],slow:[0,46,97,104,25,134,77,39,26,105,19,40,12,45],slop:77,"0x7fff5fbfef2c":26,transact:[32,47],activ:[63,88,90,91,93,96,97,99,82,105,67,70,8,45,46,75,130,53,56,25,134,61],lii4gc:132,z80:29,awlsegclass:141,wilei:47,allocframeclassstruct:7,genera:47,clang:[1,6,26,132],unscan:141,requir:[0,3,4,7,8,9,11,12,13,14,16,20,21,24,25,27,28,29,121,32,35,36,37,39,41,43,44,45,46,49,50,52,54,55,56,57,61,62,66,69,70,72,73,74,75,76,77,80,81,84,85,87,88,90,91,92,93,94,95,96,108,99,101,103,104,105,106,107,2,109,115,116,117,118,120,130,123,126,128,133,134,135,136,137,138,140,141],mumbl:124,discontigu:[24,93],arenaclamp:8,borrow:77,"0x7fff5fbfef28":26,roger:47,where:[1,88,89,90,91,29,95,30,97,99,102,103,104,27,106,107,108,6,54,35,69,93,7,36,8,80,9,72,39,10,40,11,117,96,45,74,46,120,50,75,76,121,41,16,77,128,19,20,21,81,55,56,57,58,79,66,24,70,133,125,26,84,105,140,61,85,141],arglist:[57,107],assumpt:[35,24,37,16,117,77,135,11,32,54,66,56],o_ndelai:74,amort:103,mps_build_:85,screen:50,sparc:[6,29,132],spare:[88,24,8,16,72,105,45],uncondition:135,shortag:[140,16],caar:26,mani:[1,88,89,90,91,92,29,96,97,99,100,102,103,3,106,107,108,134,54,67,35,69,93,7,112,9,114,39,40,14,45,46,120,49,50,16,19,141,20,21,125,128,58,24,133,25,61,60,135,26,105,139,41,85,62],mann:139,anti:[54,30,57,39],sentinel:[20,8,24],ismov:15,compareless:[66,103],klauser:47,bufferdescribemethod:107,weak_table_:11,scannabl:[67,93,39,105,41,61,62],"0x0000000100002fe4":26,locuscr:24,mps_arena_spare_commit:[8,105,45],thousand:71,resolut:[49,21],catastroph:[24,105],extant:115,former:[67,88,57,36,101,39,106],poolasm:116,"_mps_":69,config_stat:85,nodedescrib:103,mps_pool_debug_option_:[77,44,2],addroffset:[66,103],canon:54,arenaleav:[75,15,69],blah:[35,141],splaycomparemethod:103,cobol:[16,25],freelist:134,"0x7fff5fbff830":26,pursu:24,stateoffram:7,smalltalk:[87,88,90,47,16,25,106],"0x1003f9b58":26,binari:[88,90,92,101,103,69,59,36,8,72,40,45,74,75,49,123,20,21,70,133,60,85],sizeroundup:66,mps_lib_get_eof:49,tru64:[124,6,132],mps_root_create_table_mask:120,extern:[88,89,90,91,92,29,121,130,99,103,105,106,107,108,32,65,54,67,48,69,7,72,9,116,45,74,46,75,49,50,16,80,133,135,138,28,85,141],attrscan:66,temptat:[123,84],dereferenc:[66,69,125,25],commitlimit:8,summer:47,reservoirpermit:[54,141],c89:91,rest:[35,75,24,15,61,123,80,140,55,141],mps_build_lc:132,gdb:[21,26,80,45],unmaintain:25,mps_build_ll:132,concentr:[46,85,36],threadderegist:[75,118],issetrang:29,littl:[67,46,35,57,29,24,8,85,16,25,77,103,19,116,81,97,96,56],instrument:85,exercis:[103,26,104,47,29],around:[125,92,95,96,103,107,80,35,70,11,9,40,41,74,46,75,49,15,52,77,78,20,66,58,82,25,28,61,62],rejoin:103,sac_o:19,categoris:[24,35],epdlpoolclassstruct:54,pop:[90,7,93,115,57,105,64,126],amcgen0rampmodefrequ:20,world:[96,16,47,45],intel:[90,92,132],segalloc:[24,141],integ:[88,92,29,101,82,105,32,21,69,93,132,10,41,120,49,11,66,55,128,24,61,85],inter:[91,24,37,99,101,9,106,107,55],rightnod:103,poolawl:[29,141],pthreadextresum:52,satisfactori:[35,103],constitut:[61,29],resfail:[24,66,52,103],definit:[90,29,79,103,114,32,80,68,35,69,7,8,72,10,40,116,73,118,120,75,76,52,77,18,53,20,54,24,25,78,137,28,85,141],evolv:75,noop:[117,85],base_address:44,fillinternals:107,notabl:[67,90,93,52,39,66],refer:[0,4,9,11,12,13,14,15,16,21,23,24,25,26,28,29,30,32,33,34,35,37,38,39,40,41,42,43,45,46,47,130,50,52,53,54,55,56,57,58,60,61,62,1,65,66,67,68,72,75,76,77,79,80,81,84,85,86,87,88,89,90,91,92,93,94,95,96,97,99,101,82,104,105,106,107,108,109,110,112,113,114,115,116,118,119,120,121,124,125,126,128,133,134,135,138,139,140,141],splaytreestruct:103,obj_pad:[55,61],arrow:87,power:[90,92,29,132,11,133,25,101,9,93,105,79,41,66],rightreturn:103,acc:23,mps_pf_xci3ll:132,joyner:[96,47],acm:47,neighbor:24,act:[67,91,107,96,116,53,108,32],johnston:[88,89,47,101,104,105,138,139],droppedmessag:130,rebuild:21,awlsegfinish:141,berger:47,effici:[1,87,92,29,96,97,99,101,103,104,64,106,109,125,67,35,93,7,112,8,9,39,40,41,43,138,45,46,120,13,47,11,16,77,122,53,37,66,57,58,23,24,133,82,105,61],surviv:[67,87,35,90,58,93,96,16,25,82,40,108,32,61],poolbufferclassmethod:107,poolclassmrg:[57,121],hex:[3,114],laboratori:47,conclud:[32,46,56],tomasev:47,mps_os_o1:132,messagetypecollectionstat:32,"0000178ea03f57da":80,dirti:[90,91],inframe_o:7,mps_io_send:74,creat:[0,1,91,29,88,94,95,96,2,79,101,104,105,4,107,108,32,109,54,67,48,35,44,125,7,112,8,122,113,72,115,128,114,11,43,119,12,45,74,46,120,50,75,13,68,130,41,121,51,77,18,19,53,124,21,55,126,127,57,58,106,24,25,61,60,135,78,138,141,140,37,86],certain:[88,90,92,97,101,102,104,105,106,107,108,32,48,35,69,7,9,116,117,12,45,74,46,50,16,18,20,80,24,133,25,131,84,85,141],ecoop98:47,clearup:[130,72],googl:17,mps_ld_t:[128,41],tight:[9,133,21,25,40],freestand:[74,49,73,123],genuin:[46,75,107,84,12,61],sigmod:47,inexplic:93,symbol_pool:21,mask:[56,120,81,52,29],tricki:[35,24,84,32,66,56],mimic:2,mass:[24,96],mps_telemetry_set:21,cpp:69,cpu:[87,46,90,132,96,97,16,6,45],scm:[71,26],consider:[46,35,47,76,96,88,85,40,5,56],splaynoderefresh:103,illustr:[104,45,40,61],ferreira:47,extrapol:61,bufferap:107,resok:[29,52,51,103,107,116,20,54,66],codasyl:25,tail:[77,47,25],sml:[47,25],chenei:[87,104,91,47],rootdestroi:75,introduc:[67,46,35,23,7,24,8,16,120,25,105,99,107,95,32,141,106],splaytreedescrib:103,candid:[141,91,52,29,55],condition:80,mps_arg:44,harri:47,quux:50,reset_mask:21,adjust:[74,57,94,24,97,104,39,99,77,9,90,105,116,103,141,12,56,130],mps_lib_get_stderr:49,small:[1,87,89,91,29,95,96,97,99,103,104,105,106,33,125,67,34,35,69,93,71,8,72,9,40,12,45,46,75,13,130,16,52,77,122,19,80,126,58,24,133,25,84,61,85],amcbuf:35,lockreleaserecurs:70,ref_io:84,ensuredebugclass:77,tricolor:[101,104,105],sync:[50,7,15,51,117,81,56],past:[1,46,91,29,68,61,101,40,65,20,141,55,85,62],secondparamunsign:80,"_diag":50,suboptim:[58,61],otoh:24,deleg:[7,84],richard:[50,69,47,24,8,15,130,114,107,65,66,139,12,80,85],clock:[0,91,49,8,114,26,105,41,141],section:[104,27,6,67,35,70,72,40,41,12,76,14,11,16,128,20,57,24,84,61,85,62],mps_pool_class_mv_debug:77,delet:[0,1,90,101,103,105,32,65,66,35,9,41,46,75,11,130,21,57,24,25,113,27,141],abbrevi:[105,97,98,41],mps_amc_apply_stepper_t:37,method:[63,88,61,91,92,94,30,99,103,90,27,4,107,108,32,65,6,66,67,48,35,69,7,36,37,113,72,115,39,40,11,42,43,12,120,50,75,13,47,14,123,41,130,127,77,79,53,141,54,55,116,57,58,23,106,25,28,125,135,26,84,137,105,86,8,85,62],contrast:[89,96,130,105,45,108,81,56],mps_ap_alloc_pattern_end:[131,106],hasn:[32,87,21,12],full:[63,88,30,100,103,104,27,35,132,114,39,10,41,45,74,46,50,131,19,21,24,25,135,26,61],hash:[127,90,128,11,25,101,77,113,26,99,41,61,62],inher:52,free_siz:2,parenthesi:[20,79],fstruct:61,freeblockupdatenod:103,prior:[0,128,52,25,103,32,21,141],testtre:103,pick:[54,82,47,41],action:[88,90,101,105,106,107,125,67,35,114,39,41,45,46,75,50,77,53,20,66,116,24,135,64,141],luck:[14,125,40],mps_addr_fmt:[55,45],via:[63,30,2,130,79,103,104,106,107,108,32,109,54,35,59,112,37,80,115,10,11,43,12,96,45,119,46,120,75,13,49,116,16,52,128,19,21,126,57,7,24,25,61,125,121,134,138,141,140,8,123],depart:47,barringstruct:27,gratuit:[78,29],decrement:[97,15,101,9,106,107],coercion:54,select:[67,35,57,47,29,14,8,7,100,102,3,106,108,21,134,12,85,92],gudeman:[101,82,104,92,47],etc:[92,94,30,105,65,6,69,7,40,96,74,130,16,78,21,57,24,134,60,136,28,85,141],rhel:1,poolframepopmethod:7,more:[0,27,4,6,59,8,9,11,12,14,16,18,19,20,21,24,25,26,29,30,32,35,37,38,39,40,41,44,45,46,47,49,50,52,53,54,55,56,57,7,61,1,64,66,67,48,69,70,75,77,131,79,80,81,82,85,87,88,91,92,93,94,95,96,97,99,101,102,103,104,105,106,107,108,112,113,117,119,120,130,123,125,128,135,137,138,140,141],uncoop:[96,47],hundr:[71,104,91],xci6ll:[6,132],cach:[90,91,29,30,97,100,101,103,104,105,106,109,34,93,112,8,9,72,115,39,40,11,43,12,96,119,13,47,15,16,19,126,138,62,37,86],damien:47,malo:47,morgan:47,learn:[1,46,25],isresetrang:29,rootvar:66,bogu:[32,42],scan:[1,87,89,90,91,92,29,88,106,30,97,99,102,104,105,4,107,108,32,109,66,67,34,35,69,93,7,71,37,76,80,9,72,115,39,40,11,43,12,45,120,75,13,47,68,14,113,15,127,77,79,53,141,21,55,126,116,57,23,24,133,61,125,112,135,26,118,84,138,86,140,41,62],rodriguez:47,registr:[57,91,108,72,41,80,140,118,86],accept:[35,58,7,96,15,130,61,116,39,104,19,84,91,54,134,55,85,62],pessim:112,condemn:[0,88,91,99,101,87,104,105,32,67,35,7,72,39,40,41,42,12,116,130,53,58,23,24,134,26,28,141],huge:[46,97,105,100],netinet:74,vmso:78,eventdescrib:80,simpl:[91,92,29,106,30,103,104,105,4,107,6,35,69,93,7,70,112,9,114,39,40,11,41,12,50,75,47,49,15,18,123,20,80,126,133,25,134,26,84,138,141,61,85,62],pieper:[139,47],arenaseri:8,referenc:[87,88,90,91,93,95,96,97,102,103,105,108,125,35,37,115,9,10,11,43,12,13,66,57,135,26,61,141],variant:[48,114,61,13,95,37,84,25,55,115,103,105,106,53,11,43,28,85,62],ofap:107,mps_io_type_telemetri:74,varianc:55,unreserv:116,circumst:[119,135,128,91,7,94,12,96,130,39,103,61,9,56,107,138,44,28,45],splaytreefirst:103,leroi:[47,108],issubclasspoli:54,poolinitmf:80,paper:[46,57,16,103,104,21],scott:47,untouch:[14,66,29],currrent:80,formatcr:75,"0x1003f9b70":26,"0x1003f9b78":26,wrt:75,rapidli:[71,25],tractstruct:8,superflu:39,mps_rank_exact:[89,11,120,115,105,106,41,61],hyperspec:[91,25],arenastruct:[32,130,107],amelior:[24,77],mps_rank_ambig:[120,105,61,93,106],arbitr:96,arenacr:[130,8,75],osarct:[6,132],achiev:[68,120,103,75,112,8,52,99,9,90,105,123,107,39,32,80,96],ecru:[94,89],tracescan:[57,23,116],found:[63,92,29,2,103,27,108,125,48,69,71,114,40,41,12,118,119,46,120,116,16,52,77,19,138,21,55,128,24,137,105,61,85,141],arenaread:121,monoton:107,procedur:[68,91,93,84,135,25,103,105,106,107,41,61,85,62],obj_t:[125,120,128,11,41,113,26,84,21,61],operation:101,isbas:20,reduct:[67,47],ftp:6,agre:[0,25],research:[16,47,25],bibop:[106,40,25,92],mps_arena_cr:[8,18,45],sparingli:20,type_pad1:[26,61],nonport:52,belief:48,pair_:[26,61,84],controlpoolstruct:8,believ:[90,7,24,103,104,107],mps_alloc:[96,79,106,108,109,69,112,37,115,11,43,119,13,14,77,19,125,55,126,138,61,62],driven:[101,47],"_mps_fix2":40,struggl:26,clump:24,major:[67,46,90,91,59,37,133,25,77,87,20,80,96,45],number:[0,87,90,91,92,29,88,94,96,97,101,102,82,104,3,4,107,108,32,65,6,54,35,93,70,71,8,80,114,40,41,43,12,45,46,120,13,47,105,14,123,15,121,52,19,138,20,21,116,57,58,66,24,49,133,25,61,60,112,26,84,27,141,28,85,106],globals_scan:61,frameptr:7,precautionari:24,indistinguish:35,"000ae03973352375":21,guess:[24,15,26],fuller:16,vararg:[76,77,123,65,28,141],checkpoint:36,illeg:[7,116,114,39,18,64,2,12],reservoircheck:63,supernamestruct:54,segprefexpress:24,commonplac:92,relationship:[7,102,30,25,77,10,54],mps_thread_reg:[120,104,140,61],"0x7":84,consult:[32,49,8,125,40],grace:80,"0x1234":80,rb_1995:[15,114],niklau:25,reus:[67,119,90,112,133,30,16,39,25,9,26,105,106,78,54,8,126],reinstat:15,arrang:[1,67,57,92,88,30,51,103,18,27,40,116,85,141],algol:[91,16,47,25],comput:[91,92,96,103,105,106,107,108,67,35,8,9,41,46,47,16,128,23,24,25,26,28,141],defect:[27,114,76],packag:[6,90,106,25],config_assert:85,amcstruct:35,equival:[87,88,35,69,66,73,37,133,30,84,54,44,6],reservoirstruct:63,ancillari:[46,130],spaghetti:[105,91,85],self:[88,103,104,52,47],also:[0,2,27,4,6,7,8,9,10,13,16,18,19,20,21,23,24,25,28,29,30,32,35,37,39,40,41,42,45,46,47,68,50,51,52,54,55,56,57,58,59,61,1,64,66,67,48,69,70,73,74,75,77,79,80,82,83,85,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,110,114,116,120,130,124,125,128,133,135,136,137,138,141],analogu:104,brace:[20,54,76],pipelin:105,plai:[35,47],plan:[47,7,103,39,80,62],mps_fmt_destroi:[55,61],cover:[67,35,97,16,120,79,60,105,84,125,61,45,141],quadword:[90,83],ext:85,abnorm:[21,16],exp:26,microsoft:[1,91,132,25,6,85],pp_2005:85,xcode:[6,85],session:[20,80,45,41],daconta:[47,25],impact:[80,12,85],fputc:[49,123],dosser:47,writer:25,solut:[46,89,80,8,16,39,25,134,77,9,72,108,6,61],protset:[81,51,56],rangessam:29,factor:[46,96,104],writef:[34,50,72,103,123,66],remedi:108,btresrang:[29,141],awlbenefit:141,mainten:[54,85],liabl:[20,21,59],ambiti:24,banner:20,synthes:47,nailboard:35,crl:47,set:[63,87,89,91,92,29,88,94,30,97,99,101,102,103,104,64,106,107,124,65,6,54,67,48,35,69,93,7,70,71,8,80,9,72,39,40,41,42,12,96,45,74,46,120,47,49,50,130,51,52,128,19,53,20,21,81,55,56,116,57,58,23,66,24,25,134,125,112,26,84,105,141,28,85,123],adopt:20,sep:85,buffersetrankset:107,seg:[67,48,35,57,7,66,14,8,15,80,117,30,39,26,123,107,54,21,28,141],isfinalpool:8,see:[0,2,3,4,5,6,83,8,9,10,11,12,13,14,15,18,20,21,23,24,25,26,27,28,29,30,32,35,36,37,39,40,41,43,44,45,46,68,49,50,52,53,54,55,56,57,58,61,62,1,64,66,67,48,69,70,71,72,73,74,75,77,78,79,80,81,82,84,85,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,112,113,114,115,116,118,119,120,121,123,124,125,126,128,129,130,133,134,135,137,138,140,141],sed:114,analog:[49,96,45],"_win32":85,topmost:[105,58],restructur:103,mutex:[52,56,70],messagetypegc:130,ringremov:27,awlfix:141,signatur:[34,57,75,29,76,8,114,134,137,10,3,107,32,65,54,28,141],javascript:[16,25],disallow:39,incident:[20,59],matthia:47,closur:[91,93,47,25,100,103,53,116,85],cryptic:[50,116],last:[90,29,103,27,107,54,67,48,35,8,114,39,40,41,46,15,20,80,128,58,24,133,82,134,26,105,61,141],retent:[35,105],pdp:[83,92,47],let:[94,14,77,26,123,61],maclisp:[92,47],fermin:47,whole:[67,68,35,2,40,29,24,15,25,101,116,87,93,85,107,108,43,125,41,45],becam:[135,93,85],pda:105,load:[46,75,92,106,97,25,105,99,40,6,21,45,86],weakcv:57,markdown:20,schedul:[0,97,58,13,47,71,49,37,11,96,60,135,93,131,41,21,43,45,86],pthreadextsuspend:52,provok:[60,14,103,26,46],church:26,poolclassam:29,connexion:35,mutatorfaultcontextstruct:51,contraint:39,devic:[7,93,96,16,78,108],sinc:[1,87,90,92,29,88,94,96,101,64,107,32,66,67,48,35,8,80,9,39,40,41,12,45,46,120,68,49,52,18,53,20,54,55,126,57,58,23,24,133,25,134,125,26,105,141,140,61,85,128],mps_arena_extend:45,devis:[24,96,104,3],fire:[77,80,103,2],caleb:47,great:[35,90,97,40,80,85],fund:8,func:19,weak_array_find_depend:11,mpscmvt:112,straight:[77,40],erron:[23,7],histor:[87,88,90,91,92,93,94,96,99,101,102,104,105,106,83,6,68,35,70,72,15,121,78,124,81,57,132,25,86],durat:[67,90,93,25,105,55,45],lookup_in_fram:[21,26],error:[125,88,90,92,93,128,94,30,2,130,99,103,27,106,108,32,65,66,34,35,69,37,72,39,40,41,43,119,96,45,74,46,120,14,11,121,78,19,20,21,55,116,57,58,79,49,82,26,131,84,105,61,85,86],clarifi:[20,141],real:[67,46,47,96,50,121,39,25,52,102,9,105,19,99,108,20,66,12,117,106],vol:47,vanish:26,chase:[92,47],yuasa:47,irrelev:75,hypothesi:[87,37,99],obsolet:[55,61,132,28,41],shorten:85,x64:[6,85],shorter:[125,61],decod:[74,69,93,21,106,40,80,6,86],outermost:131,mps_bool_t:[0,74,128,119,7,84,79,77,19,41,138,125,44,55,45],data_scan:84,nomov:57,stack:[1,89,90,91,93,99,100,103,104,64,106,108,33,34,35,7,112,37,9,72,115,39,40,11,43,44,118,46,120,13,47,68,41,16,131,138,125,81,56,126,25,135,26,105,140,61,85],recent:[88,120,91,93,7,95,8,97,64,40,108,80,85,141],person:[50,47],expens:[67,46,89,90,75,92,88,96,105,91,85],johan:25,insidepol:8,poolclassawl:29,"__int64":85,mysql:59,mps_key_arena_cl_bas:[44,45],simm:90,incapacit:21,eager:93,"0x10012a000":26,lv1:69,input:[74,87,93,14,79,135,105,41,21,45],oberon:25,inconsequenti:24,transpar:[120,90,69,94,14,79,77,104,125,128],single_act:29,"0x1003f9bb8":26,formal:[50,3,25],encount:[14,21,16,84],acknowledg:[34,139],map_noreserv:78,sampl:[49,77],rankmax:30,iji:3,chunksiz:21,benefit:[67,46,35,88,8,77,105,11,54,96,141],recognis:[65,114],recogniz:92,machin:[125,90,92,93,96,97,99,101,104,105,106,108,66,68,35,132,12,74,46,120,47,14,50,16,21,25,85],pietro:47,prerequisit:[6,127],coexist:108,materi:[20,59,46],whiteboard:[72,107],"r\u00f6jemo":47,uncach:8,colorado:47,primarili:[40,8,97,52,39,107,116,54],intl:47,rankweak:[66,28,40,141],contributor:[20,59],next:[1,87,91,29,88,95,30,102,103,27,107,125,67,35,7,112,8,39,40,41,12,45,75,130,50,16,131,19,20,54,81,55,127,58,24,133,26,84,105,61],thirdli:[8,25],span:[1,20,88],mps_format_cr:40,mythic:93,sock:74,textual:[103,116],custom:[120,47,130,25,41,85],suit:[106,25],subgraph:105,decomposit:29,link:[63,88,90,91,30,101,103,104,27,106,108,32,33,6,125,67,34,36,40,41,65,118,74,46,47,11,16,52,141,20,21,57,25,60,113,5,105,86,85,62],atom:[67,46,75,93,47,70,8,97,52,107,54,140,125,56],line:[103,116,107,65,6,21,67,69,40,41,74,76,11,50,77,20,125,25,26,138,85,141],mitig:[46,35],pool_debug_opt:44,pkg_add:6,impl:[29,30,103,107,54,48,69,7,70,8,80,10,116,73,75,50,51,52,77,78,123,66,57,23,129,36,28,85,141],parser:61,"char":[74,128,58,92,66,49,84,80,125,26,123,41,32,65,21,44,61],getthreadcontext:[1,118],phantom:[101,105,106,25,108],invalid:[0,92,99,101,103,64,106,108,125,67,8,114,41,45,119,120,14,130,53,66,23,105],gonthier:[47,108],consequenti:[20,59],retract:[8,57],mps_scan_end:[120,11,84,55,113,40,41,61],wrongli:2,alloc_pattern:131,obj_skip:[26,55,61],lang:[25,101,105,106,108,54],algorithm:[87,91,29,96,99,100,101,104,105,106,35,93,9,72,39,46,47,57,58,24,133,25,138,141],discrimin:[66,57,104,114],mrgstruct:57,bufferofap:107,walker:[77,116],fresh:116,hello:123,ungar:[97,47,25,106],io_o:49,code:[125,88,90,91,92,29,94,30,97,130,99,102,103,64,106,107,108,32,65,6,54,67,35,69,93,59,70,8,80,114,39,40,41,117,119,12,96,45,74,46,120,50,75,13,76,14,123,15,16,52,77,131,19,141,20,21,55,56,116,57,58,7,79,2,66,24,132,133,25,135,84,105,86,140,61,85,62],partial:[74,46,91,23,29,112,24,130,72,134,39,93,105,107,54,125],nzonegroup:24,scratch:[9,125],mps_prod_str:36,holdout:46,procur:[20,59],tracecondemn:[57,116],migh:77,young:[87,37,91,89],send:[74,69,52,72,101,136,80,81,140,56],tricolour:[101,104,105],sens:[88,91,92,24,97,28,102,103,105,107,41,20,61,62],sent:[74,14,21,130,52],unzip:6,thread_suspend_resum:118,finalcv:[60,57],mps_arena_formatted_objects_walk:[37,105,55,45],disast:35,tri:[67,87,69,92,14,96,82,99,100,101,77,39,104,105,19,40,11,91,66],magic:[65,114],scalabl:[67,54,105,47],blockquot:35,fewer:[16,103,12,29,46],"try":[1,105,107,67,48,35,70,114,9,40,11,45,46,120,15,77,78,20,21,57,24,61,85],race:[14,54,125,107],impli:[46,35,75,59,88,94,24,8,103,25,39,105,20,21,80,85],natur:[90,92,93,95,83,109,80,67,35,69,132,112,11,14,77,19,20,66,126,25,138,62],nmr:35,odd:91,index:[34,128,92,29,88,25,134,101,39,105,99,40,108,66,80],mps_rank_weak:[120,11,101,113,106,41],led:[80,29],lee:47,larson:47,punct:20,mps_res_ok:[119,79,106,2,135,40,49,45,74,120,41,14,11,131,19,125,55,58,113,26,84,140,61],ubuntu:1,mps_arena_commit_limit:45,messagesig:114,survei:[16,47],technolog:[102,24,91,47,46],mps_key_mvff_slot_high:[48,44,138],epdldbg:54,calibr:49,mpsclo:13,disciplin:[106,25],poolaccess:[117,57,116],zip:[6,141],commun:[0,74,57,91,47,96,50,52,25,101,77,9,90,99,42,81,55,56,106],doubl:[87,90,58,107,47,112,82,114,39,93,19,40,108,32,66,141,80,45,92],"throw":[35,57,16],zig:103,doubt:59,lesli:47,loci:[67,24,72],comparison:[66,128,103,41],rubbish:107,structu:2,thix:118,larch:47,scatter:[9,89,80,47],paraphras:69,config_var_hot:[14,85,100],weaker:108,process:[87,90,91,92,93,96,99,100,101,102,103,104,105,106,108,6,110,67,7,36,71,9,39,40,41,45,46,15,47,14,11,51,18,20,21,56,57,23,24,133,25,134,135,78,84,61,85],lock:[1,97,125,34,35,69,7,70,8,72,75,14,52,53,66,55,56,128,135,54,140,61],mprotect:[81,56],preformat:12,high:[90,92,29,30,99,103,104,105,107,48,35,93,39,96,74,46,47,21,58,24,25,84,138,141],lispwork:25,fprintf:[49,123,26,61,84],mps_arena_commit_limit_set:[14,91,45],locu:[67,24],giusepp:[139,47],delai:[57,47,112,24,135,26,107,81,12,56],"0x7fff5fbff0a0":26,mps_thread_dereg:[120,140,61],fence_s:2,nonew:35,overridden:[8,54],enshrin:85,alloc:[1,2,4,7,8,9,11,12,13,14,15,16,18,19,20,21,24,25,26,28,29,30,32,34,35,37,38,39,40,41,43,44,45,46,47,130,54,55,57,58,61,62,63,64,66,67,48,69,70,71,72,75,77,78,79,80,84,86,87,88,89,90,91,92,93,94,95,96,97,99,100,101,103,104,105,106,107,108,109,111,112,113,115,116,118,119,120,121,123,125,126,127,129,133,134,135,131,138,140,141],essenti:[0,69,94,24,25,103,105,107,108,75,12,61],seriou:[1,46,74,106],counter:[24,21,130],gavinis:107,serrano:47,issu:[69,92,29,24,96,16,72,135,93,105,130,107,32,5,140,28,118,86],findlongresrang:29,allot:24,allow:[0,63,90,91,92,29,88,73,96,100,87,104,105,106,107,2,32,65,6,54,67,48,69,93,7,36,8,80,9,114,39,136,40,11,42,43,12,45,74,46,120,75,41,14,15,130,52,77,18,19,20,21,81,125,55,56,116,57,66,24,82,25,61,60,113,78,118,84,141,28,85,123],mps_tag_a_:77,"00000001003ff000":21,move:[1,88,89,61,91,92,29,95,96,97,99,100,90,105,106,108,65,109,125,67,35,112,8,9,72,115,39,40,11,42,43,12,45,50,13,15,128,19,37,20,66,55,126,116,57,24,25,28,135,104,84,138,141,41,62],microsystem:25,comma:20,perfect:[58,92,108],mps_arch_pp:132,chosen:[67,7,24,133,103,82,134,60,9,3,40,95,105,61,45],decai:[87,47],therefor:[88,91,93,100,104,105,106,107,32,68,35,69,112,9,39,117,45,120,66,55,24,135,84,61],python:[46,16,25,108],overal:[75,107,29,36,71,40,12,61],innermost:131,wastag:63,mps_root_create_reg:[125,120,104,140,61],snake:108,spinlock:56,mps_arena_clamp:[91,45],multiprocess:47,anyth:[1,88,6,67,48,35,39,114,9,40,12,74,46,120,130,77,57,24,84,61,85,141],iglio:47,mnemon:[68,66,97,105],beneath:39,tracer:[67,34,7,8,72,39,53,66,12,30],subset:[67,120,23,29,112,105,106,107,116,80,61,141],societi:47,freetreealloc:103,"static":[0,1,90,91,93,100,104,105,106,32,65,54,7,70,8,80,72,40,41,74,46,120,75,47,130,52,77,66,81,56,128,25,26,84,61],obj_gen_param:61,variabl:[125,90,91,93,94,96,97,79,27,106,2,33,109,21,34,69,70,112,37,80,115,9,40,41,43,45,119,46,120,13,47,48,49,11,16,52,77,138,20,54,81,56,126,116,25,61,105,86,28,62],rootcreat:75,contigu:[88,40,29,94,24,8,97,99,134,77,103,18,105,30,20,28,96,92],mps_key_mfs_unit_s:[44,126],failnextmethod:54,snapout:35,"0x1003f9bd8":26,tempt:[128,79,84],unnam:78,lexer:61,david:[35,69,47,8,52,116,32,139,12,28],length:[0,74,35,128,58,29,66,41,80,84,61,125,26,3,11,54,21,12,28,141],enforc:[39,140,85],"0x519bla3l":141,outsid:[67,46,35,69,94,73,89,72,77,75,20,117,12,62],type_port:41,softwar:[67,34,90,91,47,59,36,46,25,134,72,20,5,45,92],segreturn:141,poppend:7,sem_post:52,owner:30,buckets_find:[128,41],ecoop:47,licens:[1,34,59,76,20,6],system:[5,6,7,8,11,12,13,14,15,16,18,19,20,21,23,24,25,26,34,132,38,9,40,41,45,46,47,49,50,51,52,54,55,56,57,59,60,61,1,65,67,68,69,70,71,72,74,76,78,79,80,81,84,85,87,88,90,91,92,93,94,96,97,98,99,100,101,102,104,105,106,108,114,117,118,119,120,130,125,127,133,134,135,136,140,141],uninsur:35,poolcheck:10,termin:[125,88,93,29,14,84,52,103,104,49,32,20,21,80],uneras:35,accompani:[20,85,59],haven:[39,57],steel:[67,92,47],unmap:[88,96,82,134,102,18,78,105,106,124,45],initalis:75,"0x1003f9948":26,roberto:25,spaceaccess:116,clearli:[8,26,28],liner:20,usenix:47,fourteenth:47,element:[35,91,8,97,104,103,26,27,19,105,44,61],optimis:[80,85,40],sdram:[90,105],depict:89,messeng:[46,47],chief:[139,45],accuraci:[101,66,12],shieldrais:15,discret:[55,116],type_charact:41,unaccept:[46,105,99,48],btisresrang:29,app_for:27,jun:[21,26],config_var_:85,morrisett:47,placement:[35,29,47,24,8,72,134,93,108],"_mps_key_extend_bi":65,instig:0,stronger:[57,69,92,141],face:[105,96,16,93],mps_io_message_max:74,ckq:3,"9c080":80,fact:[87,88,89,29,30,97,79,104,106,107,32,54,113,114,39,40,96,45,120,16,128,19,66,56,57,24,25,134,135,26,84,61,141],"000000010992f000":21,bufferreturn:107,guei:47,pthreadextinit:52,"0x000000010000447d":26,trivial:[35,57,23,8,107,137,125,81,56],usv2:52,thread_get_context:118,should:[0,63,29,88,30,130,99,101,103,104,3,106,107,2,32,6,109,54,67,35,44,69,47,7,73,71,8,80,114,115,39,10,40,11,42,43,119,12,96,45,74,46,120,50,75,41,14,123,15,117,51,52,128,77,18,19,20,21,81,55,56,116,57,58,79,66,24,49,61,125,112,135,26,131,118,134,137,141,28,85,62],tape:92,"0x00007fff90509df0":26,"0x1003fad48":26,hope:[24,120,18,85],mps_ap_alloc_pattern_begin:[131,106],meant:[24,39,105,88],obj_pool:[55,61],familiar:[67,61],memcpi:[49,66,26,12,125],lockix:14,obj_fmt:[61,55,41],amcz:[34,13,84,4,41,33,61,62],resumethread:118,symtab:[120,61,41],mps_mvff_size:[48,138],reig:47,mps_sac_destroi:19,"__mode":25,attribut:[74,57,24,72,103,128,116,66],btfindlongresrangehigh:29,typereturn:32,unimport:141,frame:[88,90,91,93,99,64,108,109,34,7,112,37,72,115,11,43,120,13,68,138,21,126,26,105,62,86],bty:29,btx:29,packet:80,temporarili:[32,131,15,7],wirf:47,polymorph:[54,66],mps_fmt_t:[13,115,14,37,61,77,4,11,43,44,55],wire:[96,108],buffercheck:107,misus:27,sparecommitlimit:8,pagefault:57,mps_fmt_auto_header_:[55,84],segwhit:39,mps_res_unimpl:[74,14],fri3gc:[6,132],mps_fix_cal:[55,84],drum:[105,92],mps_class_mv:[109,44],ramp:[35,58,7,72,131,106,20,86],tlb:104,mps_class_mf:[109,44,126],boyer:[47,29],distil:25,ucb:47,mailto:59,insuffici:[125,64,25,108],va_arg:[65,30],plezbert:47,immedi:[90,92,99,102,103,64,32,67,35,36,112,39,41,12,45,119,46,120,50,130,52,128,57,24,82,26,84,61,141],neighbour:103,togeth:[87,88,58,7,29,112,24,30,133,16,61,77,93,106,20,100,55,141],event_intern:21,fmt_b:55,linkpartstruct:57,purchas:35,site:[46,136,88],archiv:[6,136,107],cohort:[24,141],mutat:[63,87,90,91,93,88,30,97,99,101,82,104,105,106,107,108,67,68,35,7,8,9,72,39,12,96,45,75,15,51,53,81,56,23,25,118,141],referenti:88,access:[0,87,90,91,92,29,128,94,96,97,99,100,101,102,103,104,105,106,107,108,32,5,6,54,68,35,69,93,7,70,37,9,72,39,11,117,12,118,46,120,50,75,13,41,49,15,16,51,52,77,18,19,53,124,21,81,55,56,116,57,58,79,66,73,82,25,134,125,135,26,121,78,140,28,85,62],paulo:47,matthew:[139,47,107],afterrampgen:35,competit:112,undesign:67,longjmp:55,raymond:52,expans:[29,36,14,50,79,66],upon:[79,101,102,103,41,54],coffe:45,phd:47,mps_pf_lii6gc:132,reclam:[101,135,47],off:[74,35,57,91,70,94,133,50,104,89,77,26,105,116,80,12],colour:[67,91,29,14,30,72,101,39,104,105,53,66,45],count_max:29,frombt:29,ecmascript:25,filesystem:[74,114,85],losegclass:28,facilit:[105,25,134],tunabl:35,paus:[46,58,91,71,8,16,99,9,106,75,96,45],less:[87,90,91,92,29,130,103,105,106,108,109,125,35,69,112,8,40,41,45,46,49,50,16,19,20,66,56,58,133,135,138,61,141],bufferdescrib:[75,123,107],mrgscan:57,amcbufferfil:35,paul:[139,47],mps_args_don:[2,13,112,37,11,61,115,4,41,138,43,109,44,55,45,126],web:[136,25],makefil:[6,85],bibliographi:[34,16,47,46],exempt:59,mps_pool_destroi:[119,135,61],petrank:47,dest:49,piec:[46,57,91,70,50,133,72,9,104,2,45],arguabl:54,sigsoft:47,cruz:47,cedar:88,dish:105,tick:12,recurs:[46,75,93,47,70,8,25,100,39,10,105,72,91,54],resid:[67,90,91,92,24,15,101,102,105,106,54],corpor:[68,47],resio:66,stagger:90,mps_pf_w3i3mv:[85,132],not_condemn:[0,26,41],pretest:[0,25],captur:[39,91],interact:[0,46,47,29,133,49,96,97,16,99,74,9,105,41,21,28,45,86],conservat:[30,107],mps_res_memori:[14,120,19,45],guarante:[88,92,128,94,99,101,106,107,35,70,112,8,9,39,40,45,74,46,120,75,49,130,77,78,19,81,55,57,28,135,141,61,62],transport:[74,104,105],rb_2012:[65,85],avoid:[0,87,90,91,92,95,30,97,99,100,27,4,107,108,32,65,54,48,35,69,59,70,71,8,39,40,41,12,45,46,75,76,130,123,15,121,52,77,18,79,20,21,56,57,66,24,133,135,84,105,141,61,85,106],foowibbl:50,pollthreshold:8,"0x1003fe928":26,milutinov:47,truth:84,aitr:47,mps_arena_spare_commit_limit_set:[8,105,45],sigabrt:[21,26],begintrac:50,stage:[67,57,107,76,103,105,40,84,21,85],mps_fix12:[61,84,55,79,11],interven:[131,19],irix:[94,6,132],sleepycat:59,assess:35,lund:47,pitfal:9,mere:[67,130,97,91,128],merg:[35,128,91,29,24,30,133,103,72,39,116,80],arena_class:45,obj1struct:54,base1:103,intellig:[97,130,47,40],protocolclasssuperclasspoli:54,deliveri:74,putc:20,sigstop:52,mps_debug_option_:[138,43,109],extend_bi:65,"0x1003f9bf8":26,count:[87,88,90,29,94,95,96,97,101,105,106,107,80,35,93,7,70,9,114,38,39,41,44,45,74,46,120,47,15,77,20,66,57,25,134,60,110,28,141],shrunk:24,writeabl:24,postedclock:114,tracepol:[8,26,12],otherwis:[0,1,89,92,29,88,30,130,101,103,105,4,107,32,66,67,68,35,69,59,70,8,80,39,40,41,12,45,119,120,75,49,16,52,128,19,20,21,81,55,56,57,58,23,24,134,125,135,131,118,84,28,141],problem:[87,88,90,93,96,114,100,104,3,106,108,21,67,35,8,9,72,38,39,11,46,47,130,41,16,52,77,20,66,81,56,57,24,105,133,25,135,27,61],unformat:[112,77,138,62],"int":[88,29,79,105,107,32,65,80,35,8,49,44,74,120,14,121,123,20,66,57,54,27,61,85],inv:[30,53],ind:35,ing:[78,25],inc:47,nonetheless:125,mps_fmt_check_fenceposts_t:77,lookup:[128,92,29,96,99,100,26,40,41,134],varieti:[91,93,30,97,100,102,106,6,21,29,36,72,49,12,46,76,14,50,130,77,20,80,25,26,62,85,86],messagedeletemethod:32,repeat:[35,128,24,96,2,60,77,135,104,41,125,61,141],debugpoolcheckmethod:54,vein:93,multithread:47,eof:49,dave:[52,47],rule:[69,76,50,72,135,85,114,41,20,66,61,56],bufferisreset:107,nurseri:[87,97,91,95,50,60,131,108,58],poolmvstruct:20,oldest:[68,35,108],"const":[58,49,32,65,21,44],albuquerqu:47,edward:[96,47,25],sped:[0,25],spec:66,"000ae0397333bc6d":21,simmon:139,jacob:47,correl:112,cmu:47,cmp:[128,41],lockw3:14,deutsch:[90,47,25],consequ:[57,13,14,85,11,115,4,41,43,140,45],thisclass:54,gcsegstruct:[30,28,141],amsscan:39,btcopyoffsetrang:29,topolog:103,told:[67,99],displai:[0,74,36,130,50,16,114,20,80],block_requiring_fin:135,michal:47,firstfit:48,findshortresrangehigh:29,bitmask:[120,21,92],smoke:60,aka:[8,72,52,29,132],"000ae0397335c8b5":21,mps_releas:36,brk:[105,92,93],newspac:[95,104],total:[91,96,103,105,107,109,48,35,71,8,9,41,45,46,116,53,20,66,58,24,112,26,138,61,141],argchecks:65,highli:[1,46,35,25,40,61],bookkeep:[46,57,96,16,25,9],aaron:66,indiana:47,segbuf:107,overrun:77,springer:47,word:[87,90,91,92,29,95,96,99,101,104,21,106,107,108,134,80,35,69,93,83,136,40,11,120,50,77,79,20,66,55,126,57,24,61,125,26,84,105,141,41,85,123],err:[20,8],restor:[0,91,7,47,70,30,51,25,52,103,105,56,84,81,61,45],exit_failur:46,work:[1,87,91,29,96,97,99,101,103,104,27,106,107,6,66,67,35,69,71,8,80,9,72,39,40,11,43,12,45,74,46,120,50,75,47,14,15,16,52,18,19,138,20,21,125,56,116,58,23,24,133,25,61,60,135,78,121,118,105,139,41,85,62],pierc:47,coalesc:[63,46,89,90,91,92,93,88,112,97,133,101,105],miscibl:24,could:[89,29,94,96,121,130,100,103,104,27,106,107,6,21,67,35,69,7,73,9,72,39,40,49,43,12,45,74,120,75,14,15,16,77,128,123,53,20,54,81,56,57,66,24,25,61,84,28,85,141],pierr:47,addr_return:69,indic:[0,88,90,93,94,30,79,103,104,3,106,107,32,21,67,35,7,70,8,80,9,39,14,42,45,120,49,41,121,52,131,54,55,116,128,66,24,105,132,84,64,141,61,85,62],ordinari:[35,91,96,106,11,20,55],sever:[88,90,91,29,95,97,105,108,125,67,35,71,8,40,45,74,46,14,16,77,54,2,24,133,25,112,84,138,61,85],verifi:35,lam:47,recogn:[125,128,11],lai:[20,61],lag:47,lab:47,mps_tramp:140,lau:52,law:20,arch:[67,74,69,68,24,36,134,75,80,85],averag:[48,66,97],scarc:[88,135],domin:46,opaqu:[74,90,69,70,94,79,104,128],recompil:69,mechan:[0,1,89,90,91,92,93,88,94,95,96,97,99,101,87,104,105,106,108,65,80,34,7,70,8,72,41,45,119,50,52,77,18,54,56,57,24,36,25,134,125,135,78,118,137,140,28,141],order:[87,88,90,91,92,93,73,95,96,97,99,100,101,103,104,27,106,107,6,134,66,48,35,69,7,70,8,80,9,39,10,40,41,42,44,118,74,46,75,47,130,11,121,51,78,19,138,20,21,81,56,57,24,105,133,25,12,125,135,26,84,64,140,61,85],"0000178ea03f6827":80,mps_io_destroi:[74,49],mpstd:[66,132,69,85,36],diagnos:[21,130],message_type_o:0,addit:[125,90,91,92,29,94,30,103,104,107,21,67,35,7,112,37,9,115,39,40,11,43,45,46,13,130,50,16,77,78,19,54,55,126,57,24,133,25,135,138,61,141],pascal:[16,25],sizealignup:66,flexibl:[1,67,120,90,94,24,30,85,130,101,78,27,19,80,133,45],mps_telemetry_filenam:[49,21],threadringsuspend:118,arenaent:[75,8,15,69],them:[0,1,90,91,92,29,106,95,30,97,99,87,101,103,105,4,107,32,65,54,67,35,69,93,7,71,8,80,113,114,9,40,11,43,73,96,45,74,46,120,50,13,41,130,15,16,52,77,18,19,20,21,55,116,57,58,79,24,133,25,61,60,112,135,26,84,138,141,140,37,85,62],epdl:[48,54],buffercreatev:107,thei:[0,2,3,4,7,8,9,10,11,12,13,16,18,19,20,24,25,27,28,29,30,121,32,35,37,39,40,41,42,43,45,46,47,49,52,53,66,55,56,57,58,60,61,62,1,65,54,67,68,69,70,72,74,77,78,79,80,82,84,87,88,90,91,92,93,96,97,99,101,102,103,104,105,106,107,108,110,112,114,116,120,130,123,125,128,133,113,137,138,140,141],fragment:[88,89,91,92,93,95,96,97,99,100,105,106,108,35,112,9,45,74,47,16,77,18,19,126,24,133,138,62],thee:21,safe:[0,1,93,88,30,79,103,104,27,107,125,35,69,7,70,112,72,115,39,44,45,46,120,75,47,52,66,56,128,12,25,105,140,61],"break":[92,29,105,106,6,109,125,132,112,12,45,74,15,121,77,20,80,24,25,26,84,54,138,61],band:[88,92,94,99,100,104,12],arenahigh:48,epdr:[48,54],stdarg:73,tendenc:[95,37],stichnoth:47,poolepvm:29,rootcreatet:75,accessmax:30,arenapark:8,network:[74,46,90,49,16,25,135,45],mps_peak_describe_pool:24,daniel:[139,47],forth:[20,105],barrier:[90,92,106,97,99,101,102,104,105,4,107,108,109,125,67,112,8,72,115,39,11,43,12,45,120,13,47,15,121,53,37,66,55,126,23,25,134,26,118,138,140,61,62],standard:[125,91,96,98,99,104,107,6,21,68,69,36,8,9,49,45,119,46,47,14,50,52,79,54,129,25,84,41,85],mvt:[34,112,33,125,126,62],canterburi:47,angl:20,traceback:80,createv:75,subtl:[88,106,40],sigact:52,semaphor:52,ownership:70,render:123,independ:[67,68,90,75,13,47,99,74,18,85,107,80,45],reinitialis:75,unmark:[96,57,105,141],uncollect:9,nomin:[20,59],timothi:47,serendipit:24,upshot:128,john:[87,47,96,25,21,139],happili:[35,121],poolclassamc:75,r4000:132,target:[1,46,127,69,29,76,66,49,84,52,10,40,108,6,132,61,85],provid:[63,1,91,29,88,94,30,97,130,103,104,27,4,107,108,32,65,6,134,54,67,35,69,93,59,70,8,80,39,114,136,115,9,10,40,11,43,73,96,45,74,46,120,13,14,123,41,16,51,52,128,77,18,19,53,20,21,81,125,55,56,116,57,7,106,129,49,133,25,61,60,135,78,118,84,105,2,37,62],mps_ap_trip:125,mrginit:57,provis:[73,116],mps_ap_frame_push:[115,64,93,7],manner:[35,59,24,52,77,123,116],strength:[133,106],recreat:[69,107,116],latter:[101,35,57,106,29],transmit:[74,49,80,50],shieldcaches:15,mps_ap_frame_pop:[115,64,93,7],what:[0,1,91,29,88,127,106,107,32,65,66,67,35,93,7,71,8,80,9,72,39,40,11,45,74,46,120,76,14,50,16,52,77,19,53,20,54,81,55,56,116,57,58,24,133,134,125,26,84,141,140,61,85,123],lexic:[20,25],phase:[67,57,96,39,72,9,105,108,103,12,85,141],excus:28,freeblockcompar:103,notion:[46,8],emptys:107,opposit:[87,88,89,90,91,92,29,94,95,96,97,99,100,101,102,82,104,105,106,108,93,103],protocol:[1,91,93,30,99,101,103,64,107,32,54,67,34,35,69,7,8,80,72,115,39,116,42,74,120,75,15,77,53,66,57,61,125,84,137,141,28,85,86],involv:[92,29,94,30,101,103,104,105,106,107,108,7,40,11,12,96,46,75,16,52,77,131,54,81,55,57,133],btget:29,predecessor:25,segpreflow:48,likewis:[8,96],pooladdrinframemethod:7,watson:47,mps_ap_fil:[125,26],first_fit:138,mps_alloc_dbg:77,emb:[63,54,103],walgenbach:47,"__date__":36,rung:27,septemb:47,steal:[103,45],fragmentation_limit:112,fp_size:77,traceend:[35,50,57],charact:[46,92,132,49,61,103,105,4,40,41,20,6,21,85,123],awar:[88,24,50,130,11,54],erez:47,drawn:[103,107],awai:[74,35,57,24,50,16,72,40],accord:[125,88,29,95,30,99,105,107,108,66,67,68,35,114,40,117,12,46,50,51,131,79,54,133,138,85,141],lamport:47,preprocessor:[95,69,132,14,25,26,79,49,85],dbgpool:[14,77],map_priv:78,han:[139,47],howev:[0,88,90,91,92,29,94,96,99,105,106,6,134,125,67,35,93,59,71,8,9,39,14,43,73,45,46,50,75,49,15,52,78,19,53,20,54,81,56,57,24,25,61,84,139,140,41,85,141],eventcom:80,brad:47,messagecollectionstatscondemnedsizemethod:32,com:[1,68,59,136,20,6,73,85],col:53,con:[0,91,47,93,25,101,69],epdldebugsig:54,toni:[75,29,47,52,54,139,28],ref_o:135,resumpt:118,dconfig_var_cool:[6,26],guil:25,wider:[20,6],guid:[29,30,79,103,114,54,34,35,69,72,11,68,130,15,16,20,80,127,128,24,60,61,106],mrgrefsegscan:57,speak:[141,55,92],degener:97,convolut:35,subscrib:136,insert_link:125,withreservoirpermit:[30,35,107],mps_objects_step_t:77,foodescrib:50,pool_o:[119,13,112,37,115,4,11,138,43,109,126],ident:[128,75,29,132,71,30,97,121,79,102,4,107,54,19],aix:94,gnu:[0,132,25,26,6,21],repack:47,properti:[29,30,97,99,101,103,104,105,4,33,109,80,34,112,37,72,115,41,43,45,13,47,11,66,126,128,58,24,54,138,86,61,62],mps_lib_memcpi:[49,66],aim:[20,47,25],zerokei:103,publicli:[46,25],thrash:[46,47,96,101,104,106,108],aid:120,getcurrentthreadid:118,vagu:[24,92],cons:93,cont:20,conv:[66,69,29],sockaddr_in:74,freeblockofsplaynod:103,cond:10,conf:[85,47,62],dumper:[80,72],op_env:26,descent:[39,103],incorrectli:[135,93],perform:[0,87,90,91,29,88,30,99,103,104,27,106,107,108,6,68,67,34,35,69,7,70,71,80,9,72,39,10,40,11,12,96,45,46,120,75,13,47,48,130,15,16,127,77,128,54,55,56,116,57,58,24,133,25,125,112,135,26,84,105,141,61,85,62],descend:[103,25],synch:107,mps_mvt_free_siz:112,fragil:84,evid:[26,93],quentin:47,rail:88,hand:[34,35,93,29,46,14,79,61,106,40,11,66,126,55,56,86],reservoirfinish:63,rais:55,poolarena:[54,75],kept:[67,35,57,91,70,14,50,90,113,9,84,121,106,41,133,61,85],undesir:[32,112,75,114],scenario:[125,35,54],mps_size_desc_t:24,thu:[0,46,35,57,91,94,95,108,25,134,101,112,87,104,40,41,66,125],hypothet:[24,54],client:[0,63,90,91,29,88,73,30,97,130,79,87,103,104,64,106,107,108,32,5,54,67,34,35,69,93,7,70,112,8,80,72,94,39,128,40,11,42,119,44,96,45,74,46,120,50,140,41,48,14,15,121,52,77,18,19,53,37,21,55,56,116,57,58,65,66,24,49,122,61,125,135,26,131,118,84,105,86,2,28,85,62],wherebi:[0,91,7,24,97,131],thi:[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,18,19,20,21,23,24,25,26,27,28,29,30,32,35,36,37,39,40,41,42,43,44,45,46,68,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,48,69,70,71,72,73,74,75,77,78,79,80,81,82,84,85,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,111,112,113,114,115,116,117,118,119,120,121,123,124,125,126,128,130,132,133,134,135,131,137,138,140,141],ringfinish:[27,114],victim:[21,52],ifdef:85,unbuff:[48,138],poolcondemn:116,amcseggen:35,threadreturn:118,spread:[46,133,95],"0x1003f9ae0":26,board:[35,47],"2fe288":80,lcc:132,filenam:21,"0x00000001003fb130":26,reassign:[24,103],percentag:112,zct:[90,110],born:108,forcibl:52,messagestruct:[32,57,114],morereturn:26,overcom:[78,15,25],pthreadextfinish:52,type_integ:[61,41],plu:[59,112,24,8,107,20],someclass:54,pose:61,confer:47,messagereturn:32,gartner:25,"0005e040":80,obj:[35,26,57,8,84,121,55,77,113,10,61,41,125,141,28,128],poolscan:[26,116],eventdump:80,curiou:21,"float":[87,88,35,93,95,99,82,27,118,107,108,105,73,85],mps_arena_walk:77,bound:[0,90,58,92,29,94,96,97,25,102,103,26,105,126],lewi:[47,25],opportun:[77,103,58],myformat:6,protocolsomeclassguardian:54,mps_label_t:[21,79],accordingli:[5,25,49],wai:[125,29,128,96,130,99,101,103,104,106,107,108,32,6,134,66,67,35,69,113,59,36,8,9,114,39,40,11,117,12,45,46,120,50,75,41,14,15,16,52,77,124,18,123,20,54,57,24,49,70,133,25,61,135,26,131,78,28,85,62],segment:[63,87,92,29,30,97,99,101,105,106,107,108,109,21,67,34,35,93,7,8,80,72,39,40,116,117,12,96,74,48,15,51,77,18,54,56,126,57,23,66,24,134,138,28,141],lowest:[48,29,93,68,10,138],dec_assembl:68,traceid:66,st85:103,somehow:[74,25],"true":[0,88,29,30,79,103,107,32,66,48,35,69,93,7,8,80,114,39,10,41,42,12,45,119,46,11,51,20,54,55,128,125,135,84,138,61,141],cached_count:19,reset:[35,128,7,29,66,8,15,39,107,41,21,28,141],maximum:[63,67,97,58,29,112,8,85,74,77,103,19,20,66,109,80,45],absenc:[49,121,77],emit:[74,35,93,50,130,39,107,116,21,12,80,85],alongsid:[54,90],"abstract":[63,88,29,103,66,67,7,70,8,72,39,10,45,46,47,76,15,51,52,77,54,24,25,85,141],mps_sac_class_limit:19,postscript:[91,105,16,25,102],refsetismemb:30,pirinen:[67,35,57,23,47,24,7,121,99,101,77,39,104,105,53,116,32,139,85,92],encrypt:84,testor:70,amcgencr:[35,80],mps_begin:77,jone:[46,35,90,69,47,94,8,16,99,104,106,116,32,139,12,28],test:[0,87,29,128,94,96,102,103,21,114,6,54,125,132,71,72,39,10,40,49,117,12,45,74,46,14,41,130,18,66,56,57,25,134,60,113,26,138,141,61,85,86],shrink:[112,24,8,92],jonl:[139,92],mps_key_arena_s:[44,61,45],arenainit:[8,75],iwmm:47,config_:85,mps_class_mvt:[112,44],concept:[39,85,47,40],mps_ap_frame_select:7,consum:[0,99,64,45,65,85,106],datum:130,prot_writ:[81,78,56],dalton:47,middl:[35,91,24,96,103,99,120,39,26,106,54,125,45],zone:[67,23,24,8,134,18,40,12,141],graph:[87,101,89,90,91,95,99,60,39,104,105,53],yve:47,supposedli:93,jvm:25,brown:47,mps_pf_lii3gc:132,congest:74,condit:[87,93,30,99,103,105,107,32,6,54,35,59,10,12,119,46,14,50,16,131,20,66,55,24,125,61,141],octob:47,word_act:29,seemingli:[24,26],operator_:61,administr:[16,25],bring:[103,45,29],"12th":47,gui:47,rusag:49,upper:[112,69,79,85],htm:68,oldspac:[94,88],cost:[89,90,94,96,97,114,101,103,104,105,4,125,67,35,59,71,72,9,41,75,47,19,20,21,7,24,25,112,84,61,85],alfr:47,bole:47,appear:[1,91,92,30,99,104,3,108,54,35,114,41,12,96,46,121,78,79,20,21,128,24,26,61,85],protocolclassstruct:54,uniform:[69,93,29,116],mps_os_i5:132,setter:107,va_list:[119,77,39,65,54,125,45,141],tolimit:29,redirect:35,defici:63,gener:[0,4,6,7,8,11,12,16,18,19,20,23,24,25,26,28,29,30,32,34,35,37,39,40,41,42,43,45,46,47,50,51,52,53,66,55,56,57,58,61,1,64,65,54,67,68,69,70,71,72,74,76,77,78,79,80,81,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,101,103,104,105,106,107,108,109,112,113,116,117,118,120,130,124,125,127,133,134,135,131,137,138,140,141],"1003fa7d0":21,disclaim:[20,59],failnoteseg:54,lii6gc:[6,132],mps_os_ia:132,weakref:25,attrpm_no_read:66,behav:[74,46,91,14,16,79,102,131,107,54,56],macintosh:[85,47,132],regardless:[35,45],extra:[90,29,96,99,101,107,32,35,111,8,9,40,116,118,119,46,75,15,130,78,20,125,45,137,28,141],messagepost:32,marker:[88,120,93,94,61,64,55],mobil:35,prove:[87,35,93,94,135,114,82,104,116,61],live:[0,87,89,90,91,93,88,96,97,101,82,104,106,108,68,35,71,37,113,9,11,46,120,13,47,14,50,131,19,116,57,58,2,135,26,41],suppos:[42,120,19,29],preturn:[107,116],mps_capac:58,allocmutators:107,finit:74,elseif:20,gcstart:12,sigstack:81,logarithm:132,graphic:[74,92,24,25,80,139,85],amcfinish:35,"0x519705e9":28,car:[26,61,47,84],prepar:[0,58,24,26,19,116,125,73,56],"0x1003f9c08":26,prehistori:8,can:[0,1,2,3,6,7,8,9,11,12,13,14,15,16,18,19,20,21,23,24,25,26,27,28,29,30,32,35,36,39,40,41,43,44,45,46,47,68,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,48,69,70,71,73,74,75,77,78,79,80,81,82,84,85,87,88,89,90,91,92,93,94,95,96,97,130,99,100,101,102,103,104,105,106,107,108,110,112,113,116,117,120,121,122,124,125,128,132,133,134,135,136,138,140,141],boilerpl:54,heart:[88,35,91,92,116,105,106,84,42],mps_arena_t:[0,93,94,79,4,109,112,37,115,11,43,44,45,119,120,13,77,55,126,128,58,24,135,138,140,61],mps_root_create_fmt:120,topic:[34,127,11,16,79,41,61],heard:46,abort:[14,84,39,26,49,21,61],occur:[0,88,90,91,93,94,96,130,99,101,102,82,104,105,106,107,108,54,35,114,9,12,45,74,14,16,128,66,56,57,125,131,61],multipl:[1,87,90,29,88,94,95,2,100,101,103,104,105,108,80,67,35,93,70,8,72,11,12,45,46,75,15,130,52,77,131,19,53,20,54,126,128,24,82,25,125,135,118,140,61,86],bjarn:[46,25],write:[0,90,91,92,94,30,121,130,99,101,102,103,105,106,107,108,33,6,54,67,34,35,59,80,72,136,40,11,45,74,46,120,13,47,49,123,50,16,51,77,18,79,20,21,81,56,57,23,66,24,25,134,125,135,78,5,84,141,140,61,62],uncheck:[10,27],product:[1,87,127,69,93,59,36,14,37,55,77,39,26,85,40,43,6,21,45],segloreturn:30,f_setfl:74,arenadescrib:75,mps_key_mvff_arena_high:[48,44,138],explicit:[46,90,75,92,88,130,16,25,77,39,54],pooltrivbufferinit:116,"0x00000001003f9b80":26,mps_ap_addr_in_fram:7,approx:67,"_ts_":77,softrefer:[105,106],shieldcov:15,still:[87,90,83,29,96,97,130,103,104,27,113,107,108,32,6,80,67,35,93,70,9,39,40,41,12,45,46,14,116,16,77,128,124,21,55,57,25,135,26,28,141],ieee:47,dynam:[87,90,91,93,96,97,99,100,82,104,105,106,32,35,7,8,114,74,46,75,47,130,54,81,56,133,103,25,135],conjunct:[90,85,70],protocl:74,precondit:[32,107],window:[1,87,92,70,49,96,132,51,114,82,85,11,20,6,140,66,45],tsmessag:130,non:[91,29,73,95,30,99,103,104,27,106,107,2,32,5,66,67,68,35,69,93,59,70,11,8,72,39,41,42,43,12,96,45,74,120,50,75,47,14,15,52,128,20,54,55,116,57,7,24,49,25,61,118,84,137,105,28,141],noo:117,recal:[75,61],halt:[87,15,93],halv:104,supersed:7,varag:65,half:[104,51,29],now:[0,88,91,29,96,28,103,116,107,108,125,35,7,39,40,41,44,119,46,75,130,15,121,18,21,57,24,25,12,61,141],provision:67,discuss:[67,88,36,49,15,16,52,101,39,136,107,54,135,61],nor:[74,90,24,96,97,130,101,39,105,19,107,108],introduct:[63,1,29,73,30,103,27,114,107,65,32,5,6,68,66,67,34,35,69,7,36,8,76,80,72,38,39,10,40,116,42,117,12,74,50,75,48,15,130,51,52,77,124,18,123,20,54,81,56,127,57,24,61,60,78,134,3,28,85,141],critiqu:47,obj_scan:[113,84,55,61],drop:[74,101,35,57,130,60,9,20,110],buckets_pool:41,sendto:74,januari:47,splaytreeinit:103,replai:[80,107,116],buckets_scan:41,replac:[88,35,61,75,94,14,11,124,25,55,77,103,18,113,24,65,54,12,41],wrap:[46,50,15,101,77,82,84,20,117],replay:[80,72,107,116],significantli:[67,46,75,29,24,133,39,27],year:[91,47],operand:[66,26],happen:[91,95,96,130,103,106,107,125,67,35,69,7,111,11,40,41,12,119,46,15,75,14,50,16,52,77,78,19,54,55,56,57,129,24,28,26,140,61],"0000178ea03acf6d":80,shown:[26,57,104,101,135,78,27,41,21,125],space:[125,88,90,91,92,93,94,95,96,97,99,102,104,3,106,107,108,32,78,109,66,67,48,35,69,71,8,80,9,72,39,40,41,42,12,45,46,47,76,14,116,16,51,77,124,18,19,53,138,20,21,126,57,58,2,24,105,25,61,112,26,121,134,64,28,85,128],gdbinit:[21,26],overcommit:[94,96],stuff:[74,35,12,85,107],rational:[95,66,85,72,76],undead:[82,90,97],argv:[120,26,3],mps_message_t:[0,135,58,41],carl:47,argc:[120,26],card:[91,47,108],care:[125,88,35,75,107,93,66,24,30,50,120,40,41,20,54,55],couldn:[35,58,120,55,77,41,12,61],unwis:77,lambda:[135,26,41],directli:[87,90,92,30,100,103,106,107,108,21,35,59,36,9,114,39,10,73,96,74,120,50,130,52,66,56,57,25,134,125,135,54,85],subrang:29,zag:103,yourself:[61,45,62],act_on_range_high:29,ring:[34,35,57,75,76,8,52,114,27,118,32,91,66,30,56],size:[2,83,8,11,13,14,15,16,18,19,20,21,24,25,26,28,29,32,35,132,37,39,40,41,43,44,45,46,49,54,55,57,58,60,61,62,63,65,66,48,69,70,71,74,77,78,79,80,82,84,85,87,88,89,90,91,92,93,94,95,97,99,100,101,103,105,106,107,108,109,112,115,116,120,122,125,126,127,128,129,133,134,131,138,140,141],sheep:107,silent:15,caught:140,sigvec:[81,56],checker:77,cumul:23,yip:[96,47],especi:[46,90,68,94,24,99,77,104,27,106,40,108,85],prot_read:[81,78,56],mostli:[29,96,97,130,79,64,4,65,33,6,34,35,71,8,41,43,46,13,47,14,16,77,131,37,66,58,25,26,84,105,61,62],setrankset:107,than:[0,87,90,91,92,29,88,94,95,96,97,98,99,101,102,103,104,27,106,107,108,65,7,134,66,67,68,35,69,59,71,8,80,114,39,128,40,11,45,130,74,46,120,75,105,14,41,16,52,77,18,19,138,20,54,81,55,56,116,57,58,23,79,2,24,49,133,25,61,125,112,26,131,118,84,137,64,141,140,28,85,62],browser:25,testnod:103,fork:91,delic:11,anywher:[24,46],deliv:[74,57,25,36],mps_thr_t:[120,104,140,61],engin:[67,123,25],longword:[90,97],callback:103,lumpi:58,begin:[88,91,29,95,99,101,103,104,3,32,6,67,35,69,36,116,45,14,50,130,77,79,20,125,57,105,133,137,27,28,85,141],importantli:85,neatli:[74,46],unalloc:107,mps_alloc_pattern_ramp:[35,131],sigpwr:52,multiprocessor:[75,47],amcreclaim:[35,12,39],fixemerg:35,mrg:[34,57,121,72,42,32],steadi:24,mrb:94,shieldleav:[117,15],define_buffer_class:107,maint:85,concurr:[1,88,75,92,47,52,101,135,106,53,108,91,54,12],obj_delet:[41,128,11],ground:106,onli:[1,2,7,8,9,10,11,13,14,15,18,19,20,21,23,24,25,26,28,29,30,32,35,36,37,39,40,41,43,44,45,46,49,50,51,52,53,54,55,56,57,59,61,62,63,64,65,66,67,68,69,70,74,75,77,78,79,80,81,82,84,85,87,89,90,91,92,94,95,96,97,130,99,100,101,103,104,105,106,107,108,112,113,115,116,119,120,121,122,123,124,125,128,133,134,135,131,140,141],ratio:112,busili:9,tracedescrib:50,overwritten:[35,57,94,9,26,106],cannot:[0,89,90,91,29,30,130,99,100,101,103,104,105,106,32,66,67,35,93,8,9,39,11,43,45,46,41,14,15,16,51,77,131,79,53,54,57,24,133,82,125,135,84,61,85,62],mps_io_writ:49,seldom:102,hash_t:[128,41],mps_key_mvff_first_fit:[48,44,138],zaphod:29,segsummari:23,concern:[67,46,94,96,16,104,39,26,106,107,12,61],splaytreesearch:103,"0x000000010007b14a":26,v40f_html:68,between:[0,1,89,61,91,88,30,99,28,101,102,103,90,105,106,107,108,6,134,80,35,69,7,132,112,8,9,114,39,40,41,44,96,45,74,46,75,47,49,116,16,51,52,77,19,20,54,100,87,57,58,79,24,12,125,135,84,37,85,141],"import":[125,29,99,104,105,106,107,21,35,69,7,71,72,9,10,40,41,46,120,50,52,18,79,20,66,24,25,84,61,85],bufferclass:[48,107],style:[34,7,29,76,24,50,25,40,116,20,54,118],inflex:[104,16],blame:46,mono:25,pertain:57,nearbi:[97,26,16],inconsist:[20,140,99,24],evict:91,overview:[1,29,30,130,103,114,5,65,134,68,67,34,35,7,36,8,76,80,72,38,39,40,117,73,118,74,15,75,48,121,50,16,77,78,54,81,127,57,24,70,61,122,28,85,141],dispatch:[35,25,40,41,12,61],mps_pool_class_epdr_debug:77,exploit:[112,37,7,40],splayroot:103,damag:[20,96,59],resort:41,invert:[99,29,25,108],invers:[87,18,29],fixabl:116,sparecommitexceed:8,derefer:2,linkseg:57,"0x000000010000261b":26,thesi:47,"0x000000010002686d":26,mutandi:103,pedant:35,epdlpoolclass:54,trick:[39,69,61,103],sizeisalign:[14,66],amcscan:[35,26],findshortresetrangehigh:29,stdout:49,metric:[35,98],henc:[87,89,91,103,104,106,107,108,54,48,35,10,41,46,75,116,18,80,55,56,57,24,125,78,28,141],worri:[46,75,24,15,16,25,40,41,125],susp:52,eras:25,prot_:85,mps_ss:40,develop:[1,29,130,103,104,107,32,6,80,68,35,69,59,36,71,8,39,10,43,73,45,74,47,14,15,16,51,52,77,124,54,81,117,56,127,57,7,24,25,60,141,28,85,62],proto:[72,7],epdldebugcheck:54,epoch:[49,8,66],knuth:105,document:[1,119,29,73,30,79,103,104,3,114,107,124,32,5,6,134,66,67,64,35,69,59,36,8,76,80,72,94,39,10,40,116,44,96,45,74,46,50,47,68,14,15,130,52,77,78,123,20,54,81,125,56,57,7,24,105,25,12,60,131,27,140,85],finish:[0,63,92,95,30,99,87,103,27,107,108,32,21,67,48,35,8,114,41,44,45,46,75,13,76,130,116,16,52,77,20,54,57,26,141],typesett:25,someon:[20,79,46],treadmil:[94,104,91,47],mps_addr_pool:[119,45],ranksetempti:107,tradition:101,rampfinish:20,traceanc:130,"9c000":80,tobt:29,printezi:47,unflush:21,bitmap:[91,92,99,104,105,21],touch:[35,128,14,107,95,125],speed:[46,35,57,91,29,112,16,72,25,39,18,105,19,84,21,12,125,62],versu:35,death:[87,57,47,112,24,41,80],struct:[63,94,30,79,103,27,107,2,32,65,66,35,69,7,11,8,80,114,41,44,118,74,120,49,15,121,51,52,18,19,20,54,55,57,58,61,125,137,141,28,85,128],mmap:[94,96,78,106,124,85],desktop:105,identif:85,treatment:91,versa:[67,8,11,25,41,30],avgsiz:[20,48],earli:[46,47,29,30,15,130,25,93,105,99,40,114,96,85],nielsen:47,tobas:29,read:[0,92,29,97,79,101,104,105,106,107,108,32,78,66,67,69,7,70,8,80,11,73,45,74,120,75,13,49,50,121,51,77,18,21,81,55,56,57,24,25,134,135,26,140,41,141],compatfield:69,amc:[34,35,57,58,79,14,37,72,134,39,26,131,4,40,116,33,43,141,12,61,62],amd:132,awlstruct:141,usefulli:35,rootdescrib:75,mps_awl_find_dependent_t:11,output:[74,14,50,80,72,103,26,105,79,49,6,21,85,123],downward:[24,45,29,138],shield_depth_width:30,iff:[141,134],"0x00000001003f9a58":26,squirt:50,bufferarena:107,sixth:61,"0000178ea03f67b5":80,aquir:139,nmk:6,src:85,central:[105,80,91],greatli:[46,6,104,133],arenafin:[57,121],degre:[77,79],wolf:47,mps_telemetry_label:21,wold:2,backup:56,processor:[1,90,91,92,93,96,97,99,100,101,82,104,105,106,107,108,125,132,40,11,120,49,15,18,79,21,25,60,85],wordindex:29,bufferscanlimit:141,nurs:15,your:[1,89,102,21,6,80,71,114,49,45,46,120,41,14,50,131,66,127,24,125,135,26,84,61,62],stare:11,log:[74,7,66,49,50,80,72,107,6,21,85,130],unflip:121,area:[88,90,91,92,93,95,30,97,99,100,105,107,67,39,96,45,46,16,78,20,24,134,138,28],aren:[1,35,107,59,40,41,66,140,125,29],splaytreecheck:103,haskel:[16,47],start:[0,88,89,91,92,29,106,30,99,103,104,64,4,107,65,6,109,54,67,48,35,93,112,8,80,9,114,115,39,40,11,43,44,45,119,120,50,13,41,130,131,79,138,20,21,126,58,24,133,25,61,125,26,84,105,86,140,37,62],amcreclaimnail:35,low:[63,29,94,30,101,103,105,108,32,67,34,7,132,72,39,11,45,46,48,49,52,77,18,21,55,58,24,25,84,138,85],lot:[67,46,35,128,58,14,8,16,39,25,134,77,9,18,24,40,108,20,141],poolxxxstruct:137,customalloc:47,stanford:47,"default":[0,21,107,6,109,54,69,112,72,49,74,41,14,50,123,20,80,126,26,84,137,138,61,85],segtypep:35,bucket:[87,128,91,92,93,108,41,61],scanner:[34,120,97,23,68,76,72,40,39,107,84,85,141],ring_for:27,decreas:[46,133,75,92,106],fput:[46,123,61,49],valid:[88,91,29,30,114,100,103,106,107,65,125,93,7,8,72,10,41,96,45,119,120,50,75,11,16,77,80,81,56,116,57,58,134,26,28,141],you:[0,1,88,94,79,101,87,3,106,107,32,6,66,67,35,44,69,113,59,71,37,80,9,115,39,136,40,41,43,119,12,45,74,46,120,50,13,105,14,11,16,77,78,19,138,20,21,55,128,58,24,49,134,125,135,26,131,84,64,140,61,85,62],poor:[46,58,95,96,16,9,108,61],registri:80,gnumak:6,docstr:80,string_:[26,61],peak:[24,72,61,45],pool:[1,27,4,6,7,8,11,12,13,14,15,19,20,21,23,24,26,28,29,30,32,33,34,35,132,37,39,40,41,42,43,45,47,130,50,54,55,57,58,59,60,61,62,63,64,65,66,67,48,69,71,72,75,76,77,79,80,84,85,86,87,88,90,91,92,93,94,96,2,99,102,105,107,108,109,111,112,113,114,115,116,117,119,120,121,122,123,125,126,127,134,135,136,137,138,140,141],reduc:[87,90,91,94,97,99,100,106,67,35,8,9,40,12,45,46,47,121,23,24,133,84,85],deliber:[96,61],munro:47,inevit:29,attardi:[139,47,25],mps_chain_destroi:[58,61],messi:85,unblock:[52,56],publish:[87,136,85],af_inet:74,articl:61,foster:25,xiaohan:47,segv:56,horror:20,mpm:[67,74,57,69,29,76,30,50,123,40,116,137,66],mpw:85,verb:[96,29],mrgfinish:57,butenhof_1999:52,veri:[1,88,92,29,95,96,97,99,104,64,106,107,108,80,67,35,69,93,71,8,72,9,40,11,117,12,46,120,75,14,41,16,19,138,54,126,57,23,24,133,25,61,125,112,121,105,28,85,123],mrgregist:57,parentnam:54,maximis:138,recvfrom:74,emul:[1,51,11],ismm:47,anal:[24,80,75,52,56],dimens:[102,105,85,47],tag_siz:41,modula3:25,"0x1003f9878":26,consecut:[112,88,93],mps_clocks_per_sec:49,modular:[14,96,77,25,46],unsurprisingli:35,excess:[65,12,25],strong:[67,29,25,101,135,104,105,99,40,41,65,106],modifi:[88,91,29,30,99,103,27,68,7,36,8,9,39,44,96,74,50,77,56,58,25,105],arena:[0,63,114,91,29,128,106,30,2,130,79,102,82,112,27,4,107,108,32,65,109,54,67,34,35,44,69,93,7,71,8,80,72,115,39,40,11,43,12,96,45,119,120,75,13,41,48,14,15,117,52,77,18,19,53,138,21,55,56,126,127,57,58,66,24,61,1,135,26,121,118,134,105,141,140,37,86],ahead:[35,91,39],garwick:47,amount:[63,90,29,99,103,105,106,107,109,67,35,71,8,9,40,11,45,46,78,20,66,81,57,58,133,112,18,138,85,141],"0x1003fb130":26,put:[88,91,29,94,96,79,82,107,108,67,35,114,39,11,12,45,74,50,121,52,77,20,128,23,24,137,41],mps_telemetry_get:21,famili:[132,85,25,92],emptyinternals:107,segmyseg:54,dangl:[67,90,7,96,16,39,2],dec_alpha_calling_standard:68,sparecommit:8,findlongresetrangehigh:29,azaguri:[91,47],taken:[35,58,8,16,104,9,10,105,41,20,66,30,45,141],zorn:[46,91,92,47,25,139],tracebegin:[50,57],keystruct:65,splaytesttreemethod:103,mps_key_mean_s:[48,112,65,138,109,44],pthreadext:[52,56,118],histori:[47,76,8,25,20,21,96],amcinit:35,btfindresrangehigh:29,mps_arena_reserv:45,templat:[77,2],abcdef9811c7340bc6520f3812:[3,114],unreli:[74,46,16],"0x0000000100001947":26,phrase:102,mrgrefsegclass:57,inescap:77,anoth:[0,87,89,91,92,29,88,94,30,99,100,103,104,105,106,107,108,65,66,67,35,7,9,39,11,12,45,119,46,120,75,41,16,52,128,19,54,56,57,58,23,79,24,131,133,25,125,135,26,84,141,140,61,123],compactifi:[91,47],reject:[46,84],type_t:[125,128,61,41],undergradu:25,unlink:[57,104],s7ppac:132,addr_method:44,egc:[6,132],help:[46,57,2,88,44,96,50,130,72,61,39,26,40,84,32,21,139,12,54,45],reservoir:[63,34,30,72,77,21],soon:[67,135,120,90,91,53,14,84,130,9,99,61,39,40,108,6,55,45],pthreadextstruct:52,amcbufclass:35,held:[75,7,70,8,52,19],ffi:28,hierarchi:[91,30,97,100,101,105,106,107,108,54,96,141],paramet:[125,91,29,94,30,99,103,116,107,65,134,21,35,69,7,112,37,80,115,49,43,12,118,74,120,50,13,76,14,11,51,52,77,18,19,20,54,81,55,56,79,66,24,25,61,60,78,138,140,28,85,141],mps_class_mv_debug:[109,44,2],map_vari:124,classofpoli:54,poolfre:[48,39,75,66,116],mps_key_t:[65,44],finer:[30,75,106],nofault:28,sentenc:20,cet:85,arenaalloc:[24,8],foor:27,average_s:[138,109],summaris:[24,68],fulli:[91,79,10,105,116,54],backtrac:[14,80,26],ifip:47,heavi:[46,80],quantum:12,tv_sec:49,beyond:[120,25,45,40,6,55,85],todo:41,event:[0,130,104,116,107,6,21,59,72,39,49,45,74,46,41,14,50,16,128,20,80,55,57,135,26,61,86],mps_sac_alloc:19,safeti:[34,128,69,70,52,72,107,75,140,56,86],robert:47,attrincr_wb:66,enomem:[74,78],gpl:59,pun:[69,79,104,84,61,86],justif:[57,29,76,24,30,3,32,54],signif:75,reason:[125,29,99,103,105,106,107,108,7,80,48,35,69,93,59,8,39,40,11,73,45,46,120,50,75,14,15,130,123,53,20,66,55,56,116,57,23,24,49,133,25,135,84,138,141,62],base:[63,61,92,29,128,30,97,99,100,103,90,105,106,107,124,6,134,54,67,68,35,93,7,132,8,80,115,40,11,43,44,45,74,120,13,47,123,41,104,51,78,79,20,21,55,116,57,129,12,25,28,60,113,26,84,138,141,37,85,62],dirk:47,classnamestruct:54,earliest:25,asm:68,basi:[9,80,29,107,134],launch:13,mps_lib_fputc:49,lifetim:[87,89,57,47,106,94,24,37,97,16,25,100,112,90,105,99,40,41,61,96,95],assign:[125,46,69,93,29,24,96,133,80,25,101,104,19,107,20,21,66,141],singleton:[32,30,57,27,107],obviou:[35,29,8,77,103,20,66,80],misc:[69,30,72,107,81,28],placehold:[137,35,61],uninterest:40,awldescrib:141,implementor:[87,54],miss:[90,96,99,100,101,103,104,27,107,67,69,8,73,74,47,15,52,18,20,57,24,134,26,105,28],mps_t_ulongest:[66,85,132],expand:[74,132,14,25,27,79,54,66],scheme:[0,87,91,92,93,99,101,3,106,71,41,120,47,50,16,21,127,128,25,135,26,84,105,61,86],adher:[68,69],getter:8,"0x1003fe820":26,mps_lib_fil:[57,49,50,103,123,107,141],ncc:47,std:[73,29],awlinit:141,grep:[20,21],prot_bar:85,nevertheless:3,greg:47,mps_message_:114,consumpt:88,toward:[46,105,29],grei:[67,87,35,57,24,30,72,39,123,53,116,12,141],randomli:[60,16],lii3gc:[6,132],"null":[30,79,103,105,116,107,65,35,69,7,8,41,44,74,46,120,15,11,50,130,52,77,128,123,20,125,55,57,24,113,26,61,141],juici:107,lie:[48,30,91,134],lib:[6,123,85],mps_ld_:[66,128,41],lin:47,mps_res_param:[14,19],align_up:61,exampl:[0,2,27,4,6,59,8,9,10,11,12,13,15,16,19,20,21,24,26,29,30,32,35,36,37,39,40,41,43,44,45,46,49,50,52,54,55,56,57,58,7,60,61,62,1,65,66,67,69,72,73,74,75,77,79,80,82,84,85,86,87,88,90,91,92,93,94,96,97,99,100,101,102,103,104,105,106,107,108,109,112,113,114,115,116,120,130,123,124,125,126,127,128,132,133,135,138,140],useless:21,command:[0,50,25,26,114,6,21,85],shieldlow:15,alignof:61,kai:47,mixtur:[88,11,84,25,79,41,12],capitalis:3,amcnailboard:35,maco:134,alpha:[34,107,68,132,72,83,6],getrusag:49,clear:[46,118,50,92,29,94,24,108,101,103,26,105,106,41,21,141,84,66,56,128],clean:[54,90,25,108],usual:[0,1,89,90,91,92,29,88,95,30,97,99,100,101,102,87,104,3,106,107,108,32,125,67,48,35,93,9,39,40,41,96,45,46,68,14,50,16,128,19,138,20,54,55,116,57,23,24,105,133,25,135,84,27,61,85],blend:25,awesom:35,iwooo:47,hyper:[87,35],mps_key_extend_s:109,current:[0,63,91,92,29,88,30,102,103,104,27,106,107,108,6,54,67,68,35,93,7,36,8,39,11,43,12,132,45,120,50,75,130,15,16,52,77,20,21,81,1,57,23,66,24,105,70,25,118,84,64,140,28,85,141],coerc:54,pretti:[78,40],"0x0000000100008ca2":26,queu:130,pooldebugmixinstruct:77,"__file__":77,protcanstepinstruct:51,nativ:[106,132],stavro:[139,92],arenawrit:121,"0x1003f9b88":26,"0x1003f9b80":26,grey:[39,57],firstparampoint:80,close:[1,46,91,93,59,88,112,24,108,135,74,87,41,20,85],"2fe374":80,particip:[141,7,116],won:[63,48,67,24,8,16,52,61,39,105,19,40,32,20,125,30,106],amalgam:6,numer:[80,82,25,11],poorer:103,res_v:[125,19],distinguish:[87,88,35,91,92,37,82,27,61,101,103,104,3,40,20,55],messageclass:[32,57,114],messageinit:[32,114],both:[125,90,91,29,30,130,99,103,3,106,107,2,32,134,54,48,35,69,7,70,37,80,9,39,40,41,45,11,123,15,16,77,18,79,138,20,21,56,66,24,25,61,135,84,105,141,8,62],delimit:[120,55,84],forgotten:26,ecma:25,myseginit:54,header:[88,91,92,94,97,99,100,104,105,106,5,6,35,69,37,72,115,11,43,73,13,79,80,55,84,62,61,86],linux:[1,34,70,132,52,72,26,85,11,6,140,56],stamp:[49,21],empti:[0,63,92,29,30,87,103,27,107,32,65,67,35,39,117,44,130,121,66,57,24,133,28,61,141],destructor:[46,90,91,47,88,25],newcom:41,threaten:[104,91,47],walter:139,anthoni:139,box:[91,92,99,101,82,106],bufferinitmethod:107,tracefindgrei:12,imag:[24,105,106,29,46],coordin:[24,96,58,77,41],partli:74,look:[0,63,91,29,88,95,30,103,106,107,65,21,11,8,9,114,39,40,41,44,47,14,50,16,128,123,20,54,55,57,24,134,125,113,26,84,141,85,62],typecheck:10,"while":[0,119,90,96,99,104,105,107,108,35,114,9,11,45,74,46,120,75,41,130,50,16,52,77,20,125,81,56,57,23,24,25,113,26,84,61,85,141],leftreturn:103,ought:[8,28,39],guido:25,loos:[87,105,25,107,92],loop:[125,88,128,91,29,112,118,135,9,27,56,40,41,117,12,61,45,141],prolog:[87,91,16,25],malloc:[1,46,69,92,93,129,8,16,25,61,96],mem_top_down:45,readi:[74,8,130,114,107,116,54,44,61],threadstruct:52,costli:[87,96,97],pedagog:[39,66,116],debug_opt:[138,43,109,2],shaw:47,grant:105,finalpool:8,traceinit:12,mps_res_t:[119,64,4,2,109,69,7,112,37,113,115,40,11,43,44,45,74,120,13,14,41,77,131,19,125,55,126,58,24,49,135,26,84,138,140,61,106],conflict:[75,8,69],imagin:[77,21,35],optim:[88,91,97,102,103,6,8,39,40,41,12,45,46,120,47,19,80,127,57,23,82,135,84,61],wilson:[87,46,89,91,92,47,88,95,97,16,99,101,93,105,133],dimm:90,temporari:[68,93,47,77],user:[0,11,94,96,99,102,107,21,71,8,116,45,74,14,50,16,77,80,24,49,25,54],yuan:47,specialis:[24,80,85,141],older:[87,46,35,91,132,95,96,89,55,9,105,106,108,80,61],mps_lib_memcmp:[49,66],www3:68,commonli:[67,88,90,92,93,14,96,50,100,101,102,105,108,97],arenacommitlimit:8,five:[67,35,92,112,96,120,9,40,55],weakest:106,"000ae0397334df9f":21,ipc:80,uninit:107,fflush:49,controlfre:130,subsequ:[74,46,35,57,91,23,88,130,39,90,32,65,12,45,141],march:47,actionstruct:141,characterist:[101,48,112,88],signal:[117,51,52,26,105,2,21,81,140,55,56,86],resolv:[46,66,104],manifest:[26,114],popular:[25,108],eec:47,mps_pool_class_epdl_debug:77,sketch:32,comparegreat:[66,103],creation:[48,57,91,107,7,97,121,72,134,77,135,93,64,53,41,65,21,141,61,45,92],some:[0,3,6,7,8,9,12,14,15,16,18,19,20,21,24,25,26,28,29,30,32,35,39,40,41,44,45,46,47,68,49,50,52,53,54,55,56,57,58,60,61,62,1,65,66,67,48,69,70,72,73,74,75,77,78,79,80,81,82,84,85,87,88,89,90,91,92,93,94,96,97,99,100,101,102,103,104,105,106,107,108,113,116,119,120,130,123,125,128,133,134,135,131,137,140,141],fragmentori:35,weaksplat:35,nloci:24,link_t:125,cgi:25,inframereturn:7,run:[0,1,90,92,29,88,94,96,97,130,99,100,104,105,106,107,6,54,67,48,69,93,59,11,8,80,9,114,39,40,41,45,74,46,75,47,68,14,50,16,52,20,21,81,125,55,127,128,66,25,134,60,71,135,26,84,141,140,61,85,86],epdrpoolclassstruct:54,step:[1,57,40,29,84,104,51,114,125,77,9,26,107,41,20,43,61,85],subtract:[0,46,40,93,28,105,107,84,55],faith:57,mps_class_mvff_debug:[138,44,2],dissimilarli:93,traceabl:[8,116],idr:52,lieberman:[89,47],idl:[58,45,86],slot_high:138,block:[0,63,89,90,91,92,93,88,94,95,30,97,134,99,87,101,103,104,64,4,108,112,109,80,67,48,35,69,113,111,71,8,9,72,115,39,41,43,119,44,96,45,74,46,120,75,13,14,11,16,52,77,18,19,138,20,21,55,56,126,128,58,79,106,129,24,49,133,25,61,125,1,135,26,131,84,105,141,2,37,85,62],compactli:[102,105,92],within:[1,88,90,91,29,30,104,27,106,107,108,134,80,48,35,114,9,10,40,96,45,119,46,120,15,14,50,77,20,66,55,56,24,28,84,105,141,61,85,62],toft:[47,25,106],protstepinstruct:51,mps_message_clock:0,ensur:[63,90,92,93,30,99,101,103,104,105,107,21,35,69,7,11,8,9,114,39,40,41,117,45,74,46,120,75,13,49,15,52,51,123,54,125,55,24,133,25,60,135,118,84,61,85],diag_:50,carnegi:47,fence_templ:2,reserve_depth:112,properli:[57,49,130,77,105,19,21,56,45],"0x000000010001287d":26,newer:[80,12],branch:[35,91,105,40,125,12,85],mminfo:20,info:[67,74],utc:[21,26,47],trishul:47,mps_defin:[135,121,41],similar:[87,88,89,90,91,92,93,30,97,130,99,100,101,102,82,104,3,106,107,108,66,59,112,8,39,41,96,45,74,120,75,49,121,52,123,20,54,56,57,24,25,125,105,61],w3i3mv:[6,66,132],obviat:77,flush:[0,35,49,30,15,80,105,19,107,32,21,61,45,141],doesn:[63,91,29,96,103,105,107,32,65,66,67,71,8,80,9,39,40,41,12,45,46,11,19,53,20,54,56,128,24,125,118,137,141,37,62],lectur:[21,47],incomplet:[74,69,94,49,79,134,77,66],dconfig_var_df:85,aggrav:46,pronounc:90,titl:[68,17],tito:47,setsparecommitlimit:8,appendic:34,proxi:88,setenv:6,sigcont:52,draw:[89,105],gigabyt:[87,24,104,92],sigsuspend:[52,56],w3i3m9:132,william:47,drag:47,eval:[135,26,41],dram:[90,105],infrequ:[9,97,106],depth:[57,75,47,112,30,15,97,61],unconnect:100,mps_arch_al:132,fclose:[49,41],attrbuf_reserv:66,searchbas:29,compact:[67,90,91,92,47,96,97,25,100,82,105,106,20],tsba:24,easiest:[77,75],mps_arena_park:[37,45,108],aris:[88,90,59,24,103,39,84,20,55],eventbuff:80,michael:47,poolclasslo:29,rdoss:47,scanlimit:[39,141],relink:[57,104],jump:[20,116],download:[6,61],poke:[32,69],blockpool:20,cell:[94,101,91],experiment:[29,25,132],chilimbi:47,mps_clock:[0,49,114,79],cele:25,munmap:78,ierusalimschi:25,segsiz:[30,141,35,39],becom:[0,88,90,91,96,99,87,27,106,108,35,9,39,40,41,45,119,46,120,16,19,53,125,57,23,24,82,25,134,135,105,139,61,141],accessor:[32,130,54,75,107],obsolesc:103,convert:[69,29,66,49,8,84,77,27,85,65,20,21,81,12,28,56,141],convers:[32,77,8,79,25],genr:35,chang:[87,119,90,91,29,128,96,97,130,99,101,103,104,3,116,107,108,32,65,6,66,67,35,69,36,8,80,9,40,41,42,117,12,45,74,120,75,47,14,50,16,77,78,79,53,20,21,57,58,24,49,133,121,105,141,61,85,62],perform_client_act:45,chanc:[14,35,140,77,24],"0x00000001000014e3":26,clark:[94,47],danger:[14,54,133],realloc:24,"boolean":[8,79,107,54,66,80],metaphor:77,hudson:[91,47],implic:52,jonathan:47,remaind:[88,35,133,107,12,141],exegesi:15,fillmutators:[8,107],benchmark:71,about:[0,119,90,91,92,29,30,97,99,101,103,104,64,106,107,108,32,134,21,67,35,69,93,7,112,37,80,9,72,39,40,41,96,45,74,46,120,75,130,113,15,16,77,123,53,54,55,56,116,57,58,66,24,82,25,61,125,135,136,118,140,28,85,62],fri6gc:[6,132],retriev:[0,58,29,130,121,102,135,105,45],salad:105,perceiv:[0,25],attrgc:66,ride:39,awlscan:141,meet:[57,7,29,8,52,103,53,80,73,55,141],pedictor:12,control:[1,88,89,90,91,29,96,130,99,104,105,106,107,66,67,48,35,93,7,8,80,9,72,39,10,41,73,45,74,46,120,50,75,47,49,15,16,52,77,79,20,21,126,119,24,25,125,26,140,61,85,62],protic:47,mvffinit:48,"002b":21,protix:26,accesssetempti:30,buckets_t:41,"002d":21,sought:24,reservoiravail:63,link_:125,georg:47,acycl:10,trace_max:[66,8,12,30],circular:[95,104,27,47],prottramp:[81,26,51,56],precalcul:[57,141],bufferfinish:[57,107,116],apstruct:[69,107],obtrus:9,messagetypegcstart:130,messagefinish:[32,114],rove:[95,133],fastest:[105,125,91,84],mps_root_creat:[120,91,61,108],jni:108,"2fe2c4":80,splayfindlast:103,outer:137,mps_addr_t:[125,93,79,104,106,21,69,7,37,113,40,41,44,45,119,120,11,77,19,66,55,128,135,26,84,61],handl:[0,89,96,130,79,100,101,103,64,106,108,32,65,125,67,35,69,7,70,113,72,115,40,49,118,120,75,14,11,16,51,52,77,19,66,81,55,56,57,23,25,135,26,84,105,141,140,41,85,86],auto:[13,37,84,115,11,43,55,62],mps_build_gc:132,handi:[101,105,85,108],front:[88,57,58,97,45],mps_build_gp:132,type_pair:[21,26,61,84],somewher:[46,120,107,18,53,20],config_plinth_non:49,dominiqu:47,mode:[0,74,35,91,112,30,15,51,25,120,77,87,26,106,108,66,81,61,56,86],poolr:30,upward:[24,29,138],unwind:[20,121],accessnon:66,findlongresetrang:29,chunk:[63,20,56,45,24],mps_res_commit_limit:[14,19],special:[1,88,89,91,92,93,94,30,97,79,103,64,106,107,108,134,54,35,69,59,8,72,115,11,74,46,14,16,53,138,20,66,133,25,28,21,135,121,84,105,61,141],"th\u00e9se":47,influenc:[103,91,25],mps_lib_assert_fail_t:49,pooldescrib:[75,116],suitabl:[63,88,92,29,96,97,99,103,21,48,93,59,70,39,11,43,46,120,49,19,80,55,1,7,24,133,134,61,62],hardwar:[67,89,90,91,92,47,96,15,16,25,38,104,9,93,105,72,99,108,55,45],fmt_o:55,watermark:24,fmt_a:55,kilobyt:[98,96,58,61,92],transliter:[34,3,76],unwant:[80,25],ask:[67,34,35,61,91,7,46,24,15,121,25,38,18,19,119,55,45,62],mac:[6,47,100],timer:21,keep:[92,99,101,103,104,105,106,108,67,35,113,70,8,9,39,40,11,12,45,46,13,41,130,50,16,77,123,57,58,24,133,25,134,135,136,84,61,85,141],counterpart:[39,125,2],"universit\u00e9":47,austin:47,christoph:47,qualiti:49,perfectli:[46,107],xci3ll:[6,132],wrapper:[49,101,77,41,28,141],attach:[0,92,96,104,106,107,32,48,35,7,8,72,30,74,75,52,77,19,53,125,57,61,28,141],attack:96,withington:[97,47,139],prone:[46,65],configura:[121,85],deregist:[120,121,60,135,140,61,45,62],fuzzi:16,methodolog:47,eql:102,enqueu:[101,105,106,108],exactli:[87,90,91,29,94,30,97,79,108,32,66,35,11,74,49,16,51,77,20,54,57,85,62],rsp:118,ben:47,cpython:25,bloat:[32,46,15],bef:35,claim:[75,7,70,14,8,52,104,54,140,56],poolblacken:39,noprint:26,dubiou:[82,29],bet:[77,52],exhibit:[97,92],"function":[0,1,27,7,8,10,11,12,13,14,16,18,19,20,21,24,25,26,28,29,30,32,34,37,39,40,41,42,44,45,46,47,48,49,50,51,52,53,54,55,56,57,61,63,64,65,66,67,68,69,70,72,73,74,75,76,77,78,79,80,81,84,85,86,87,88,90,91,93,94,96,97,98,99,100,101,102,103,105,106,107,108,114,116,117,118,119,120,121,123,124,125,128,130,134,135,131,140,141],weiser:[87,46,91,47,25],threadringresum:118,mps_pf_align:[126,132,112,95,8,11,109,85,62],arenaaccess:[8,56],thereto:24,tabl:[89,90,91,92,29,99,100,101,102,104,106,108,134,21,34,35,132,71,80,72,110,39,40,11,41,44,45,120,47,15,18,66,127,128,24,25,28,113,26,141,61,62],need:[0,1,27,4,6,7,8,9,11,12,13,14,15,16,19,21,23,24,25,26,28,29,30,35,37,39,40,41,43,44,45,46,68,49,50,52,54,55,56,57,58,61,62,63,64,65,66,67,48,69,70,73,74,75,77,79,80,81,84,87,88,89,90,91,92,93,94,95,97,99,100,101,103,105,106,107,108,111,113,115,116,118,120,121,123,125,128,134,135,138,140,141],border:24,flip_mask:21,runciman:47,screw:39,unawar:108,pthread_sigresum:52,mps_message_type_fin:[0,88,96,135,41],singl:[1,87,90,91,29,88,94,30,97,103,27,106,107,32,67,35,69,93,7,70,71,8,122,9,72,39,40,11,43,44,96,118,75,130,52,51,77,18,53,20,54,57,24,133,25,134,26,105,140,61,85,141],radioact:47,deploy:[1,14,21],lockfinish:[75,70],discov:[57,91,71,14,104,72,61,77,113,26,24,41,32,28,45],awl:[34,90,29,11,72,101,113,41,33,141,62],runfinalizersonexit:135,deploi:[1,74,73,123,114],mps_debug_class:77,unbusi:107,inde:[96,55,84,54,8,85],snapshot:[101,105,99],constrain:[48,35,69,24,30,77,39,66,80],icfp:47,vmtractofaddr:12,verbos:21,minski:[47,25],grate:139,anywai:[35,128,70,52,41,54,28,56],segbas:[30,39],hadn:74,forev:130,obj_:61,poolmark:116,obj1:54,protstruct:85,mps_block_siz:19,joint:47,lockinit:[75,70],tbl:[128,41],messagecollectionstatslivesizemethod:32,allocfram:7,extract:36,enabl:[0,117,7,49,11,80,52,61,135,105,41,32,21,54,85,130],underscan:[43,26,127],mpscam:43,perl5:3,base2:103,contain:[125,88,89,91,92,29,106,30,2,99,134,101,103,104,27,4,107,108,32,65,6,109,54,67,68,35,93,59,36,112,8,39,115,9,40,11,43,44,96,45,74,46,120,50,75,13,41,123,15,16,52,77,128,79,53,37,20,21,55,126,138,116,57,58,7,66,24,70,61,60,135,26,118,113,84,105,141,28,85,62],grab:[138,28],legaci:[65,6,76],mps_add_fencepost:77,statu:[46,132,24,134,11,80],correctli:[128,75,93,116,99,107,84,69,54,125,56],limit2:103,tend:[92,29,16,101,84,85],lua:25,state:[0,119,90,91,93,30,99,82,27,106,107,108,66,67,35,69,7,70,8,72,39,40,116,12,96,45,74,120,75,49,52,77,18,79,20,54,55,56,57,23,24,25,61,78,84,105,140,37,86],luc:47,neither:[74,119,120,57,24,90,101,39,10,107,108,118,130],tent:77,kei:[87,50,11,16,113,25,101,77,103,90,3,114,40,41,65,44,128],parseabl:50,mps_ap_destroi:[125,61],attrpm_no_writ:66,bucket_:[128,41],tracesetismemb:8,jersei:25,pthreadextcheck:52,awlfinish:141,unimpl:[66,130],quit:[63,88,91,93,95,101,104,65,21,69,9,74,46,120,130,77,20,80,24,25,61,85,62],slowli:21,addition:[46,29,96,50,79,103,131,107,54,45],willi:47,poolnoalloc:141,treat:[35,90,11,41,130,89,135,128,116,108,12,28,118],otb:20,forestal:108,colnet:47,tracefix:[8,116,21,23],replic:[102,96,106,47,108],harder:[24,133,99,25,108],glossari:[87,88,89,90,91,92,93,94,95,96,97,98,99,31,101,102,82,104,105,106,107,108,110,34,83,72,46,16,100,22,139],mps_chat:0,revis:[91,12,47,41],"2fe338":80,scienc:[16,47],parti:[24,85],began:21,anachronist:[35,99],mps_reserve_block:[125,79],http:[68,70,40,20,6,85],event_poolinit:21,fmt_ah:55,tracecr:[130,12],undiscard:130,effect:[0,88,91,92,29,30,99,103,107,32,54,67,35,69,93,71,80,9,72,115,39,12,96,45,74,46,120,47,50,77,18,19,124,21,56,57,79,24,131,133,125,26,61,85,128],sooner:[46,26,45,40],mps_message_queue_typ:[0,32,96,41],ringappend:27,mordechai:47,swizzl:47,seginit:30,well:[0,88,92,29,128,30,97,79,102,103,64,32,6,21,67,69,71,9,114,39,41,43,96,46,75,11,16,77,78,19,54,55,56,57,66,24,133,25,125,112,84,105,141,62],action_find_set_bit:29,mpseventcnv:[6,80,21],undefin:[46,69,29,49,8,52,79,103,104,107,135,56],sibl:103,distanc:[24,55],mistaken:[125,41,11],distant:[46,26],increasingli:[131,141],hess:47,brainpow:40,seghi:30,bits_act:29,clinger:47,poolclassstruct:[66,116],dbe93:57,hpl:47,burden:[74,24,87],loss:[59,29,130,84,20,80],lost:[111,25,77,103,20,125],roth:47,necessari:[125,88,91,99,100,103,104,21,116,66,69,7,70,8,80,9,41,42,45,46,11,15,130,51,52,77,128,79,37,54,81,56,57,24,36,135,118,84,140,61,85,141],martin:[139,47],async:[56,67,52,53],page:[90,91,92,29,96,97,99,100,101,102,82,104,105,106,108,6,35,93,8,72,40,45,46,120,75,47,51,78,21,81,55,56,57,24,25,134,61],string_equalp:41,unit_s:126,home:25,contig:8,peter:47,librari:[1,92,96,79,105,108,5,6,34,69,36,72,40,14,73,46,47,49,50,123,124,21,55,127,129,24,25,26,85,86],win32:[118,81,72,56,70],borland:25,broad:66,overlap:[67,120,49,15,130,39,131,116,45],estim:[88,58,25,40,75,20,12,45,141],overlai:106,mynoteseg:54,encourag:[39,133,96,40],journal:47,usag:[74,50,58,92,36,96,15,72,100,103,21,61,45,126],offset:[69,29,116,78,105,108,124,55],freedom:[74,46,102,25,77],eventdef:[21,80],arenamutatorallocs:141,hysteresi:[57,112,24,8,15,72,134],pointless:[53,126],mps_fmt_b_:55,downgrad:75,splaynodestruct:103,define_alias_class:54,north:47,subsum:67,awltracebegin:141,message_typ:0,xerox:47,gain:[7,71,25,77,84,140,45],spuriou:[67,35],eas:[46,25],highest:[48,29,68,106,138,45],dmb:92,lofix:[28,40],unlock:[54,52,56],mps_type_t:74,asynchron:[0,93,50,16,52,61,104,26,105,107,32,55,45],limit:[0,63,90,91,92,29,94,30,97,114,103,105,106,107,124,65,54,68,35,59,73,112,8,9,72,39,40,11,12,96,45,74,120,14,15,16,51,52,19,141,20,21,55,58,66,24,25,61,125,113,84,139,41,85,123],indefinit:[35,90,91,93,97,99,100,65],vleck:114,evalu:[47,84,99,79,26,19,41,66,125],erik:[0,25],protocolsomeclassstruct:54,eric:47,pthread_onc:52,futur:[63,87,91,92,93,97,79,101,103,116,32,65,21,35,69,7,72,40,49,12,46,120,75,14,50,131,123,66,56,57,58,24,135,54,141],rememb:[87,88,89,91,29,99,101,105,106,67,70,9,40,12,45,46,120,75,47,20,66,57,24,25,134,62],compatlvalu:69,stat:141,neeli:47,stai:[93,11],mrgfree:57,refsig:116,indirectli:[54,46,9,30,101],portion:[68,35,69,29,18,45,108,91,78,141,56,106],tightest:133,decemb:47,pool_class:55,btset:29,secondli:[8,96,80,40,25],whose:[0,88,99,100,102,82,27,2,32,80,67,68,112,37,110,41,44,119,120,11,19,54,55,128,58,79,12,105,25,28,21,135,84,64,139,140,61,62],accur:[46,89,23,97,104,108],mrgcheck:57,swap:[92,94,96,100,102,18,78,105,106,108,45],doubleword:[90,97,83],"void":[0,63,61,29,88,94,79,103,104,27,4,107,2,32,65,109,54,48,35,69,7,70,112,37,80,114,115,128,41,43,119,44,45,74,46,120,13,47,11,123,15,51,52,77,18,19,20,21,55,126,57,58,66,24,49,132,28,125,135,131,118,138,141,140,8,85,106],govern:32,affect:[91,29,101,82,104,105,107,32,69,7,71,115,45,16,77,80,58,24,135,26,138,85],mps_pool_check_fencepost:[77,2],hitch:50,vast:133,agesen:47,extend_s:[138,109,126],shieldflush:15,config_assert_al:85,vector:[120,97,92,29,102,41,77,93,105,84,61,141],initialis:[35,75,70,130,114,137,103,32,12,141],bevan:139,"10g":26,tracescanareatag:68,aggreg:[102,93],mps_key_vmw3_top_down:[44,45],even:[0,63,90,91,29,99,100,101,87,104,105,106,108,80,67,35,69,93,59,112,9,39,40,41,42,117,12,45,46,52,77,78,19,20,21,81,55,57,24,131,82,25,125,135,26,84,141,140,61,123],arena_poll_max:8,neg:[119,128,29,49,80,55,45],asid:19,cheng:47,"new":[0,1,91,92,29,88,95,96,97,99,87,101,103,104,27,106,107,108,32,33,6,54,67,34,35,69,7,70,8,80,9,39,41,117,45,119,46,120,50,47,14,11,130,77,124,128,79,138,20,21,55,116,57,58,23,24,105,132,133,25,125,135,118,84,64,141,61,62],net:[74,25],ever:[46,120,132,8,16,104,40,21,140,28,141],"0000178ea03c332c":80,elimin:[46,91,96,133,25,134,101,103,105,106,40,125],port_ref:41,abov:[125,61,92,29,30,103,64,107,6,109,80,48,35,59,8,9,11,43,44,119,46,16,52,18,19,20,21,55,24,12,78,134,138,28,85,141],mem:[66,134],never:[63,87,92,29,88,96,97,79,102,106,107,21,69,71,8,115,9,41,119,46,75,49,15,130,53,20,66,55,116,128,25,125,112,135,61],met:[101,20,30,59,134],"00000001003fc000":21,abstractli:[32,57,12,52],interpret:[0,119,91,104,64,2,32,21,71,116,45,74,120,41,80,127,128,25,135,26,84,61],algebra:[102,105,93],jame:47,drj:[29,8,107,116,20,66,141],permit:[0,1,91,93,30,102,103,104,108,32,54,35,7,112,8,96,45,46,15,130,52,77,20,80,56,59,133,125,85,141],pack:[92,55,61],mpmconf:129,joshua:47,skippabl:61,sigxfsz:[140,52],call:[0,1,27,6,7,8,9,10,11,12,13,14,15,16,18,19,20,21,23,24,25,26,28,29,30,32,35,37,39,40,41,43,44,45,46,49,50,51,52,54,55,56,57,58,61,63,64,66,67,68,69,70,74,75,77,78,79,81,82,84,85,87,88,90,91,92,93,94,96,108,98,99,101,103,104,105,106,107,2,111,112,113,114,115,116,117,118,119,120,121,124,125,128,130,133,135,131,137,138,140,141],recommend:[40,49,50,16,79,61,19,107,84,140,55,62],awlbufferempti:141,type:[0,2,27,4,7,8,9,10,11,12,13,14,16,19,20,21,25,26,28,29,32,34,35,132,37,39,40,41,43,44,45,46,47,49,50,51,52,54,55,57,58,61,63,64,66,67,69,72,74,77,131,79,80,82,84,85,86,88,89,90,91,92,93,94,96,97,98,99,101,102,103,104,105,106,107,108,109,112,114,115,116,118,119,120,130,123,125,126,128,135,137,138,140,141],tell:[0,1,87,128,36,24,41,130,89,25,67,88,39,85,108,125,120,61,45,106],awlcondemn:141,mps_arch_m4:132,mps_arch_m6:132,warn:[1,68,69,140,72,78,19,84,124,66,81,12,125,85],mps_fmt_fwd_t:[88,55,61],wari:8,btfindshortresrangehigh:29,room:[77,35,58,102],bufferdetachmethod:107,worth:[46,35,57,24,78,105],spong:123,hansen:[139,47],root:[1,87,89,61,91,92,93,96,101,103,104,105,106,108,6,109,66,67,34,7,112,37,9,72,39,40,41,43,12,45,120,75,13,47,68,11,121,113,53,54,126,127,57,58,82,25,28,125,135,118,84,138,86,140,8,62],locusallocdesc:24,defer:[90,91,93,47,15,9,131,106,107,125,110],give:[0,1,91,128,95,30,79,101,103,105,107,65,80,35,132,71,10,40,117,45,74,46,49,15,16,77,78,124,21,57,58,134,112,137,62],mps_ld_reset:[128,41],amsbufferfil:39,unsign:[0,93,30,79,103,21,80,29,132,8,10,41,44,74,120,49,11,19,66,128,61,85],"0x000000010000206b":26,quot:[88,96,79,101,105,61],confin:[66,16],answer:[46,91,61,29,62],config:[74,35,36,50,114,66,85],updat:[87,88,90,91,92,30,99,103,105,106,107,32,21,67,69,9,40,41,96,45,74,46,75,47,14,116,52,51,79,66,55,56,119,24,49,82,28,84,61,85],freeblockbaseofsplaynod:103,gen_param:58,attempt:[63,90,91,29,96,130,103,27,106,107,108,69,93,112,40,116,12,45,46,75,121,15,16,52,77,78,125,55,56,57,24,133,25,105,61,141],third:[47,76,71,24,50,80,9,27,40,41,66,132,12,61,85],maintain:[63,90,91,93,30,97,101,103,104,105,106,107,54,67,70,8,72,39,40,12,96,45,120,15,50,52,19,20,80,126,127,57,24,134,118,139,61,85,141],mps_telemetry_reset:21,decl:[73,28,85],belong:[0,63,91,93,88,30,64,106,107,108,109,7,112,8,115,41,43,45,119,120,13,11,138,19,37,125,55,1,126,128,58,84,105,140,61,62],afip:47,config_var_cool:[14,26,85],fifo:[88,97,93,138],poolcreat:[75,116],copyright:[20,59,76],suceed:103,sigplan:47,better:[88,29,100,103,106,107,6,125,39,40,11,45,119,120,13,50,16,66,55,128,133,84,61,62],rampbegin:20,persist:[119,35,58,47,120,131,19,84,55,45],erlang:16,mps_scan_begin:[120,11,84,79,55,113,40,41,61],mps_reg_scan_t:[120,61],debugmixin:77,promis:[57,91,61],prot_exec:[81,78,56],"0x7fff5fbff7a0":26,xcppgc:132,went:[14,66],oblig:61,side:[24,30,50,103,72,77,39,79,20,125,56],mean:[87,88,92,29,128,94,96,97,134,99,100,101,102,103,104,27,106,107,108,32,65,7,109,54,67,35,69,93,59,112,37,80,39,10,40,11,42,117,45,74,46,120,50,75,13,14,15,130,52,77,124,18,79,138,20,21,55,56,116,57,23,66,24,105,25,61,125,78,135,26,84,64,141,140,41,62],character_:61,enorm:[77,35,139],fromlimit:29,mps_res_limit:[74,14,19],forgot:26,collector:[1,87,89,90,91,92,93,88,94,95,96,97,99,101,82,104,105,106,107,108,6,125,67,35,71,37,72,38,115,9,40,41,45,119,46,120,47,14,15,16,21,55,57,58,24,25,61,135,26,118,28],unbound:[0,106],mps_arena_create_k:[44,61,45],crucial:[9,57,107,41],content:[0,1,90,92,102,106,107,32,65,125,68,35,37,116,45,74,50,130,77,80,55,58,25,26,61,141],rewrit:125,reader:[103,84],mps_arena_create_v:45,quantifi:47,kiem:47,mccarthi:[87,21,96,47,25],traceunflip:12,linear:[48,29,47,97,134,105,40],situat:[63,35,128,75,23,94,24,8,99,9,26,11,55,45],ineffici:[112,133,97,16,9,105,106,108,28],cytron:47,beown:70,rampoutsid:[20,35],ish:77,iso:[69,92,47,36,49,25,79,91,73,123],isn:[46,91,40,24,30,116,77,9,26,131,107,41,20,66,12,85,141],fmt:[69,13,37,2,115,4,11,43,55],hoop:116,hook:[8,120],unlik:[35,91,25,105,40,61,126],massiv:35,brock:47,wherev:66,sometim:[0,88,90,91,92,29,94,99,87,104,105,106,107,108,6,93,9,11,46,77,18,20,57,23,82,25,135],memcmp:[49,66],with_arena_lock:7,bttest:29,mps_build_cc:132,namespac:69,"0x5195bace":3,mutati:103,mps_sac_class_:[105,19],somewhat:[41,105,56,40,108],mps_build_cx:132,peculiar:106,symptom:19,mps_peak_creat:24,silli:29,keyword:[91,98,79,105,4,107,2,65,109,125,34,112,37,76,115,11,43,44,45,119,13,48,20,80,126,138,61,86],matter:[128,92,47,14,30,9,24],modern:[46,93,96,16,25,100,102,9,40,108,61,85],mind:[71,24,9,16,105],mine:[74,47],amcgen0frequ:20,bitfield:66,seed:60,seen:[46,23,70,77,39,105,108,80,85],seem:[46,35,57,75,39,103,77,9,66,61],churn:[60,57],minu:141,mps_peak_destroi:24,fwd2:61,resetrang:29,regular:[0,103,101,135,41,6],myseg:54,fwd_:61,prematur:[87,46,90,96,16,82,108],tradit:70,simplic:[63,57,29,103,84,140,85],don:[1,92,29,30,79,101,106,107,125,67,48,35,69,8,114,39,40,41,44,45,46,15,14,50,52,77,78,20,54,81,56,116,57,23,24,61,135,141,37,85,62],simplif:46,doc:[67,68,69,29,24,39,80],doe:[0,2,27,59,8,9,10,11,12,13,14,15,16,19,20,21,25,26,29,30,121,32,35,37,39,40,41,43,44,45,46,49,50,52,55,56,57,7,61,62,67,68,69,70,71,73,74,75,78,79,80,81,82,84,85,87,88,91,92,94,95,96,97,99,101,103,105,106,107,108,109,112,135,115,116,117,120,130,126,128,133,113,137,138,140,141],buckets_:[61,41],splaynod:103,dot:21,kristen:25,sigsegv:[81,26,140,52,56],visitor:[102,105],esoter:65,arenaallocher:24,syntax:[20,54,91,25,68],base_doc:68,despit:[128,91,92,16,25,105,106,41,54,56],acquir:[112,14,30,45,138],field2:69,explain:[7,14,50,16,103,61,39,3,40,11,54,134,44,28,85],field1:69,arpa:74,splaynodecheck:103,hoard:47,stoy:[94,47],stop:[74,46,75,47,2,24,15,130,52,99,9,105,41,32,20,45],compli:82,h30097:68,softli:[25,101,77,105,106,108],bar:[105,27,85],headerlength:35,baz:[27,85],bag:[20,92],bad:[46,35,92,24,104,25,77,103,26,99,41,65,125,133],ban:20,mps_arena_has_addr:45,rightchild:103,datatyp:70,subtre:103,tractofbaseaddr:8,subject:[0,120,49,80,101,77,135,105,107,41,32,6,55,45,126],said:[67,87,95,96,77,82,104,106,108,21],invalu:114,simplest:[125,48,75,30,103,39,104,6,61],sos8cx:132,btfindlonghigh:29,obj_chain:[61,41],lazi:[99,121,47,29],"0x00000001003f9b40":26,flexowrit:21,notreach:20,against:[74,46,128,71,8,84,103,123,108,80,96],loader:45,exemplari:[20,59],shortcut:35,nocopi:12,liabil:[20,59],ullages:20,three:[0,88,91,96,99,101,102,103,27,106,108,5,6,109,80,67,35,36,71,8,9,39,10,41,43,45,46,14,50,16,77,128,79,20,21,55,57,24,132,133,82,25,125,112,26,84,105,61,85,141],specul:[29,25],sac:19,trigger:[102,35,50,108],interest:[0,106,32,6,67,68,7,72,40,12,45,46,14,78,124,21,81,55,57,24,25,28,113,136,84,61,62],basic:[92,30,104,105,106,107,108,65,67,35,8,72,41,45,46,16,77,18,53,54,56,24,25,138,61,85],suppress:[79,85],tractreturn:8,"0x0000000100001ef7":26,efficaci:12,exception:24,unretriev:130,gcsegclass:[35,57,28,141],servic:[67,46,69,59,129,24,96,16,51,134,104,105,19,118,20,81,133,56],mps_rm_const:[120,91],calcul:[35,57,133,50,130,72,101,66,55,141],neat:20,anchor:47,spawn:25,seven:[74,138,35],digital96:68,sigpoolawl:141,mexico:47,allen:47,symtab_s:[120,61],"1003fd328":21,disappear:[135,35,106,79],grown:[81,57,25],pthread_t:52,rankbuf:107,receiv:[74,10,120,57,91,59,46,94,80,133,16,52,72,61,103,26,107,32,21,135,55],make:[0,1,6,59,39,12,14,15,16,18,20,21,24,25,26,29,30,35,132,37,9,40,41,45,46,49,50,52,54,55,56,57,58,7,60,61,62,63,64,65,66,67,69,70,71,72,73,74,76,77,78,79,81,84,85,86,87,88,89,90,92,93,96,97,99,102,103,104,105,106,108,112,114,118,119,120,130,123,125,127,36,133,134,113,140,141],elli:[67,47,25],mps_headers:55,mps_io_o:74,kit:[34,6,127,59],kim:47,kib:134,mps_io_t:[74,49],studi:[77,16,56,47],canstep:51,inherit:[34,93,24,72,78,25,53,54],qualit:74,poolmrg:[32,42,57,121],weakli:[11,25,101,105,106,108],endif:85,programm:[0,46,35,93,68,94,24,96,50,16,135,25,88,112,87,122,105,99,54,132],isomorph:104,left:[91,29,30,108,79,103,4,2,21,35,8,41,96,45,74,14,130,52,66,133,25,84,28],identifi:[29,97,98,99,102,105,32,21,69,36,8,44,118,75,50,79,80,55,57,134,84,54,61,85,86],just:[0,88,91,92,29,30,101,103,105,107,2,32,65,6,21,67,48,35,69,93,73,71,80,113,114,39,40,41,12,45,74,46,120,130,50,121,77,53,20,54,81,55,57,66,24,25,134,135,26,84,141,140,61,85,62],sigusr1:[140,52],bandwidth:[96,106],human:[36,50,32,5,21,80],nowadai:[101,105],yet:[0,87,130,80,67,35,9,40,11,12,15,14,50,121,77,20,66,57,58,24,25,125,135,26,54,61,141],languag:[1,87,90,91,92,93,88,94,96,97,99,102,82,104,105,106,108,125,34,69,59,113,38,9,40,46,47,68,49,16,79,54,127,57,25,135,61,85,86],character:[101,46,47,25],save:[87,68,89,57,91,47,7,14,25,39,105,84,118],change_s:24,opt:6,applic:[1,88,93,96,102,87,105,108,32,6,112,38,49,45,74,46,47,14,16,52,24,133,25,135,26,84,62],background:[74,29,70,8,82,72,103,123,45],"0x1003f99d8":26,rusage_self:49,manual:[0,1,90,93,88,95,96,2,100,87,64,107,108,33,109,67,34,112,38,115,9,40,11,65,119,46,120,48,130,116,16,77,122,19,138,125,126,57,25,84,105,86,61,85,62],toaddr:74,unnecessari:[87,46,35,40,41],www:[20,6,40],mps_arch_s8:132,deal:[46,35,128,102,66,89,25,101,94,105,108,54,43,85],interv:[0,88,29,51,41,125,61,45],mps_arch_s9:132,maxim:[67,112,54],dead:[87,88,90,91,93,94,95,96,97,99,82,64,106,107,67,35,7,71,37,114,115,40,116,131,125,57,58,26,61],mmqa_test_funct:29,intern:[125,88,89,92,29,121,130,99,103,105,107,108,32,65,6,66,69,7,8,80,72,39,40,41,45,74,46,75,47,76,14,123,16,77,19,21,126,57,119,24,49,133,26,141,28,85,62],interf:78,make_pair:61,insensit:25,trace:[87,90,91,92,93,30,97,99,101,104,105,106,66,67,35,8,80,9,72,38,39,40,41,12,96,45,120,50,47,130,15,121,18,53,20,21,55,116,57,58,23,24,61,26,84,28,141],messagetypefin:[32,57],friedman:[94,47],inrampmod:20,idiomat:27,bold:46,promot:[87,35,58,93,95,37,104,123,108,54],"0x7fff5fbff808":26,"super":[77,54],unsaf:[105,135,75,52,45],mps_peak_clos:24,simul:[48,117,47,25,102],felleisen:47,frame_o:[64,7],commit:[125,120,75,14,8,96,72,61,18,105,19,107,116,91,66,28,45,141],framereturn:7,buffertrip:[75,107],down:[0,88,29,30,114,103,104,105,106,107,6,67,68,35,132,8,72,10,40,49,12,45,74,46,14,77,19,20,55,24,25,26,61],seglo:30,formerli:[132,91,41],lieu:67,"9c1e0":80,editor:[139,25],fraction:138,analysi:[0,29,94,106,21,67,69,93,37,72,39,12,74,120,75,47,52,53,80,55,56,57,24,61,85,141],form:[0,87,90,91,29,88,94,95,96,97,99,100,101,103,104,3,106,107,108,80,35,69,59,114,10,11,12,50,14,15,16,79,138,20,21,116,57,44,133,25,134,26,105,140,61,85],forc:[46,25,84,32,21,61],substrat:18,refpartstruct:57,sigcontext:52,tucson:47,seggrei:39,unrel:26,mpscsnc:115,featur:[0,90,93,79,103,104,105,106,2,125,34,8,72,39,41,45,120,11,16,77,78,37,21,25,61,85],semicolon:20,classic:[46,24,100,9,105,6],"__line__":77,diagnost:[34,35,50,130,72,6,85],glanc:39,sticki:[97,105,47],excel:103,accessread:[66,15,51],fmt_scan:120,unlimit:[46,10],matur:[14,37,47],journei:61,has_reservoir_permit:19,subdivid:30,felt:46,stringid:21,losegstruct:28,mps_build_ac:132,russo:47,my_malloc:46,furthermor:[14,120,40,77],pseudo:[60,69,40,107],ignor:[74,35,91,131,39,99,120,9,10,106,40,32,65],skip:[125,88,35,61,13,29,37,15,127,55,115,39,26,105,4,40,11,41,43,28,141],mrgrefseg:57,invent:[87,9,92,25],"0x0000000100005ff5":26,"0x0000000100003ea6":26,milo:47,pldi:47,hierarch:[50,47],depend:[87,88,90,91,29,97,79,101,102,103,64,106,107,108,33,109,54,34,35,93,73,112,8,80,72,115,39,10,40,11,43,12,45,74,46,120,141,13,14,41,117,77,123,138,21,114,126,127,128,58,66,24,132,133,82,25,61,113,118,84,105,86,140,37,85,62],cornel:47,intermedi:[112,40],w3ppmv:132,memorymanag:40,aspx:85,string:[125,99,102,104,4,21,36,40,41,44,46,47,49,50,52,123,80,58,25,28,26,61,85],asymptot:107,special_:61,format_return:77,did:[46,23,25,41,65,61,45],die:[87,58,93,37,99,26,106,40,41,141],dig:80,iter:[57,29,76,8,52,25,39,27,72,40,103,61,141],magnet:92,item:[123,8,105,103,36],mps_ap_creat:[13,112,37,115,107,11,138,43,125],dip:77,round:[35,57,69,92,129,14,133,16,78,105,19,41,138,125,61,45,141],dir:85,segmerg:[30,39],alignshift:[28,141],minimis:[80,85],addr:[63,30,103,21,107,54,35,69,7,8,80,39,41,44,45,119,11,121,51,77,123,37,20,66,55,128,125,26,61,141],"0x00000001003f9730":26,wors:[88,35,133],suspect:[26,107],sizelog2:[28,141],deriv:[90,69,92,66,49,8,99,94,9,104,27,79,137,91,54,12,28],guardian:[32,54,57,121,47],type_link:125,integer_:61,awlsegstruct:141,coincid:[77,35,28,134],wait:[0,1,75,8,130,52,45,41,56],epdldebugpoolclass:54,bop:27,shift:[29,134,40,66,28,85,141],steffen:47,amcrampbegin:35,extrem:[35,57,130,104,114,18,105,40,85],bob:47,mps_rank_t:[120,115,106,11,66,44],refsetuniv:[67,23,141],grunwald:[97,47],modul:[63,87,29,30,99,103,108,32,65,67,34,59,36,8,76,72,117,118,74,46,75,68,49,16,51,52,124,18,20,54,81,56,57,70,25,134,78,85,86],transplant:103,perf:[80,75],univers:[67,27,47],visit:[87,120,92,37,26,6,55,45],perl:[87,16,3,25,88],diwan:47,mps_key_args_end:[65,44],idempot:[21,57],mps_pool_class_t:119,appel:[67,92,99,47,108],olivi:47,oop:[26,47],examin:[67,68,57,92,29,24,80,51,61,9,90,105,56,40,95,54,141,12,28,45,128],mps_pool_check_free_spac:2,effort:[74,57,14,96,108,99,39,85,24,45],fly:47,uniqu:[67,57,75,92,47,50,21,66,85,141],imper:25,pthreadext_sigsuspend:52,lau_1999:52,cisc:97,"_any_":107,nearest:[24,103,105],predict:[46,112,57,58,93,29,71,24,91,97,16,94,18,105,40,138,65,125,109,45],winston:47,agent:67,mps_alloc_frame_class_stack:7,noaver:12,oslo:[0,25],foreach:3,pure:[1,87,90,41],map:[88,91,92,29,94,30,97,102,103,3,106,108,34,35,69,93,8,72,39,41,73,96,45,46,49,15,52,77,18,124,81,56,24,82,134,78,105,85,141],snc:[33,62,64,115,34],max:[74,8],usabl:[69,45],repr:53,intrus:[35,47],membership:8,mad:47,mai:[0,2,3,4,6,7,8,9,11,12,13,14,16,18,19,20,21,23,24,25,26,30,32,35,37,39,40,41,43,45,46,47,49,50,51,52,54,55,56,57,58,61,62,1,64,66,69,70,73,74,75,131,79,80,81,82,84,85,87,88,89,90,91,92,93,94,96,97,99,101,102,103,104,105,106,107,108,109,112,113,114,115,116,118,119,120,130,123,125,126,128,133,134,135,138,140,141],underscor:[65,79],grow:[0,46,35,57,58,68,112,24,96,105],man:[96,78,69,29],findshortresetrang:29,mpsio:[74,49,21],"switch":[74,35,76,24,84,80,25,61,40,41,20,6,43],eventkindenum:80,deposit:63,talk:[74,77,35,39],shield:[34,30,15,72,57],schwartz:[101,104,47],cutt:47,lsp:[35,72],eventrep:[107,116],yarsun:47,equip:[68,47],pointer:[0,88,89,90,91,92,29,128,94,95,96,2,130,99,100,101,103,93,27,106,107,108,134,80,67,68,35,69,47,7,115,8,9,114,104,39,10,40,11,43,119,12,45,74,46,120,75,13,41,49,123,15,16,77,117,18,19,53,66,55,126,116,57,58,79,129,24,132,133,82,25,61,125,135,26,118,113,84,105,141,140,37,62],rovner:47,interspers:103,group:[35,23,7,24,52,25,20,80,139],thank:139,polici:[1,88,90,91,92,29,97,99,101,87,104,105,108,32,48,35,93,7,112,8,40,119,47,19,54,79,24,133,134,138,61,86],mail:[57,69,29,24,52,77,136,3,107,54,12,80,141],main:[90,91,92,96,79,102,103,104,105,106,108,65,35,69,72,9,46,120,47,130,20,54,24,133,26,61,85],recoveri:[80,47],free_templ:2,traceaccess:23,initi:[63,88,91,29,30,97,101,103,104,27,114,107,32,66,35,125,70,71,8,80,72,39,40,41,12,45,74,46,120,15,75,50,130,51,52,78,19,54,116,57,24,134,60,105,61,141],tucker:[24,139,47,107],sigloseg:28,workload:47,"9c0d8":80,thvv_1995:114,massachusett:47,median:80,continu:[1,91,93,97,99,101,104,106,29,9,10,41,117,45,46,16,51,20,80,57,133,25,84,61,141],lookasid:[102,104,93],mps_key_rank:[115,41,44,11],redistribut:[20,59],poolreadi:8,fopen:49,jackson:[139,47],"0x7fff5fbff174":26,mps_arch_i4:132,mps_arch_i6:132,correct:[1,91,96,103,104,64,107,125,35,69,70,8,9,72,39,41,43,14,11,20,54,55,23,132,135,84],mps_arch_i3:[69,85,132],poolsetframeclassmethod:7,bufferattachmethod:107,"goto":[20,54,69,40,29],ams_index_addr:39,mps_key_mvt_frag_limit:[112,44],california:47,org:[6,40,25],badli:[24,16,101,104,11,133],frequenc:[9,80,19],mps_size_t:[138,109,126],thing:[106,54,35,69,112,8,39,10,40,12,45,46,75,47,121,50,16,77,18,19,20,66,128,23,24,28,135,137,61,85],principl:[67,65,69,85,47],think:[125,120,24,39,25,77,9,78,19,114,20,21,66,141],frequent:[87,34,61,75,46,37,25,38,9,26,40,108,55,45],first:[0,87,91,92,29,88,95,30,97,99,101,103,93,27,107,2,32,33,6,109,54,34,35,44,69,47,132,71,8,80,39,114,38,9,40,11,42,12,96,45,119,50,75,41,48,15,121,51,52,128,19,138,20,21,55,126,57,58,24,133,25,61,125,112,26,134,105,141,140,28,85,62],carri:[128,108,93,84,135,116,107,41],question:[1,34,91,7,59,46,14,25,38,77,136,6,61,45,62],housekeep:103,acquisit:135,"long":[0,1,29,79,87,101,103,105,106,107,108,125,67,35,69,93,132,112,37,9,39,40,41,44,45,46,15,75,13,47,49,50,121,19,20,66,56,128,58,24,26,84,61,85,141],rebal:103,oppos:[46,90,91,48,99,66],mmref:40,lar:[139,47],mps_mv_size:109,memo:47,blacklist:[24,92],were:[125,88,90,91,29,30,97,101,103,104,3,4,107,32,21,68,35,69,132,71,8,39,41,12,118,46,120,77,128,19,54,81,55,57,58,23,25,61,64,140,37,141],mps_io_type_t:74,dash:[20,41],"1992a":105,"1992c":[94,104],"20g":26,awlsegreturn:141,advic:[127,26,19,45],messagecollectionstatsnotcondemnedsizemethod:32,advis:[20,85,59,138],interior:[90,91,92,111,99,39,84],channel:[81,50,72,56],c90:91,pain:[46,40],norman:[94,47],job001809:35,normal:[0,89,91,79,103,21,106,107,108,80,48,35,7,70,112,9,10,40,11,45,50,15,77,20,66,128,24,125,135,54,105,41,85,141],track:[67,46,57,91,88,14,39,25,77,9,26,105,99,24,103,141,12,61,106],c99:[65,91],tract:[63,24,8,72,134,40,12,30],pair:[57,92,29,132,130,15,90,103,26,107,41,6,84,61],awlstatsegstruct:141,dylan_skip:12,synonym:[91,92,29,25,105,108],gracefulli:[94,12],show:[74,46,71,8,50,130,52,9,26,107,41,20,21,12,54,85],mps_mvff_free_siz:[48,138],threshold:[8,35],fenc:[77,88],behind:[67,91,124,4,41,69,21],black:[67,87,35,91,92,94,30,72,101,39,104,105,99,116,55],moreau:47,nearli:[35,23,24,96,99,114,40,125,61],variou:[29,96,32,6,80,34,36,114,38,39,40,12,118,74,46,120,50,130,77,18,66,81,56,57,24,25,84,61,85],get:[0,61,91,29,95,130,102,27,114,107,108,32,65,6,134,125,67,35,73,71,37,72,39,40,11,12,45,46,50,14,15,121,77,78,19,138,54,127,57,58,23,24,133,28,26,118,84,137,105,41,85,141],mung:85,splaytestnodemethod:103,secondari:[85,47],eventmaxstringlength:80,gen:[35,69,85,141],protan:30,yield:[138,30,80,108],tillotson:139,summari:[67,23,8,52,72,40,116,80,12,30,56,141],kernel:[78,18,15,106,124],ams_alloc:14,vmdestroi:[129,18],lasttractbas:8,markschang:39,spars:[89,93,99,18,25,108,106],symtab_root:[61,41],eagain:78,infinit:[24,96,134],checkl:[20,10],"0x1003cb958":26,mps_sac_flush:19,checkd:[10,114],updatenod:103,enumer:[105,66,69],label:[69,79,104,20,21,86],palimpsest:108,enough:[88,92,29,97,103,107,78,21,48,35,93,112,39,49,45,46,14,16,18,19,66,55,23,24,133,60,26,61,141],checku:[10,114],across:[74,48,91,68,99,118,138,6,85],fcntl:74,august:[52,47],parent:[7,95,99,103,10,64,27,54,66,141],audienc:21,saguaro:91,improv:[90,29,97,102,112,27,106,6,35,11,37,9,72,39,14,43,12,74,46,50,13,47,49,15,77,78,81,56,57,58,24,133,25,71,136,138,28,85,141],among:[46,30,25,77],undocu:[140,51],nodereturn:103,ultim:[8,52],marc:47,bufferranksetmethod:107,btrangessam:29,mark:[87,88,91,92,29,95,96,97,99,101,82,104,105,116,108,33,67,34,35,69,9,114,39,40,41,42,43,47,14,15,141,21,58,2,25,139,28,62],workshop:[47,132],"000ae0397334e0a0":21,wake:52,repres:[125,88,89,91,92,29,30,97,79,100,102,103,104,3,106,108,32,21,35,93,7,8,80,39,41,44,118,46,120,47,51,52,77,53,66,55,128,24,82,134,135,84,105,61],those:[88,90,91,92,29,95,30,97,99,103,104,105,106,107,108,65,125,67,69,70,8,10,40,49,73,45,74,46,75,14,116,130,52,77,18,21,133,134,113,78,118,61],sound:[16,3,29],interoper:[39,69],mps_align_t:[93,79,138,66,44,55],"_next_":107,antoni:47,wasmark:[42,141],invok:[46,135,91,7,29,30,80,52,55,77,103,10,93,84,21,12,54,56],"na\u00efv":[135,41],invoc:[91,93,50,79,105,54],advantag:[46,92,7,70,112,133,16,99,77,105,106,41],destin:[74,49,128,23,45],cluster:29,unwritten:[67,69],sos8gp:132,stepper:[120,14,37,102,105,55],same:[125,88,89,61,91,92,29,128,30,97,79,101,102,103,90,27,106,107,108,32,54,67,48,35,69,93,7,70,112,37,80,113,114,115,39,40,11,42,43,96,45,46,120,75,47,14,15,130,52,77,124,18,19,138,20,21,55,64,126,57,58,66,24,49,132,82,28,135,131,84,3,141,41,85,62],pad:[88,91,94,95,108,99,3,4,2,35,37,72,115,11,43,13,41,15,127,77,80,55,116,26,61,141],sos8gc:132,circularli:105,pai:[46,35,40],exhaust:[112,130,103,12,55],assist:[105,21,26,104,99],capabl:[58,25,105,106,125,21],postpon:[61,41],appropri:[90,91,92,29,30,99,103,105,106,107,108,134,80,67,48,35,93,36,112,39,10,41,117,96,45,120,50,52,54,55,116,57,24,133,28,135,118,61,62],"0x1003faf30":26,macro:[125,29,95,79,27,114,107,65,80,69,36,8,72,39,10,40,44,76,50,77,19,20,66,132,84,54,61,85,86],pagetablepag:20,roughli:40,eq_hash:[128,41],leewai:84,execut:[1,89,90,91,92,29,96,2,104,27,116,108,93,59,70,71,72,40,11,75,49,50,51,18,20,54,57,36,25,140],aspect:[69,36,71,132,16,39,105,124,91,12,45],autocad:87,"000ae03973361d5a":21,param:[48,80,85],"0x1003cbe50":26,doctorat:47,pitman:139,pagestruct:134,diag_with_:50,"8kib":40,mop:77,mov:11,vivek:47,sobalvarro:[91,47,25],mod:85,server:[96,47,25],bufferisreadi:107,either:[1,119,91,92,29,30,97,130,99,101,103,105,106,107,32,6,67,35,44,59,70,112,8,9,39,41,42,12,96,45,74,46,120,75,11,15,16,52,77,18,19,20,66,55,57,7,79,24,133,25,61,135,121,118,141,28,85,128],larchant:47,dylanwork:28,vmalloc:47,fulfil:[24,8],thermodynam:47,ascend:20,adequ:[24,57,45],arenaalign:[35,57,141],poolmv2:103,recomput:[24,12,72,45],pioneer:25,lii3eg:132,event_typ:21,broken:[88,35,57,91,92,103,105,106,116,42],ansic:129,referr:99,arena_class_vm:45,fencealloc:77,lvalue2:69,zonegroup:24,lvalue1:69,feldt:139,terminolog:[57,96,72,101,128,105,108,54,86],whiten:[24,116],amcfixemerg:35,bobrow:[90,47,25],complianc:141,mps_class_snc:[115,44],overwrit:[88,57,92,29,46,94,96,90,114,77,82,26,105,93,2,125,141],"00000001003fd328":21,gavinm:[24,66,57,80],"0x51970b07":28,amcscannailedonc:26,possibl:[1,87,89,90,92,29,128,30,97,99,103,3,106,107,32,7,134,66,67,68,35,69,93,59,70,112,80,9,72,39,10,40,11,12,96,45,74,46,120,50,75,14,123,41,130,52,77,18,19,20,54,55,56,116,57,23,24,105,111,25,61,125,26,84,27,141,28,85,62],poolalloc:[48,75,134,39,116,66],unusu:[74,96,78,45,25],rampcollect:20,manuel:47,embed:[47,36,24,84,52,25,137,103,99,49,32,61],deadlock:[75,70,8,97,52,135],powerless:1,cactu:[105,91],conundrum:61,deep:10,deem:[24,130,45],s7ppmw:132,file:[88,96,79,100,3,106,124,5,6,21,69,59,36,9,40,41,73,45,74,46,76,49,130,78,20,80,25,135,26,105,61,85],proport:[87,46,58,71,96,100,9,40,84,61],eliot:[139,47],fill:[63,29,96,97,3,107,108,125,48,35,8,39,116,120,75,49,130,77,66,55,57,24,61,138,28,141],again:[87,88,92,29,96,103,107,108,125,67,48,9,41,74,49,16,52,77,54,81,56,128,24,135,61],"0x1003f9ba8":26,hybrid:[87,96,93],field:[63,88,89,61,91,92,29,94,30,97,99,103,104,27,106,107,108,32,134,66,67,35,69,7,8,80,114,10,11,42,117,44,50,75,130,15,16,51,52,77,53,20,54,55,56,116,57,23,25,28,125,105,41,85,141],"0x00000001003fb000":26,reservoirsetlimit:63,coerceclass:54,architectur:[63,91,92,93,97,99,100,101,82,104,105,106,83,108,6,80,67,68,69,36,112,8,72,39,11,42,12,118,74,120,75,47,121,77,18,21,24,132,134,125,137,138,61,85],tmessag:130,sequenc:[120,91,29,133,66,24,8,2,80,104,26,27,107,84,64,54,12,55],lueh:47,ansi:[1,46,91,92,34,129,14,30,70,80,72,117,79,49,6,21,85,123],"0x1003f9b48":26,readership:[29,103,3,107,124,32,80,68,35,7,36,8,72,39,10,117,73,74,15,130,51,52,77,20,54,81,56,57,24,60,28,141],freetreeinsert:103,descript:[0,29,99,103,27,106,107,108,80,48,72,116,73,120,76,14,20,66,55,128,24,25,12,125,21,84,105,140,61,141],unseg:105,mps_check:69,represent:[87,88,29,95,96,99,101,102,103,104,105,106,69,7,8,39,40,45,47,123,128,82],forget:[45,41],mps_key_:[65,44],forbidden:[24,81,51,56],dollar:123,suno:[34,132,72,78,6,81],freeblocklimitofsplaynod:103,ruinou:71,children:[87,95,103,104,7],mvvararg:65,"10992f000":21,attrbuf:66,straightforward:[85,28,107,41],fals:[0,29,79,103,107,32,80,48,7,8,39,42,45,119,19,66,55,128,125,84,54,138,61,141],mps_shift_t:66,util:[7,50,25,32,21,86],fall:[87,128,75,47,112,14,39,25,9,19,107,20,66,80,106],indepd:65,stderr:[46,26,84,61,49],kemeni:25,mvff:[48,126,34,96,72,138,2,33,109,62],addrset:66,mrgdescrib:57,zero:[0,90,2,93,106,95,30,97,101,4,107,108,33,66,34,35,69,11,80,9,110,39,40,41,44,74,46,120,13,14,123,15,78,19,21,116,65,24,49,25,84,141,61,62],further:[0,46,35,57,91,8,52,82,55,120,9,128,40,84,32,21,125,30,45,141],mps_chain_creat:[58,61],stood:46,diag:[50,130,85,72],abl:[88,91,29,30,99,103,106,35,69,36,9,117,45,74,120,130,15,16,52,77,18,80,55,57,70,82,25,26,140,61,62],regnesentr:47,mps_build_mw:132,mps_build_mv:[85,132],"public":[87,88,89,90,91,92,93,94,95,96,97,99,101,102,82,104,105,106,108,6,46,14,79,125,25],amcrampend:35,variat:[133,9,105,96,106],sophist:[57,112,24,39,9,12,85],arena_o:45,simon:47,threadr:[52,118],dequ:[27,76],mult:54,search:[88,35,47,29,24,133,39,103,52,9,138,105,114,107,95,20,21,141,92],fwd:[61,55,41],emptymutators:107,pauillac:70,declin:[32,131],primit:[46,91,99,9,25,80,56],transit:[67,35,12,7],readili:[49,9],inappropri:9,demonstr:21,establish:[15,57],"0x1003cb970":26,distinct:[88,92,36,94,132,16,99,102,103,105,40],liber:140,regist:[1,88,91,93,96,97,99,101,104,21,106,32,109,80,68,125,112,37,113,115,40,11,43,45,120,13,41,15,121,52,138,66,126,116,57,25,60,135,118,84,105,86,140,61,85,62],two:[0,88,89,90,91,92,29,128,73,30,2,130,99,101,102,103,93,27,4,107,108,32,6,134,66,67,35,69,47,7,36,8,80,39,104,9,11,43,12,96,45,74,46,120,75,41,14,15,16,52,77,18,19,53,138,20,21,116,57,58,23,79,24,49,70,133,25,61,125,26,131,84,105,37,85,106],desir:[63,46,75,92,24,77,105,65,12],brisl:[29,36],mps_sac_creat:[105,19],particular:[0,87,91,29,88,94,96,97,99,103,104,105,106,107,108,32,80,68,35,69,93,59,70,112,8,9,40,41,12,45,74,46,116,77,18,79,141,20,21,81,55,56,57,7,24,131,25,134,125,122,84,139,37,85,128],ultrasparc:99,dictat:[24,50],none:[67,57,29,14,8,11,103,55,125,39,128,24,21,44,54,45,62],hour:114,dep:85,dev:[6,78,106],remain:[125,88,91,30,101,104,105,107,108,80,67,35,9,41,73,45,13,116,130,66,126,24,133,21,135,61,85,141],sudden:80,den:[101,46,104,47],abandon:[20,99],dec:107,dee:90,def:[68,35,57,53,29,24,8,7,114,30,137,103,18,27,107,32,78,66,28,85,141],stubborn:26,tv_usec:49,pthread:[52,56,70],emiss:80,minimum:[88,35,57,91,29,112,77,103,106,40,108,138,85],explor:24,sharp:131,strlen:41,csl:47,awkward:11,secur:[96,25,108],programmat:[5,130],csd:47,comfort:71,rapport:47,narrowli:87,needn:12,blacken:39,config_var:85,"2fe1b0":80,associ:[0,63,93,96,98,99,101,103,104,107,125,35,70,8,41,30,46,75,116,128,19,21,57,24,82,25,135,28,85,141],fri4gc:132,wobbl:20,mpseventtxt:21,mislead:[24,35],bufferdestroi:[75,107,116],mortem:80,infant:[87,99,47],rotat:[95,103],mps_scan_:69,mps_lib_memset:[49,66],through:[89,29,99,101,107,21,67,34,35,69,8,80,40,116,42,73,45,74,76,77,18,19,20,66,57,12,25,135,54,61,85],coerceinst:54,diag_firstf:50,make_bucket:41,late:[119,96,130,41],pend:[32,116],good:[1,87,92,29,97,103,3,107,125,67,69,59,71,72,39,40,12,45,120,49,50,130,20,21,57,24,133,135,137,105,61,141],mps_ap_t:[93,7,11,115,131,64,107,41,125,61],segclassmixinnosplitmerg:30,timestamp:[21,80],pollut:[67,12],entry_interpret:26,inria:[47,70],port_:[61,41],compound:[46,91],detach:[35,57,107,116],complain:77,job001658:12,mysteri:[46,90,25],easili:[1,57,69,93,59,97,52,25,77,9,128,66],token:20,type_pad:[26,61],clamp:[8,91,82,45,108],interleav:[1,88,91,96,4,107],"0x0000000100074106":26,hard:[67,46,35,92,105,96,15,16,120,114,9,26,3,106,20,125,61],idea:[67,69,105,24,91,15,80,25,134,77,135,18,3,72,41,75,20,21,12,54],connect:[74,87,89,91,94,49,37,16,135,9,27,106,73],orient:[67,74,47,88,94,96,25,103,54],diag_stream:50,nrevers:47,leftneighbour:103,perri:47,print:[0,57,66,14,50,80,135,25,103,26,116,41,21,61,45],difficulti:[0,74,108],mmu:[102,96,108],fillsiz:107,calder:47,mps_:[69,79],workstat:[99,25],mpsc:79,mpsa:79,omit:[10,26],mpsi:[14,26,69,107],mymp:6,perman:[106,99],hasseg:8,dont:26,exchang:[136,56],symbol_t:125,adesc:24,done:[0,87,91,92,96,103,27,107,108,32,6,67,35,69,114,39,41,12,45,74,46,75,49,121,77,124,21,81,56,128,58,24,25,26,105,61,141],stabl:[112,24,50,130,47],obligatori:[54,7],"5th":47,construct:[46,90,91,29,24,50,16,61,54,44,55,85],paint:99,statement:[69,76,79,27,20,80,12,125,85],twenti:91,unalign:[120,92,93,96,82,39,116,138,125],parc:47,mpseventsql:[127,6,21],para:20,park:[119,120,91,8,82,108,37,45],pari:47,part:[87,88,90,91,92,29,96,97,130,79,101,102,103,104,105,106,107,108,32,66,67,35,69,93,59,11,8,80,72,9,40,49,73,45,74,46,120,50,14,15,16,51,52,77,53,20,54,56,116,57,7,2,133,82,25,134,125,26,118,139,61,85,141],pars:130,mps_message_pol:[0,32,96],cyclic:[1,46,90,91,47,25,106],horizont:107,mrgalloc:57,unix98:52,built:[46,120,90,91,132,30,52,25,60,79,40,6,61,85],thingcheck:10,build:[1,34,127,69,76,130,91,80,25,61,74,102,39,26,105,40,20,6,131,21,85],shieldsuspend:15,mktemp:21,distribut:[1,87,90,58,59,47,71,97,25,101,9,99,20,106],passwd:78,previou:[88,95,105,108,68,70,40,116,12,14,130,20,21,81,56,23,24,133,135,26,27,28],most:[1,87,91,92,29,95,30,97,130,79,100,101,103,104,105,106,107,108,32,6,134,80,67,35,69,93,7,71,8,9,39,10,40,11,117,12,96,45,46,120,141,75,14,41,16,131,19,53,37,20,66,126,128,24,49,133,25,61,125,135,26,84,139,140,28,85,62],assoc:[24,57],moss:[139,47,108],superpag:[105,100],weak_table_t:11,dimension:[105,25],"0x000000010000d75f":26,job001811:35,carefulli:[46,95,108,121,104,24,85],pooltriv:[137,116],"9c14c":80,particularli:[46,90,91,29,24,16,82,99,103,104,107,108,20,54,117],fine:[75,96,39,135,26,69],find:[0,1,90,91,92,29,88,94,97,87,103,104,3,106,107,32,6,21,67,35,7,8,9,39,128,40,41,117,12,45,46,120,47,76,11,130,77,78,54,57,58,24,133,84,105,141,61,62],ambit:7,"0x1003f9bc8":26,ambig:[67,35,107],poolcreatev:75,boulder:47,poolamc:[35,26,134],unus:[46,57,91,92,29,133,96,130,103,134,39,26,105,93,53,2,141,55,45,126],express:[125,29,96,79,6,54,48,93,59,132,10,41,12,47,99,20,66,81,56,24,133,25,26,84,85,141],cheaper:[46,92,88,94,96,103],restart:[15,107],someclassstruct:54,"0x1003f9b68":26,"0x100001b80":26,common:[88,89,90,91,92,93,95,96,97,130,99,101,103,104,3,108,65,125,35,8,9,38,39,46,14,15,16,78,54,55,57,24,133,25,113,26,84,105,140,61,86],mps_chain_t:[58,37,4,43,44,61],splaytreeinsert:103,vinc:47,ramsei:47,argstruct:65,reserv:[91,92,93,94,96,79,102,82,105,106,107,124,134,125,35,59,112,116,12,45,46,120,75,14,78,19,20,66,24,28,18,61,141],expert:[46,139,16,62],misalign:[96,82],someth:[67,46,120,40,14,8,116,121,25,74,77,19,107,24,66,141],apistrap:7,smallest:[87,35,91,92,112,133,105,19,138,66,28],experi:[46,47,136,78,61,85],altern:[119,88,35,7,47,24,49,103,56,39,93,19,41,125,45,106],complement:46,resresourc:[66,18],"0x000000010002b399":26,popul:[29,112,25,19,141,126],uniprocessor:47,alon:106,tempor:[34,112,33,125,126,62],globalsinit:80,xleroi:70,oopsla97:47,"0x7fff5fbff3e0":26,allocp:20,simpli:[88,91,29,130,101,103,105,106,107,32,66,35,69,93,7,70,114,39,45,74,46,49,16,52,77,18,19,54,56,57,24,134,131,85],elliot:47,point:[0,1,61,91,92,93,88,94,30,2,99,101,87,104,64,106,107,108,32,65,109,66,67,34,35,69,113,7,70,71,37,9,72,115,39,141,40,41,43,12,96,45,119,46,120,50,75,13,68,14,11,52,77,128,19,138,21,55,126,57,58,79,49,82,25,28,125,112,135,26,131,118,84,105,86,140,8,62],instanti:[77,8,28,141],hangov:29,suppli:[63,128,93,7,70,49,30,133,16,25,77,103,3,99,41,54,55,62],throughout:[29,133,79,101,104,105,80,61],arenapol:[8,26],arenapok:121,frobr:27,addison:47,ram:[90,93,96,16,18,78,105,106,108,61,45],attralloc:[14,66],unnecessarili:[105,41],gap:[61,24,100,77,12,55],understand:[74,107,47,50,16,134,40,41,32,80],reslimit:66,repetit:[16,84],chatter:[0,86],bufferrankset:107,strictest:87,solid:43,define_pool_class:54,segfre:[35,141],"256k":134,unifi:77,fun:[74,68,57,69,29,8,121,117,77,10,85,134,32,124,66,81,28,56,141],wordisalign:66,subsect:32,propag:[54,50,61,40],itself:[90,91,99,100,101,103,27,106,107,108,6,21,68,35,7,70,8,10,40,41,12,46,75,16,77,128,19,54,57,36,82,134,135,26,84,137,105,141],virtu:[95,141],arenar:8,mps_ap_frame_select_from_addr:7,mps_sac_fre:19,oldkei:103,dgc:90,locusreturn:24,target_check_shallow:10,mps_pf_w3i6mv:132,moment:[24,121,39,123,41,66,141],segprefhigh:48,stripe:[24,134],sunpro:[6,132],travers:[46,8,90,103,117],task:[46,94,96,16,99,25,84,61],entri:[89,29,30,99,106,32,68,8,40,11,118,75,15,16,128,81,56,57,25,134,139,140,41,62],yehudai:47,parenthes:[20,79],withdraw:63,spend:[0,46,75,96,16,39,104,85,91,45],myunnoteseg:54,explan:[67,20,69,46],obscur:[35,19,107,92],shape:[32,91,103,3],collectionstatsnotcondemneds:32,messageclassstruct:32,cut:[20,12],cup:45,mps_message_type_gc_start:[0,130,96,58],snap:[42,35,104,105],brainstorm:80,indentifi:104,xcodebuild:6,big:[67,35,92,71,24,16,103,105,45,126],thoma:47,bit:[1,88,114,90,91,92,29,94,96,97,99,101,103,104,106,107,108,6,134,21,67,34,35,93,83,132,8,80,9,72,39,40,11,41,120,47,15,51,77,123,66,55,116,128,24,61,84,28,85,141],bip:27,awlseg:141,semi:[47,46,91,92,93,88,96,104,105],princip:25,segpref:24,transgress:[57,72],setrang:29,mps_gen_param_:[58,61],often:[87,88,90,91,92,29,95,96,97,98,99,101,102,104,105,106,108,35,69,93,8,114,9,116,12,130,46,14,16,20,24,133,25,26,84,61,85],back:[125,92,93,94,30,102,103,105,106,107,108,66,35,69,36,112,72,39,41,12,96,45,75,121,16,77,18,20,80,81,128,78,84,141],strongest:106,prot_non:[124,81,78,56],table_set:41,sizeof:[92,29,79,103,125,48,69,132,116,74,11,19,20,66,128,58,61,113,26,84,54,138,41],obj_fwd:[55,61],scale:[46,96,25,101,105,66],laru:47,mps_message_finalization_ref:[32,135,121,41],per:[125,35,75,47,29,49,30,16,51,25,134,40,32,20,21,140,80,96,130],substitut:[59,7,10,84,20,65],mathemat:[101,29],larg:[87,88,89,90,92,29,96,97,99,100,101,103,104,105,106,107,108,48,35,93,71,8,9,72,39,40,11,46,13,47,130,16,77,18,19,66,55,57,129,24,131,133,25,134,60,112,78,138,141],zcoll:60,reproduc:[88,20,26,59,46],mps_message_discard:[0,58,130,135,41,32],intial:35,mps_ap:26,vmreturn:18,mps_pool_walk:77,impos:[90,29,52,135,64,12,56],poolclassinit:20,constraint:[74,135,90,58,93,95,8,16,9,72,39,104,19,107,41,69,82,55,45],morri:47,preclud:62,manag:[0,1,2,27,4,59,8,9,11,12,13,15,16,18,19,20,21,22,24,25,26,28,29,30,31,32,34,35,37,38,39,40,41,42,43,45,46,47,130,50,52,53,54,55,56,57,58,7,61,62,63,64,66,67,48,69,72,74,77,79,83,84,85,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,82,104,105,106,107,108,109,110,112,114,115,116,118,119,120,121,122,125,126,128,133,134,135,138,139,140,141],mean_siz:112,amclargesegpag:35,abstractarenaclass:8,predat:85,arglistcheck:65,lesson:71,inclus:[112,35,61,141],few:[1,87,91,92,29,94,97,79,104,65,40,41,45,74,46,16,52,19,20,133,25,26,123],errno:74,megabyt:[87,96,104,61,92],subst:[118,7],handbook:[68,139,16,47],includ:[1,87,89,90,7,92,29,88,106,95,30,130,99,101,102,103,93,105,4,107,124,32,91,6,109,54,68,35,69,47,59,73,112,8,80,39,104,9,10,11,43,44,96,45,115,74,46,50,13,41,14,15,16,51,77,128,79,20,21,55,126,116,57,23,66,24,49,132,133,25,61,26,138,37,85,62],forward:[88,91,92,29,94,99,3,4,107,108,125,35,37,115,11,43,13,77,54,55,127,23,105,61],paren:20,busytrac:8,weak_array_scan:11,traceidmessagescr:130,subsidiari:77,mpscmf:126,quiescent:20,translat:[74,93,47,102,8,72,134,77,39,104,99,40,108,20,81,96,56],mpscmv:109,sdk:6,concaten:36,segreclaim:28,vmunmap:[124,78,18],constant:[74,120,69,29,132,14,91,99,77,103,26,3,79,114,49,75,65,141,85,106],curs:85,mps_end:77,singli:57,w3i6mv:[6,85,132],sequenti:[88,35,92,47,112,96,15,99,39,104,105,123],sheetal:47,priori:[106,68,112,28,61],metat:25,asymmetr:24,llvm:[1,132],utterli:57,bufferlimit:141,mismatch:130,deserv:[20,3,77],unclamp:[82,91,45,108],"0000000000109ae0":123,poolreclaim:[57,12,116],queri:[21,96],pthread_mutex_lock:[56,70],hilfing:47,performinternalpushframeoper:7,mps_builder_:85,root_scan:120,privat:[8,79,78,105,41,125],ringissingl:114,quarterli:47,elsewher:[128,7,36,40,66,55,85],granular:[35,24,8,100,134,28,45],adjoin:24,exit:[46,89,57,75,29,30,99,61,135,26,32,80,140,55,141],fatal:21,amcbufferempti:35,pekka:[67,35,57,23,47,24,7,121,77,39,53,116,32,66,139,12,85],buffersegmethod:107,btreturn:29,volum:107,mps_io_type_debug:74,implicitli:[54,97,27,96],stddef:73,virtualalloc:[85,45],joel:47,fortun:[67,102,9,47],"0x3":120,"0x0":26,elisp:25,crop:25,accesswrit:[66,15,51],"0x1003f9be8":26,rivera:47,append:[80,26,27,76],mps_tramp_t:140,resembl:[90,91,92,25,2,69],"1003fc000":21,mpmst:[137,116],deduc:[67,80],absolut:[114,19,93,108],"__assert_rtn":26,mps_message_type_gc:[0,130,96,58],luiz:25,waldemar:25,sink:24,tenur:[46,104,47,108],vertic:107,implicit:[91,54,104,64,105],conceiv:85,resurrect:[125,135,106],implement:[0,1,6,7,8,9,10,11,12,14,16,18,19,23,24,25,26,29,30,32,34,35,36,39,40,41,42,46,47,48,49,51,52,66,56,57,59,61,62,63,64,54,67,68,69,70,72,73,74,75,76,77,78,79,80,81,84,85,86,87,88,89,90,91,92,93,94,97,130,99,100,101,103,104,105,106,107,108,111,112,116,117,118,121,123,125,126,128,129,134,135,136,137,138,141],honor:81,foundat:67,rampmod:35,frombas:29,dconfig_plinth_non:[49,6],postpost:2,classes_count:19,train:47,basetractreturn:63,b0084kai:85,account:[67,35,69,8,9,39,41,91],cannarozzi:47,alia:[125,120,128,94,14,79,104,106,107,49,54,66],amsbufferempti:39,obvious:[50,77,39,54,81,141],fetch:[46,91,40,108],aliv:[93,95,97,99,101,105,106,68,35,71,135,115,41,12,46,13,14,11,28,113,84,61],sqlite:[6,21,86],lockclaimglob:70,protsetup:[117,81,51,56],mps_mv_free_siz:109,everywher:[61,92],gcc:[1,29,132,26,6,61,85],publicis:69,mps_pf_xci3gc:132,zonegroupnon:24,l979:47,stock:[47,25],"_addr":[61,84],inst:54,redund:[57,108],philosophi:25,physic:[46,93,102,71,95,96,99,94,82,104,105,106,108],mps_io_:[74,49],bind:[74,20,26,91],correspond:[63,87,92,29,88,96,104,64,106,107,134,80,69,7,70,8,113,115,40,11,44,45,120,15,121,52,131,123,37,66,55,116,57,132,28,135,140,41,85,141],libsqlite3:6,mps_message_type_en:[0,32,135,41],fallback:[39,85,107],tracelimit:130,meter:[50,85],movabl:[62,108],"0x1003fa7d0":[21,26],mps_os_so:132,mps_os_su:[85,132],mps_class_lo:[44,13],peyton:47,symbol_:[125,61,41],junction:95,greater:[35,29,49,114,102,103,105,66,28,45,141],spell:114,dai:[67,46,35,29,114,39,11,85],mention:[24,25,141],overkil:28,arenafre:[63,8],strive:[8,128],wordalignup:66,mps_os_s7:132,"\u00e5ke":47,"__gc":25,arenaringinit:8,strip:84,lfp:47,fluctuat:[112,24,19],rep:35,req:[29,103,107,32,54,69,7,8,39,117,74,75,130,121,52,77,80,81,56,57,24,134,137,28,85,141],facto:115,trickier:61,cwk:28,typenam:54,rel:[46,90,92,104,25,18,78,105,19,80,28],ref:[29,30,99,101,103,105,106,108,32,80,35,69,70,113,41,42,120,121,66,57,24,28,21,135,84,61,85,141],reg:80,old_symtab:61,ree:[69,116],franc:47,lossag:74,insid:[63,75,35,58,47,29,69,24,37,50,99,26,40,84,32,20,119,140,55,56],frank:47,refseg:57,releas:[88,30,79,2,32,6,70,8,116,45,46,120,75,14,50,130,56,57,58,36,135,140,41,85],likelihood:35,afterward:[120,84,45,41],refset:[66,67,8,30,134],"000ae03973336e3c":21,indent:[20,76],sigcheck:14,unanalys:7,mortal:[87,35,58,47,71,37,25,99,43,61],retain:[46,35,90,91,59,112,24,105,16,72,3,99,20],trace_set_it:130,suffix:[69,85],bame:123,facil:[67,48,35,70,49,8,50,77,39,54,73],suffic:41,ancient:80,messag:[0,88,93,96,130,101,114,107,32,21,34,125,72,49,119,12,45,74,46,14,50,121,123,80,57,58,25,60,135,136,54,41,86],btcopyinvertrang:29,udp:74,singleaccess:141,dgram:74,awlsegcr:141,"0000178ea03c2825":80,structur:[63,1,114,90,91,92,29,88,94,30,2,98,99,87,103,104,27,106,107,108,32,65,134,66,67,34,35,69,93,36,8,80,39,72,9,10,40,11,117,119,44,96,45,74,46,75,47,76,14,41,16,52,77,18,100,19,20,54,81,55,56,126,116,57,58,79,130,49,70,25,61,125,26,131,118,84,137,105,141,140,28,85,128],epdrinit:54,mps_res_resourc:[14,19,45],mps_arena_commit:[96,45],awlbufferfil:141,scan1:141,thereaft:[35,18],mps_root_destroi:[120,61],mlwork:74,have:[0,1,2,27,6,7,8,9,10,11,12,13,14,15,16,18,19,20,21,23,24,25,26,28,29,30,32,35,36,37,39,40,41,43,44,45,46,49,50,51,52,53,54,55,56,57,58,61,62,63,64,66,67,68,69,70,74,75,77,78,79,80,81,82,84,85,87,88,89,90,91,92,93,94,95,96,97,130,99,101,102,103,104,105,106,107,108,109,110,112,113,115,116,117,118,119,120,121,123,124,125,126,128,131,132,133,134,135,136,138,139,140,141],pooltrivgrei:57,wakel:47,tidi:[0,127,57,61],min:[8,85],mib:[35,141,134],mid:[30,35],"0x1003cbe38":26,mix:54,mip:[6,132],mit:47,uppercas:79,unless:[87,93,79,107,108,32,109,80,48,35,112,37,9,39,11,43,46,75,13,41,14,50,16,51,77,18,21,56,126,24,125,84,138,61,141],reservoirlimit:63,eight:[101,35,85],poolnofre:141,mps_pool_t:[119,61,69,13,126,2,112,24,37,11,115,55,125,77,19,108,138,43,109,41,4],gather:[87,105,92],request:[1,87,91,92,29,88,96,99,100,101,105,107,108,65,109,125,67,48,35,93,7,36,8,39,136,41,12,45,119,14,116,16,51,52,77,18,19,66,81,56,126,57,129,24,133,25,134,60,26,138,141,61,62],occasion:[35,40],text:[74,57,92,93,50,72,105,25,116,20,21,80],"0x100002130":26,empir:47,totalreturn:[35,26,57],texa:47,staff:[130,107],mps_ld_merg:128,untag_s:41,splaytrivupdatenod:103,scholten:47,inferior:85,richardk:3,mps_fmt_pad_t:[61,55,108],tract_of_addr:8,bear:71,regularli:57,increas:[63,88,91,94,30,101,87,106,107,80,35,45,46,75,14,15,121,131,19,21,23,24,133,103,85,141],mps_arena_start_collect:45,zendra:47,organ:[24,35,46],fixer:12,losegreclaim:28,integr:[1,67,114,93,132,66,14,96,25,74,77,27,85,79,41,43,61,45],setframeclass:7,shapiro:47,mps_pf_fri6gc:132,reform:85,pattern:[34,90,58,93,7,46,133,131,97,16,134,88,77,103,128,64,106,2,125,86],boundari:[48,91,29,47,97,99,103,93,105,107,138,28],mps_ap_:[125,69,79],compatfieldapprox:69,foostruct:[27,116],progress:[67,87,35,58,47,97,52,72,39,136,108,91,21,12,45,141],leftnod:103,locksiz:70,patholog:35,appopri:19,rankset:[30,107],revers:[0,46,29,88,30,80,103,39,104,105,20,54,61],instant:[119,88,45],equal:[47,35,69,23,29,66,49,101,39,91,6,141,55,45,92],mipspro:132,summarysofar:23,instanc:[88,92,93,96,99,101,104,105,107,32,54,48,35,112,8,40,116,12,120,75,49,77,18,66,57,24,122,28,141],equat:92,freeli:[20,55,59,24],swallow:108,comment:[0,35,69,76,52,3,40,84,20,139],reservoirwithdraw:63,gone:45,guidelin:[20,54,80,72],commenc:[80,45],traceset:[66,8,30],accumulatorreset:66,columnar:20,"0x000000010002d020":26,freeblocktestnod:103,set_mask:21,bulk:[97,12],reinhold:47,determinist:[60,26],multi:[1,46,35,97,47,59,70,130,8,96,104,125,18,93,107,108,80,140,61,56,106],attrbuf_alloc:66,plain:29,defin:[0,88,91,92,29,95,30,99,100,103,104,3,106,107,32,65,66,68,35,69,7,36,80,114,39,10,41,73,132,74,120,75,14,50,121,52,77,79,53,20,54,81,56,116,57,129,24,49,70,135,26,84,105,141,61,85,123],eintr:74,fwd2_:61,conclus:[46,35],almost:[63,46,69,93,7,77,24,25,61,101,1,27,20,125,28,56],mps_args_add_field:44,substanti:[24,9,90,106,25],partner:25,resmemori:[63,66,18],mps_arch_:85,infer:[93,25,103,105,106,3],optarg:77,denot:[6,92,29],mps_rm_prot:[120,108],w3almv:132,dealloc:[87,88,90,93,94,96,2,99,100,103,105,108,109,35,112,37,72,115,11,43,46,13,14,116,19,125,56,126,24,25,138],eventkindcontrol:80,segprefzoneset:24,wibbl:[20,50],builder:85,obj_ap:[26,61,41],thought:[75,20,21,69,66],choos:[87,91,93,103,104,106,33,125,67,34,35,7,71,113,72,40,12,45,74,50,77,54,127,24,60,112,135,61,62],amctopgen:35,btfindshorthigh:29,latest:[0,49,25,105,6,21],test1:29,test2:29,abas:50,poiter:130,zoneshift:8,systemat:[35,90],wether:35,gmk:6,adt:[63,29,70,103,66,118],traceworkclock:20,add:[125,103,104,3,107,32,6,134,21,67,69,80,9,41,44,118,46,120,50,52,77,128,19,54,57,23,24,133,25,12,26,27,61],mps_telemetry_control:[49,21,104,80,45],ada:88,ado:40,smart:[105,47,25,106],freetreeinit:103,segsmss:39,punctuat:[20,3],realiz:61,insert:[77,103,27,123,108,20,125,12,86],motorola:132,like:[63,87,90,91,29,88,96,130,99,134,27,4,107,65,6,109,54,67,35,44,69,93,59,112,37,80,39,115,9,40,11,43,12,45,74,46,75,13,41,14,15,16,52,77,78,79,138,20,21,126,116,57,58,7,66,24,131,133,25,61,125,113,26,84,64,141,8,85,106],success:[1,87,30,97,79,100,27,106,107,80,70,49,45,74,14,16,18,19,66,55,57,24,25,125,21,135,84,54,64,141,140,128],ref_p:135,porou:24,soft:[32,101,105,106,25],unreach:[1,87,90,91,88,96,82,106,108,35,116,45,119,120,16,57,25,28,60,135,26,61,62],mps_os_:85,hain:47,proper:[20,39,69,46],type_weak_t:11,butenhof:52,mps_message_type_t:[0,96,58,135,41],fromspac:[94,88,104,105],slight:[35,57,112,25,103,27,85],hosk:[139,91,47,108],noisi:50,host:[74,49,117,73],although:[88,91,29,94,30,99,103,104,105,54,93,70,8,9,39,10,41,96,46,16,52,77,78,79,66,57,25,134,62],simpler:[0,46,130,61,39,134,28,141],mps_root_t:[120,61,106],actual:[0,63,89,90,91,92,88,30,99,100,64,107,108,67,68,35,69,7,70,8,9,114,39,41,117,12,96,45,46,120,116,16,51,52,77,54,56,24,83,138,141],socket:74,withdrew:85,unfixedsummari:23,jouannaud:47,lifecycl:[60,130,72],discard:[0,88,35,58,130,72,55,135,131,19,41,32,91,125,28,45,62],predictor:47,unbox:[92,99,82,105,84,61],guard:[135,8,54,41],awhil:19,lockreleasempm:70,edeadlk:70,pictur:[1,67,12],btissetrang:29,unexpect:[26,61,25,84],bodi:[87,97,52,136,27,65,20,54,117],collectionstat:32,inlin:[1,46,120,128,69,93,84,99,79,125,27,19,40,41,6,12,66,85],buf:[14,35,7,107,49],bug:[1,46,133,90,88,14,49,85,16,25,26,99,114,108,78,21,125,45],wise:[46,90,47,94,139,56],wish:[74,35,70,30,103,39,81,56],flip:[67,88,35,140,53,7,24,8,72,125,39,104,107,21,12,66,45,92],btfindlongresrang:29,mps_count_t:112,sockaddr:74,immobil:108,pin:[95,37,84,107,108],dure:[0,88,90,91,29,94,95,30,2,99,101,103,27,106,107,108,125,67,35,69,70,8,9,39,116,12,96,45,46,75,15,52,77,128,54,55,57,28,84,105,141,61,85,62],pig:108,endsig:32,probabl:[87,88,29,30,101,103,104,105,106,32,66,67,68,35,69,40,45,74,46,120,52,20,80,24,61],misleadingli:41,mps_key_extend_bi:[48,65,138,109,44,126],detail:[1,87,91,29,94,96,99,102,103,105,107,54,67,48,35,70,80,72,39,40,41,118,74,46,68,11,50,16,77,18,79,53,21,56,128,24,134,125,135,78,84,61],virtual:[93,94,96,97,99,100,101,102,82,104,105,106,108,65,34,132,8,72,9,45,46,47,14,16,18,19,125,79,25,134,61,85,86],"000000019ef60100":123,"0x000000010000341f":26,prealloc:134,tracestartmessag:130,philipp:47,eqv_hash:41,baker:[91,92,47,94,97,25,102,104],pointeradd:66,rhsk:[20,35,107],naggum:[0,25],mps_io_flush:[49,21],mps_arena_roots_walk:[120,45],poorli:[46,9,19,99],effienc:77,mps_arena_class_cl:[44,61,45],vman_align:129,undef:[79,25],pop_bracket:20,splayupdatenodemethod:103,concret:[57,93,76,8,72,77,32,66,85],under:[1,90,91,29,79,102,103,107,108,5,59,125,67,69,7,71,117,45,14,77,20,54,81,56,23,24,135,85,62],merchant:[20,59],everi:[0,63,88,94,95,96,99,103,104,64,106,65,134,21,67,35,114,39,10,40,41,12,45,46,120,75,47,14,50,130,77,20,54,55,57,66,28,60,26,61,141],risk:[24,35],mps_final:[88,135,121,41],macraki:[139,92],rise:105,risc:97,quantiz:108,diag_end:50,quantit:74,mps_ap_create_v:125,napier88:47,x86_64:6,naiv:[35,54],direct:[87,68,35,90,91,59,29,73,24,7,16,89,99,82,49,20,54,12,125,85,130],nail:[35,95,30,72,108,42],hide:[77,69,102],introspect:[119,120,112,37,72,115,138,33,54,109,55,45,86],scp:52,supplier:46,symmetr:[103,107],liberti:74,protocolensuresomeclass:54,asymmetri:24,manipul:[46,57,75,29,30,97,51,25,55,101,10,105,118,32,140,8,56],ring_elt:27,mps_ap_create_k:[115,125,41,61,11],studio:[6,85,132],subword:29,debugg:[74,120,50,26,20,21,80,45],path:[125,91,99,100,101,21,106,108,80,34,35,40,12,76,14,77,20,66,26,84,54,105,61,85,86],precis:[87,46,35,92,47,30,89,82,103,10,105,107,108,55,96],scaveng:[87,105,104,91,47],mps_lib_telemetry_control:49,portabl:[1,47,49,25,105,79,84,21,61,85],mps_sac_alloc_fast:19,amherst:47,strai:77,printf:[0,50,3,123,41],mps_fmt_create_b:55,describ:[87,88,91,92,93,94,30,130,99,134,127,103,104,64,106,107,108,32,5,6,109,54,67,48,35,7,36,8,80,9,72,39,40,41,43,96,46,120,50,75,68,49,123,11,16,52,19,53,138,20,21,55,56,116,57,58,79,66,24,133,25,61,125,84,105,141,28,85,62],would:[125,88,89,91,92,29,128,95,30,97,130,101,103,27,4,54,67,68,35,69,59,112,8,9,39,40,41,12,45,46,120,75,14,11,16,52,77,78,19,53,20,21,81,55,56,126,57,66,24,49,133,25,135,121,118,141,61,106],tracestruct:130,musn:85,phong:47,must:[0,1,27,4,6,7,8,9,10,11,13,15,16,18,19,20,21,23,24,26,28,29,30,32,35,37,39,40,41,42,43,44,45,46,68,49,50,52,54,55,56,57,58,59,61,62,63,64,66,67,48,69,70,73,74,75,77,78,79,80,82,84,85,87,88,90,91,93,94,95,96,108,130,99,102,103,104,105,106,107,2,109,112,113,114,115,116,118,119,120,121,125,126,128,133,134,135,137,138,140,141],shoot:46,blumof:47,join:[27,136,3,79],henri:[104,47],edelson:[105,47,25],poolfinish:[48,116],overrid:[54,78,40],obj_fmt_:[55,61],segreg:[88,89,92,97,105,4,109,34,112,37,115,41,43,119,13,11,19,126,127,84,138,62,61,86],tracesetempti:[8,30,141],end:[125,88,89,29,94,99,3,106,32,80,48,35,69,7,8,40,41,44,45,120,14,50,130,131,79,20,54,55,57,24,135,26,137,105,141,61,62],concis:[65,21],bekker:47,env:[74,52,26,123,80,73],ancestor:25,dialect:25,mess:[20,69],tracescanstack:118,lovemor:139,befor:[125,88,92,29,30,79,103,27,107,2,32,54,48,35,69,70,11,37,80,9,114,39,40,41,44,96,45,46,120,75,14,15,52,77,128,138,20,21,57,24,133,25,61,135,84,105,141,8,62],parallel:[87,46,91,47,7,99,104,105,108,73,55],poolmvff:103,bootstrap:27,segsplit:[30,39],exclud:[49,6,92,29],curent:52,environ:[125,92,93,94,103,106,107,108,6,21,69,70,41,73,74,46,75,47,49,50,123,80,56,25,26,140,61,85,86],reloc:[67,91,92,105,106,107,55],enter:[35,57,93,15,26,105,108,80],exclus:[75,70,104,61,18,107,140,55,118,62],composit:[102,105,91,25],over:[90,91,29,30,2,103,27,107,108,80,67,48,35,93,112,8,39,10,40,41,117,96,45,74,120,75,49,15,16,52,77,78,66,55,57,58,24,60,131,121,118,105,141,61,85,128],becaus:[1,2,3,7,8,9,10,11,12,14,16,18,19,20,21,24,25,26,27,28,29,30,121,35,39,40,41,44,45,46,49,50,52,53,54,56,57,61,63,64,65,66,67,68,70,75,77,78,79,80,81,84,85,87,88,89,90,91,92,93,94,95,96,97,99,100,101,102,103,104,105,106,107,108,135,116,118,120,130,123,124,125,128,133,113,137,138,141],dijkstra:[96,104,91,47],ulongest:[66,123,85],btcopyrang:29,digest:108,hashf:41,fwrite:49,tramp:[81,51,56],drawback:[9,81],comprehens:91,taiichi:47,diag_singlef:50,suspendthread:118,unlucki:135,eventwdstruct:80,choic:[90,58,7,29,102,30,50,133,52,25,77,93,105,107,61,56,96],"0x000000010001f2d2":26,string_hash:41,firsttract:30,each:[0,2,6,7,8,9,10,11,14,15,16,18,19,20,21,23,24,26,28,29,30,35,132,37,39,40,41,44,45,46,50,51,52,54,55,57,58,60,61,62,63,66,67,68,69,71,75,77,78,79,80,84,85,87,88,89,90,91,92,93,94,95,96,97,99,101,102,103,104,105,106,107,108,112,116,117,118,120,130,123,124,125,126,128,133,134,113,140,141],amsinitintern:39,mps_mvt_size:112,finalizationref:32,prohibit:69,goe:[46,35,47,24,120,77,105,6,45],newli:[68,35,58,24,91,103,27,107,75,125],job001570:130,laid:[88,26],got:[32,57,141],arizona:47,worthwhil:[24,46],mps_class_awl:[41,44,11],free:[63,1,89,90,91,92,29,88,94,95,96,97,130,99,87,101,103,104,105,106,107,108,32,65,6,109,67,48,69,93,7,111,112,8,9,39,11,73,45,46,120,14,116,16,77,18,19,20,125,100,126,57,2,129,24,133,82,25,61,135,118,134,138,141,28,62],whereupon:57,foocreat:80,puzzl:41,substructur:107,filter:[49,50,72,104,40,21],heck:47,"0x0000000000000000":26,onto:[63,46,35,23,93,30,116,52,77,64,2,105,81,73,141],cbstest:29,"0x0000000000000004":26,"0x0000000000000005":26,tortuou:69,rang:[63,92,29,94,96,101,82,105,106,108,66,68,112,118,77,18,80,56,28,78,61,141],nhc:47,rank:[89,93,106,30,101,105,4,107,33,34,35,115,39,40,41,44,120,13,11,121,123,53,141,66,57,12,28,113,26,84,62,61,86],necess:[7,45],restrict:[92,99,105,107,108,6,48,69,7,39,11,12,45,49,52,77,20,125,55,56,134,135,64,85,141],datastructur:[29,8,52,51,103,30,56],alreadi:[0,88,90,91,103,27,32,54,35,70,8,9,39,40,41,118,75,52,21,57,24,137,140,61,141],primari:[103,96,85,108],rewritten:57,top:[1,46,35,58,7,29,68,8,138,72,101,60,103,26,105,41,20,80,12,37,56],epdrpoolclass:54,eqv:[0,135,26,41],toi:[0,120,128,71,84,135,26,41,21,61],too:[1,96,101,104,107,67,35,69,7,71,9,41,45,119,46,49,11,130,77,18,19,66,126,58,24,25,26,61],kanefski:47,tom:[139,114],mps_message_get:[0,58,96,135,41,32],tool:[74,46,47,36,49,96,50,16,25,80,76,72,114,20,6,132,21,85,106],took:[125,128],incur:[24,89,4],conserv:[87,88,89,91,92,93,96,99,103,105,108,68,35,9,11,42,46,47,16,66,57,24,25,141],simula:[47,25],config_var_rash:[14,106],expr:20,mps_os_w3:[85,132],"final":[0,1,88,130,101,104,106,108,32,109,67,34,35,112,8,113,72,115,40,41,42,43,44,46,13,47,11,15,121,52,123,141,66,126,127,57,12,25,61,60,135,138,86,37,62],expl:24,poolinit:[8,80,21,116],fashion:[135,96,12,25,107],ran:[66,19],pass:[0,88,91,92,29,96,98,99,100,101,103,27,4,107,2,32,65,109,54,67,68,35,44,112,37,114,115,39,40,11,42,43,12,45,74,120,13,47,14,116,16,77,128,19,138,21,81,55,56,126,57,58,66,24,49,82,25,134,125,113,26,84,105,141,140,61,85,62],thr:[120,140],raw:[8,82,106],rat:85,harper:47,thorough:85,contact:[1,34,120,59,140,41,79,136,125,115,113,26,64,11,20,6,138,43,45],obj_quot:61,mps_class_ams_debug:[43,44,2],thoroughli:66,pagetablemap:20,shallow:10,insur:35,sock_dgram:74,though:[135,35,69,29,96,52,25,55,39,26,40,108,20,78,82,73,28,45],bst:23,mps_root_scan_t:120,coin:47,everyth:[120,23,35,20,21,61],flop:24,flow:[32,80,75,25],declar:[125,88,29,3,101,64,106,107,32,65,66,69,93,36,115,116,45,46,120,47,122,79,20,54,134,27,105,28,85],amsfix:39,abi:[85,132],mps_fmt_fencepost_wrap:77,random:[88,57,130,114,60,26,105,106,107],popl:47,boolcheck:66,mpsliban:[49,6,73],i5m2cc:132,configur:[29,30,104,6,109,34,70,112,8,72,115,39,11,43,12,45,74,13,76,21,117,126,24,25,138,37,85,62],weakrefer:[101,106,25],watch:96,sharealloct:39,mps_fix:[69,55,40,84],report:[125,46,128,47,49,30,121,25,60,103,104,99,21,61,130],reconstruct:[74,26],poolframeselectfromaddrmethod:7,gareth:[139,69,116],snazzi:123,twice:[46,120,64,107,77],mergedsegreturn:30,btcv:29,richer:32,resist:123,loreclaim:[12,28,40],nul:[125,49,21,80],"0x1003faf20":[21,26],corrupt:[46,90,93,14,114,77,39,26,2,21,80],splaytreefinish:103,amcsegclass:35,hopefulli:40,databas:[59,47,9,106,6,21],phantomli:108,discoveri:35,outstand:15,res_io:77,approach:[35,75,47,133,15,16,103,79,39,85,81,56],weak:[1,90,29,101,104,105,106,108,33,67,34,35,37,113,115,40,11,43,12,120,41,141,66,127,57,133,25,28,135,62,61,86],unpreserv:35,protect:[87,88,92,106,30,79,101,102,105,4,108,33,109,66,67,34,70,112,8,72,115,41,43,96,45,120,15,75,13,47,121,11,117,51,52,78,37,124,54,81,55,56,126,116,28,125,26,134,138,86,140,61,85,62],mpscamc:[37,4,79,61],"0000178ea03c2c27":80,fault:[1,87,92,96,99,101,102,105,106,108,33,8,11,117,118,47,15,51,52,81,55,56,57],buckets_fmt:41,maxlength:29,mps_telemetry_databas:21,trust:106,amcinitcomm:35,been:[0,1,61,91,92,29,88,94,96,97,130,114,87,101,103,90,105,106,107,108,32,134,54,67,68,35,113,7,132,8,80,9,72,110,104,39,128,40,41,42,119,44,45,74,46,14,116,16,51,52,77,18,19,141,124,21,55,56,57,58,23,66,24,82,25,28,125,135,26,121,118,84,139,140,37,85,62],accumul:[35,23,95,16,107,116,66,12,130],rankambig:[35,40,42,66,28,141],valu:[0,88,89,90,91,92,29,30,97,99,101,102,103,104,27,106,107,108,54,68,35,93,7,132,8,80,114,9,10,40,11,42,44,96,45,74,46,120,50,75,14,41,130,52,128,19,21,55,116,57,23,79,2,66,49,82,25,61,125,113,26,118,84,105,28,141],quickli:[57,91,92,8,15,96,60,104,85,40,117,141,61,45,106],uncommon:35,"_msc_ver":85,sighandl:[81,56],"catch":[90,58,25,114,81,56],"_m_ix86":85,amortis:103,type_fwd2:61,mps_alloc_pattern_ramp_collect_al:131,weren:91,diag_moref:50,type_symbol:[125,26,61,41],mps_sac_free_fast:19,tediou:46,suggest:[46,57,29,71,14,94,136,3,138,139,12,61,141],complex:[46,93,7,48,130,96,50,16,103,25,77,39,26,104,99,54,85,106],complet:[125,91,29,96,130,101,103,105,107,54,67,69,59,71,114,9,49,73,45,74,46,120,14,15,16,20,80,55,56,12,84,61,85,141],mps_fmt_adjust_fencepost_t:77,vvv:21,dylan:[29,102,107,32,35,69,59,8,39,40,41,12,16,11,121,52,54,57,25,134,28,85,141],greatest:29,lockstruct:70,jean:47,bufferinitseg:80,arena_ld_length:8,ams_is_invalid_colour:14,antidot:32,segfinish:20,"0000178ea03f6b72":80,buffersetranksetmethod:107,pushfram:7,expos:[87,35,15,52,102,105,32,45,141],interfer:45,henriqu:25,els:[0,67,35,53,7,24,41,114,74,103,26,85,107,11,20,125,61,45,141],performinternalpopframeoper:7,elt:27,gave:[46,25],tactic:61,obj_isfwd:[55,61],apart:[20,10,16,68,24],ditto:[24,107],arbitrari:[8,130,79,100,103,3,54,81,55,56],hunt:47,mps_pf_fri3gc:132,slothigh:48,spongr:27,indirect:[89,90,59,73,82,99,103,40,20,12],successfulli:[119,120,90,58,125,103,131,19,54,55,45,106],mps_key_max_s:[112,65,109,44],cooper:[67,92,47,70,8,104,52,25,134,9,18,56,78,45],clash:[54,69,79],mps_class_amcz:[44,4,41],ucsc:47,eventcnv:80,fencepost:[88,90,7,94,14,77,2,137],core:[74,35,90,69,24,96,79,91,80,73],splaytre:103,hsu:47,chapter:[68,47,103,26,40,61,45],alexand:47,steadili:112,surround:20,unfortun:[46,35,15,16,50],approxim:[67,46,120,90,58,23,93,88,24,30,15,134,87,106,107,66,97,8,141],sept:47,produc:[119,35,58,29,50,120,25,77,85,21,125,45,106],fixedsummari:12,encod:[92,29,36,24,104,82,101,102,39,18,106,21],attrincr_rb:66,mps_args_begin:[2,13,112,37,11,61,115,4,41,138,43,109,44,55,45,126],cafeteria:105,storag:[0,87,90,91,92,29,94,96,97,100,101,102,105,106,108,32,93,112,72,9,45,46,47,130,52,122,54,57,24,25],stefanov:47,mps_t_word:[66,85,132],"class":[63,1,114,90,91,92,29,88,106,30,2,134,99,87,101,102,103,64,4,107,108,32,33,6,109,54,34,35,44,93,7,111,112,8,76,113,72,115,39,141,40,11,43,12,45,119,46,120,138,75,13,48,14,41,121,127,77,18,19,37,21,55,126,116,57,23,79,65,66,24,25,61,125,135,122,84,137,105,86,140,28,62],mps_build_sc:132,stuck:35,reli:[46,75,7,94,14,52,79,140,112,9,104,40,91,21,135,125,118,62],gib:134,btfindresrang:[29,141],synthesis:50,head:[63,57,95,15,77,27,20,80,125],medium:[35,72],hear:[130,62],heap:[87,88,90,91,92,93,96,99,100,104,105,106,67,37,116,12,45,46,120,47,16,55,133,25,26,84,61],hashtabl:41,freenod:103,aps31dt:68,flavour:35,attr:[74,57,7,14,8,24,66],shieldresum:15,autoconf:6,accessset:[66,30,15,51],mps_reserv:[14,79,61,77,26,106,41,125,55],"1003fd000":21,mps_word_width:[85,29,132],decrypt:84,mps_class_t:[119,13,115,112,37,11,77,4,108,138,43,109,126],darko:47,triv:137,check:[0,63,90,29,88,94,30,2,103,27,114,107,65,32,33,6,66,67,34,35,69,7,70,8,72,115,39,10,40,41,12,45,119,46,50,75,47,76,14,15,130,52,77,19,54,125,116,57,23,132,133,61,60,135,26,84,137,64,141,28,85,123],protsync:[85,81,51,56,117],assembl:[68,47,25,103,40,65,85],when:[0,2,27,4,5,6,7,8,9,11,12,13,14,15,16,18,19,20,21,23,24,25,26,28,29,30,32,35,37,39,40,41,43,44,45,46,49,50,52,53,54,55,56,57,58,61,62,63,66,67,48,69,71,73,74,77,78,79,80,81,82,84,85,87,88,89,90,91,92,93,94,95,96,97,130,99,100,101,103,104,105,106,107,108,109,111,112,113,114,115,116,120,121,122,125,126,128,133,135,137,138,140,141],deni:[24,15,116],poolstruct:[35,57,116,137,28,141],telemetri:[74,34,116,128,40,71,14,49,50,80,72,61,104,26,79,107,41,6,21,45,86],node:[87,101,89,57,91,95,60,103,104,27,53,32,105],benefici:[48,103,29],zmess:[60,130],consid:[87,88,29,95,96,97,105,93,7,8,40,116,73,119,46,50,16,52,20,125,55,57,58,24,141,62],younger:[87,35,91,95,89,99,106],longer:[0,88,90,91,29,30,97,105,106,108,54,68,35,9,39,11,42,12,96,119,46,14,15,16,18,19,124,66,81,55,116,58,25,135,78,139,61,85],mps_rm_t:[120,106],offsetof:[69,11,41,26,116,84,125,61],backward:[87,65,8,3,29],strong_buckets_ap:41,rom:[96,106],ron:47,globals_root:61,segclass:[48,30,57,54],cacm:47,signific:[87,46,75,93,29,112,24,8,133,16,49,101,103,104,108,138,21,80,96],computation:102,epdralloc:54,row:80,demer:[87,47],proxim:74,readabl:[32,21,50,80,86],environment:[60,49],lasttract:8,henderson:47,sourc:[1,93,128,103,3,107,6,54,34,69,59,36,8,76,80,72,39,11,45,74,46,47,68,49,50,130,77,78,20,21,56,57,66,24,25,113,84,27,28,85,62],unfamiliar:98,feasibl:77,broadli:[97,55],cook:47,cool:[91,14,100,102,26,21,106,49,6,80,85],"0x1003f9af8":26,level:[1,91,93,30,99,100,101,102,103,105,106,108,66,7,132,8,80,72,9,10,41,12,96,74,46,50,11,15,16,52,77,18,20,21,57,24,25,26,85],metadata:[41,11],traceidmessagescheck:130,"__time__":36,quick:[60,88,97,133],spent:[96,45],slower:[46,91,92,29,96,39],colin:47,pmo:47,port:[74,49,25,117,135,41,80,61,85],mps_ap_set_frame_class:7,leaf_ap:41,rootstruct:66,buckets_fmt_:41,paragraph:[20,50,69,72,76],unobtrus:[46,47],water:[39,92],mps_io:74,proud:21,thirti:47,rafael:47,semant:[68,57,69,49,8,25,134,90,107,32,54,12,80],isfwd:[55,41],rash:[91,93,14,100,102,106,85],visibl:[57,75,93,50,79,45],prompt:[88,57,135,25,9,106,11,6,45],post:[0,88,57,58,23,96,130,52,72,135,114,41,32,80,12],prei:108,memori:[0,1,2,27,6,59,8,9,11,12,14,15,16,18,19,20,21,22,24,25,26,28,29,30,31,32,34,35,132,37,38,39,40,41,42,45,46,47,48,49,50,51,66,55,56,57,58,7,60,61,62,63,65,67,68,69,71,72,74,77,78,79,80,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,82,104,105,106,107,108,110,111,114,116,118,119,120,130,125,126,127,128,131,133,134,135,136,138,139,140,141],todai:[46,105,25],"0xfdfdfdfd":77,handler:[63,26,14,8,117,49,51,102,52,10,134,108,21,81,140,55,56],criteria:24,msg:[74,80],prev:[20,125],reorder:125,share:[91,94,30,102,104,105,107,6,21,70,8,80,9,72,39,41,96,45,46,75,47,16,52,77,78,54,24,25,26,84,140],brooksbi:[1,47,8,15,114,107,65,139,85],prototyp:[69,29,25,107,65,85],allegro:25,judi:139,poolam:[14,29],selectfram:7,judg:35,siglopool:28,inadequ:[105,57,16],findshortresrang:29,purpos:[88,61,91,92,96,114,134,103,105,4,107,6,109,21,35,59,70,112,8,72,39,11,45,74,46,75,47,50,130,52,19,20,54,55,7,24,25,28,118,84,138,140,37],laughter:21,strother:47,stream:[88,123,57,92,14,49,50,80,61,104,103,26,116,107,41,20,6,141,21,45,86],backslash:20,limitreturn:[35,29,141],unsent:130,critic:[125,91,96,99,100,32,21,34,35,70,114,40,12,47,76,14,77,80,24,26,84,54,61,85,86],contamin:47,verlag:47,alwai:[0,63,92,93,88,30,97,99,101,102,87,105,106,2,65,66,35,69,7,132,112,80,41,42,12,45,46,120,15,75,14,50,130,77,124,131,79,53,20,21,81,55,56,57,23,24,133,134,26,84,138,61,85,141],differenti:[24,106],vital:[92,14,99,84,125,66],anyon:[20,3,28,46],fourth:[80,61],poolclassepvm:29,clone:47,scoff:85,make_t:41,bufferlog:107,genear:35,mps_fmt_class_t:[69,55],practic:[67,101,35,128,75,47,29,24,91,16,79,60,9,18,84,137,20,21,61,92],predic:[102,54,96],inform:[0,87,90,91,92,93,88,94,96,98,99,101,102,82,104,107,108,32,54,67,69,59,36,8,80,9,38,39,136,40,116,12,45,74,47,49,50,16,52,77,18,20,21,55,57,58,24,134,26,118,84,28,141],preced:[20,35,133,44,103],combin:[1,91,101,106,108,6,67,48,132,8,114,9,46,47,16,77,18,19,53,133,25,138,85],splaytreeneighbour:103,size_o:74,anticip:[46,108],changeov:40,ymmv:1,size_t:[29,79,2,65,109,125,69,70,112,37,41,44,45,74,46,120,49,11,51,77,19,20,66,55,126,58,26,84,138,140,61,85],mainli:[74,24,16,72,105,25],trapap:7,mckinlei:47,newblock:103,mayuseinlin:48,anecdot:7,dylan_scan_contig:40,term:[1,88,89,90,91,92,93,94,95,96,97,99,100,101,102,87,104,105,106,107,108,6,35,69,59,112,39,40,46,75,16,52,77,80,81,56,82,134,83,28,141],name:[92,29,94,97,99,27,114,32,65,6,21,67,35,69,93,7,36,11,80,72,10,49,44,46,76,14,50,130,52,77,79,20,54,55,116,66,24,132,25,134,141,41,85,123],sigusr2:[140,52],ters:[20,50],moher:47,individu:[128,91,29,8,131,108,80],"0000178ea03f4ec8":80,"0x00000001003f9bc8":26,begun:35,dispos:[52,25,55],abcdefghijklmnopqrstuvwxyz:[3,114],grai:[87,91,92,94,99,101,104,105],profit:[20,59],rankfin:[66,57],profil:[26,47,132,71,112,104,21,12],obj_unus:41,kent:[139,47],mps_arena_expos:45,nofin:57,unusedtablepag:134,theori:[20,96,93,92,59],boehm:[87,46,120,91,92,47,99,135,25,139],mps_word_shift:[85,29,132],prescrib:105,synchron:[0,46,90,91,7,47,106,104,52,72,103,93,105,19,107,125,92],refus:[124,8,45],motion:[82,91,47,45,108],turn:[67,87,97,58,2,50,77,39,26,105,116,41,91,21,84,55],place:[92,128,96,99,103,104,105,106,107,108,32,125,35,69,112,8,11,45,46,120,75,41,15,16,78,53,20,21,55,57,58,24,25,134,135,26,141,61,85,62],imposs:[32,65,30,99],origin:[88,29,30,135,25,55,101,103,78,105,72,40,41,139,12,8,106],suspend:[67,75,70,8,52,118,140,55,56],arrai:[88,89,91,92,29,97,98,99,102,27,65,35,8,41,44,120,11,130,19,37,66,55,57,58,79,25,134,105,140,61,141],bufferempti:[8,57,107],supernam:54,refsetempti:[30,23],suspens:[15,52,56,118],xci3gc:[6,80,132],ensurebufferclass:107,predefin:[69,61,85],wordaligndown:66,ian:47,pad1_:[26,61],anderson:139,necessarili:[91,7,66,104,61,26,118,21,54,45],mps_roots_stepper_t:120,circl:25,white:[87,89,91,92,94,30,99,101,104,105,67,35,8,39,40,116,42,12,76,53,20,55,23,139,141],mps_pool_create_v:119,mps_fmt_scan_t:[120,61,105,40,84,55],cope:[46,120,69,96,11,135,108,12],copi:[87,88,91,92,29,94,96,97,99,101,102,82,104,105,4,108,33,6,80,67,34,35,59,71,8,9,39,40,41,42,43,12,46,13,47,14,15,77,131,79,53,54,55,58,7,106,49,25,61,125,84,141,2,37,62],alan:47,ebi:47,enclos:[88,91,27,79],wow64:1,holder:[20,59],mps_pool_create_k:[119,2,13,112,14,37,11,61,115,138,4,41,65,43,109,55,126],serv:[112,8,39],wide:[46,35,90,58,112,37,15,25,9,97],amcfix:[35,12,40],subexpress:125,kolodn:47,posix:[34,69,52,72,118,56],balanc:[103,15,96,93],mpsavm:[79,61,45],posit:[119,120,128,93,29,76,24,30,15,80,79,61,39,84,41,20,66,98,65,55],seri:[101,88,9,90,21],pre:[6,130,35,107],ani:[0,2,3,6,7,8,9,10,11,12,14,15,16,18,19,20,21,23,24,25,26,27,28,29,30,32,35,36,37,39,40,41,44,45,46,68,49,50,51,52,53,54,55,56,57,59,60,61,62,63,65,66,67,48,69,70,73,74,75,77,78,79,80,81,82,84,85,88,90,91,92,93,94,96,97,130,99,100,101,103,104,105,106,107,108,112,114,116,117,120,121,123,124,125,128,133,135,137,138,140,141],subroutin:91,nickola:47,fp_pattern:77,gustavo:47,techniqu:[1,87,90,91,92,93,95,96,97,101,102,105,106,67,34,71,8,9,114,38,39,40,46,47,16,52,54,57,133,25,84],ideal:[13,71,96,16,99,106,40,54,141],"0x1003f9c18":26,sure:[74,46,89,69,24,50,77,39,26,105,107,84,61,118],tospac:[88,105,104,91,95],multipli:45,clearer:[20,66],eclect:25,compattyp:69,frig:81,later:[0,46,35,57,58,40,24,41,16,39,74,1,9,128,105,107,108,91,141,45,130],quantiti:[87,46,35,92,24,96,98,100,104,108,32],runtim:[47,40,25,61],senior:139,lwpoppend:7,uncondit:20,cheap:[87,90,24,133,39,80],permiss:[125,80,55,25],hack:[80,35,69,52,29],explicitli:[1,87,79,66,97,52,25,103,99,118,32,21,12,54,45],mps_message_type_gc_gener:130,mrgring:57,written:[1,90,91,29,104,106,107,2,32,65,54,67,68,69,80,114,39,40,11,46,75,49,16,52,123,20,21,57,133,25,113,139,61,85,141],btfindshort:29,analys:[74,58],amsinit:39,allocat:70,tailor:47,mrglinksegclass:57,freestor:[88,100],ssb:105,reveal:[74,26,93,56,41],poolframepushmethod:7,joker:21,nettl:[106,47],mps_formatted_objects_stepper_t:[105,55],poolinitmv:80,closurep:103,labori:39,lnc:47,detect:[125,90,93,30,97,99,101,103,106,2,32,54,35,69,7,113,114,39,41,45,46,120,76,14,11,16,77,19,80,57,135,26,61,85,62],review:[85,69,47,40,61],endtrac:50,dybvig:[106,47],comp:[52,25],tarditi:47,cycl:[87,88,35,57,91,93,71,11,25,60,101,104,105,72,99,108,32,12,45],bitset:[66,92],"0000178ea03f4db4":80,come:[74,55,61,69,29,102,24,8,96,16,25,28,90,78,99,30,11,20,6,21,45],reaction:21,region:[46,93,47,48,24,30,116,25,88,26,105,72,107,84,124,54,68,28,106],quiet:20,contract:[20,8,78,59,24],retir:[85,76],coucaud:47,bufferpool:[14,75,107],jitter:24,color:[87,91,92,94,99,101,104,105],inspir:25,period:[46,90,24,9,131,105,61,45],insist:[24,54,7],duti:25,sleator96:103,poll:[0,8,72,39,41,32],poli:54,coupl:[46,61],chain_o:58,isreadi:107,table_ref:[128,41],followup:52,andrew:[139,47],"0x5193e559":114,ironpython:25,mps_message_gc_condemned_s:[130,58],mps_arena_spare_commit_limit:[105,45],"case":[0,63,91,93,88,94,30,99,87,103,112,64,106,107,32,6,54,48,35,69,132,71,8,9,39,40,11,43,12,45,74,46,120,75,47,14,41,121,52,77,18,19,138,20,21,81,125,55,56,116,57,79,66,24,131,25,61,60,1,135,26,84,105,141,140,28,85,128],thisclasscoerc:54,cast:[88,69,94,49,79,104,123,84,54,66],mps_message_gc_not_condemned_s:[130,58],mps_alloc_dbg_v:77,sizereturn:103,clutter:[20,50],sos9sc:132,pthreadext_sigresum:52,eventf:80,alphabet:[34,3,29,76],lippgc:132,trip:[35,75,7,107],mps_arena_class_t:[93,45],oldnod:103,eventu:[0,67,57,16,25,77,39,78,32,124,56],ensuresomeclass:54,week:25,nest:[35,15,91,7,50,131,107,44,56],confidenti:15,driver:85,event_param:21,director:139,mps_res_fail:[14,135,131,84],mps_fmt_skip_t:[105,55,61],mps_args_end:[2,13,112,37,11,61,115,4,41,138,43,109,44,55,45,126],freetreestruct:103,moder:85,justifi:[68,35,57,93,29,39,78,107,124,28,141],without:[0,1,89,90,29,88,94,96,130,99,87,101,103,105,106,107,32,6,66,35,69,59,8,80,9,40,43,119,44,45,74,46,120,75,13,47,14,15,16,52,77,18,19,53,20,54,81,55,56,127,58,7,79,24,131,25,125,135,78,84,28,85,141],relief:24,model:[87,39,7,47,25],branquart:[47,25],event3:80,addr_io:77,table_rehash:[128,41],"4kib":40,conform:[91,29,49,79,54,85],gavin:[139,47,107],doligez:[47,25,108],kill:[46,81,56],rankexact:[66,57,141],miscellan:[46,49,38],hint:[46,58,93,112,91,131,19,138,20,109,61,85],except:[1,92,29,30,99,101,3,4,107,108,32,65,35,69,93,59,70,37,116,117,96,118,46,120,75,130,15,121,52,77,19,53,20,21,81,55,56,79,24,133,25,28,84,27,140,8,106],notori:25,vulner:[46,62],disrupt:[24,47],splayfindfirst:103,reassembl:84,whitespac:20,patrick:47,robson:47,fooarena:69,free_:116,trampolin:[81,140,28,56],mps_key_format:[2,13,37,11,61,115,4,41,43,44,55],interlock:128,shcachelimit:15,slice:[67,58],freep:20,legal:[44,24,15,52,18,32,12],moon:[139,47,25],moor:[47,29],mps_fix2:[88,120,11,84,55,113,40,41,61],mps_fix1:[88,120,11,84,55,113,40,41,61],complic:[35,29,24,77,106,108,80,85],freed:[63,88,90,91,92,93,96,97,105,107,108,35,111,112,8,9,46,130,16,19,20,125,57,61],immun:[91,99],mps_ss_:[69,79],garbag:[0,1,89,61,91,92,93,88,94,95,30,97,130,99,101,87,90,105,106,108,6,109,66,67,34,35,7,115,71,37,38,104,9,40,41,43,12,96,45,119,46,120,13,47,14,11,16,139,128,21,55,126,127,57,58,131,82,25,28,125,112,135,26,134,138,86,140,8,62],inspect:[29,51,99,39,26,85,32,5,55,45],"0x00007fff9050ae2a":26,immut:[24,96,99,102,25,41],microcod:25,s7m6mw:132,earlier:[0,90,92,24,27,107,105],stand:[46,35,57,101,9,18,122],disadvantag:[9,104,16,61,92],routin:[88,46,121,77,39,123],"00000001003fd000":21,artur:47,nikla:47,unconvent:130,fmtdy:40,certainli:[46,57,75,28],checkabl:8,strict:[87,75,92,59,24,91,105,106,20,54],mps_os_li:132,interfac:[0,1,4,5,7,8,10,11,13,14,16,18,19,21,24,25,28,29,30,32,33,34,35,132,37,39,40,42,43,44,45,46,47,49,51,52,54,56,57,61,63,65,66,68,69,70,72,73,74,75,76,77,78,79,80,81,84,85,86,87,88,90,91,92,93,94,95,98,99,102,103,104,106,107,109,112,116,118,119,120,121,123,124,125,126,128,129,130,133,134,135,137,138,140,141],ferrit:91,buffer_o:74,strictli:[87,141,85,29,92],mps_message_gc_start_whi:[0,130,58],morrison:47,tupl:93,regard:[90,69,24,96,9,91],alain:[47,25],amongst:128,obj_u:61,realli:[63,46,35,57,119,88,8,67,74,77,103,84,30],illus:[0,96,15,105,117],untag:11,faster:[0,46,96,16,25,87,105,19,84,66,125],notat:29,nmake:[6,85],sbrk:[94,105,92],notab:20,addradd:[20,66,103],strongli:[87,47,108,25,101,138,105,106,41,20],intro:[63,29,30,103,32,5,66,67,48,35,7,36,8,80,39,10,116,42,117,73,74,15,75,68,50,130,52,51,77,18,123,124,54,81,56,57,129,24,134,60,78,28,85,141],type_str:[26,41],encompass:28,rearrang:[30,103],incorrect:107,compel:46,idiom:[65,105],reconsid:24,compet:[99,45],presenc:[97,75,93,15,77,9,128,11],trash:107,discours:91,symbol:[125,120,69,47,29,65,49,50,127,25,26,79,41,20,21,12,61,85,86],wirth:25,briefli:[133,9,57,16,40],collectionstatslives:32,stackscan:[68,118],directori:[6,85],resparam:66,pollend:20,potenti:[87,120,93,29,70,24,52,9,40,49,80,61,85],degrad:[46,13],allocframeclass:7,all:[0,1,2,3,6,7,8,9,10,11,12,14,15,16,19,20,21,23,24,25,26,27,28,29,30,32,35,132,37,39,40,41,42,44,45,46,50,52,53,54,55,56,57,58,59,61,62,63,64,65,66,67,68,69,70,71,75,77,78,79,80,81,84,85,87,88,89,90,91,92,93,95,96,97,99,100,101,103,104,105,106,107,108,112,113,114,116,117,118,119,120,121,124,125,126,128,134,135,131,138,140,141],lack:[74,49,96,25,107,12],ala:29,scalar:[93,97,102,3,32,105,55],abil:[67,92,30,16,25,77,85],ptw:[24,107],follow:[0,63,91,29,30,130,99,103,104,3,106,107,32,54,67,48,35,44,69,59,36,8,80,39,9,136,11,12,96,46,120,50,75,14,41,16,138,78,19,37,20,21,55,116,57,7,79,66,24,105,70,133,25,61,125,26,131,84,64,141,28,123],disk:[74,46,92,47,96,97,100,102,105,106,108],abid:8,plausibl:[46,29],init:[63,103,27,107,32,125,48,35,7,8,114,39,116,74,75,76,52,77,123,20,54,57,24,28,141],program:[0,1,90,91,92,93,88,94,96,97,130,99,100,101,102,87,104,64,106,108,5,6,125,69,59,36,71,37,113,9,40,11,43,119,45,74,46,120,50,47,14,41,16,52,131,19,21,55,128,58,79,2,24,49,133,82,25,112,135,26,84,105,140,61,85,62],neglig:[20,59],liter:91,far:[67,46,29,70,94,24,80,16,99,26,40,41,66,61,45],faq:[46,25],fat:85,arenareleas:8,mps_class_amc:[37,44,61],worst:[87,48,35,93,47,88,133,101,135,11,138],failur:[90,30,103,104,107,32,66,7,39,41,96,118,74,14,116,130,54,128,24,49,26,137],lisp:[87,46,35,91,93,47,96,16,25,100,101,102,104,105,99,21],rescommit_limit:[8,66],list:[0,63,89,90,91,92,29,88,30,98,102,87,104,27,106,65,80,48,35,125,59,70,9,39,136,11,44,96,45,119,46,75,47,14,130,77,19,138,20,21,57,132,133,25,61,60,26,118,105,141,28,85,86],mps_free:[1,119,13,126,112,37,125,115,19,11,138,43,109,55,96,62],align:[63,87,61,2,92,29,95,30,97,99,101,82,104,116,107,108,109,125,48,35,93,132,112,8,115,39,40,11,43,12,45,120,13,14,123,41,77,19,66,81,55,56,126,79,129,44,28,26,84,137,138,141,37,85,62],synergi:77,inherit_class:54,ten:[71,88,21,104,91],qualifi:[97,25],rate:[47,8,97,25,100,101,104,105,12,96,141],pressur:106,design:[1,87,91,29,88,73,30,97,130,134,103,93,3,114,107,65,32,5,68,66,67,34,35,69,47,7,36,8,76,80,9,72,136,39,10,40,11,42,117,12,96,45,74,46,50,75,41,48,49,15,16,51,52,77,18,123,124,54,81,56,116,57,2,129,24,70,25,61,125,135,78,121,118,84,137,27,141,140,28,85,62],mps_arena_class_vm:[44,61,45],cursor:[40,141],referencess:35,sub:[63,29,7,103,20,54,92],sun:[47,25],sum:[88,120,93,112,96,133,101,138,109,55,45],brief:40,overload:105,mps_key_ams_support_ambigu:44,version:[0,93,79,3,4,107,65,5,109,66,34,35,69,36,112,8,80,72,115,40,41,43,132,45,119,46,120,13,11,130,52,77,123,138,20,21,55,126,128,105,70,25,61,125,26,84,64,140,37,85],intersect:23,mustn:[32,120],themselv:[46,35,57,29,52,114,101,39,90,32,54,135,66],berkelei:[47,59],dylan_copi:12,client_is_wait:45,behaviour:[125,30,79,102,103,21,107,54,48,35,69,70,8,39,49,74,14,130,52,77,80,56,135,84],shouldn:[67,74,57,69,134,40,61],solari:[34,6,78,72,132],mmsrc:[39,78,23],magnitud:[102,96,97,105],deprec:[29,79,64,4,65,109,21,112,37,115,11,43,45,119,120,13,20,125,126,135,84,138,140,85],heurist:[94,91,25,108],suddenli:21,hexadecim:[34,21,3,76],proceed:47,harlequin:[35,15,25,114,20,139,85],rightmost:29,coverag:[20,130,72,29],map_fix:78,minor:[0,60,80],flat:[40,25],mellon:47,flag:[35,90,24,121,39,9,78,118,107,80,81,45,141],reservoirensureful:63,stick:97,known:[63,1,89,90,91,92,93,88,94,95,30,97,98,99,87,101,102,103,104,3,106,108,54,35,7,112,8,72,110,9,41,12,96,46,75,116,16,52,79,124,66,100,56,128,59,24,105,133,82,25,125,135,27,140,61],stream_fput:50,outdent:20,valuabl:139,caveat:78,useabl:8,splaysplai:103,awlreclaim:[12,141],tracereclaim:12,cours:[87,23,24,8,61,125,49,117,55,45],goal:[73,57,69,72,136],divid:[87,88,89,91,92,29,96,28,101,104,105,66,93,9,39,49,16,80,24,133,134,61],rather:[87,88,90,91,29,94,97,98,99,103,65,125,67,35,69,112,8,39,74,46,14,79,21,81,56,25,134,26,61],nwper96:47,divis:[91,92,47,25,101,105,85],mps_fmt_create_auto_head:55,resourc:[0,88,93,94,96,99,100,104,64,116,107,32,6,54,112,49,45,74,46,14,41,16,52,66,55,57,24,135,85],mps_cached_count:19,mps_fmt_copy_t:55,reflect:[74,141,47,107,92],okai:[35,57,130,72,42,32,66,81,56],"short":[67,35,29,71,24,123,97,102,103,105,19,40,108,20,66,116,106],ambigu:[89,91,93,96,82,105,106,107,108,125,67,35,8,115,39,40,41,42,43,12,45,120,47,11,37,66,57,24,28,135,118,84,86,61,62],caus:[88,92,94,95,30,2,99,102,103,104,105,106,107,108,32,67,35,59,112,8,9,39,40,41,96,45,74,46,75,47,14,50,16,51,124,78,19,20,56,119,7,24,131,135,26,118,137,138,61,86],scanstat:[35,57,42,66,28,118,141],chiefli:87,postfin:57,target_check_deep:10,root_o:120,reachabl:[87,88,91,92,93,96,97,99,101,82,104,105,106,108,37,115,9,11,43,45,46,120,13,47,130,41,16,125,116,57,25,135,84,61],scientist:25,kistruck:[50,24,15,130,139,12],typedef:[30,79,103,104,27,2,32,65,125,69,8,114,41,44,74,49,11,19,20,54,55,128,58,28,61,85],inward:24,allocframestruct:7,stephen:[139,47],might:[87,88,61,91,29,94,95,30,99,28,101,102,103,90,105,106,107,108,32,65,54,67,68,35,113,7,71,9,39,40,11,117,119,44,96,45,74,46,120,50,14,123,15,52,77,78,19,20,21,55,56,128,58,23,79,66,24,49,133,12,125,135,26,84,140,41,85,62],alter:[69,64,85],wouldn:[9,16,28,41],"0x1003f9b98":26,"return":[0,63,91,29,88,30,121,99,103,104,64,4,107,32,65,78,109,54,48,44,93,7,70,71,8,39,115,9,10,40,11,43,119,12,96,45,74,46,120,75,13,68,14,41,16,51,52,128,113,18,19,138,20,21,55,1,126,116,57,58,79,66,24,49,133,61,125,112,135,26,131,84,129,105,141,140,37,106],framework:[67,34,47,7,72,25],bigger:[71,91,55,29,141],redecid:24,refresh:[103,90,105],compris:[63,29,70,8,106,80,73,141],ceas:107,mps_peak_t:24,truncat:74,weight:[90,29,47,101,9,106,92],linkag:[69,85],expect:[87,29,97,103,108,32,67,35,69,93,36,71,39,116,117,73,45,74,46,120,75,130,51,52,131,19,66,55,56,57,58,23,24,70,25,134,112,26,118,137,141,61,123],horribl:134,mps_stack_scan_ambig:[125,120,61,106],errror:120,"0x00000001003f9c90":26,"000000019ef60010":123,spanstruct:20,isreset:107,benjamin:[46,139,47],uncommit:[35,45],advanc:[95,34,127,7,47,46,24,41,16,25,39,11,130,141,92],differ:[1,89,92,29,96,99,101,102,104,27,107,32,5,6,80,67,35,59,71,114,39,40,41,12,45,74,46,47,14,123,15,16,51,77,122,19,138,20,66,55,128,58,7,79,24,105,133,112,26,84,3,61,85,62],isymtab:61,teach:25,thread:[1,91,92,93,96,97,101,103,104,106,107,54,67,34,69,7,70,8,72,40,41,45,46,120,75,13,47,15,52,19,66,55,56,127,128,125,26,118,140,61,85,86],threadscan:118,exponenti:87,perhap:[67,69,29,14,96,26,24,53,41,124,73,45],awldependentobject:141,entry_string_append:26,notifi:[57,107],feel:[77,61],dink:141,feet:45,mps_message_typ:[0,32],least:[0,88,91,29,95,96,79,101,103,104,105,108,21,48,35,93,8,39,40,116,12,45,46,77,18,19,20,80,126,128,58,24,125,84,61,141],stdlib:46,blank:20,fanci:77,vmstruct:[78,18],decoupl:85,script:[6,3,25],gpf:87,reentrant:[52,56],stori:[8,61],reentranc:75,store:[0,63,89,90,91,92,29,88,94,30,97,130,99,100,101,102,103,104,105,106,108,32,66,67,48,35,93,7,70,8,80,9,40,41,12,96,45,46,120,47,68,121,50,16,52,77,18,19,54,55,1,126,57,79,24,133,25,134,125,135,118,84,141,140,61,62],option:[35,7,65,24,8,116,80,79,61,77,39,138,105,43,20,21,109,44,30,45],checklist:69,aver:[121,114,77,103,65,80,12],kind:[0,88,91,94,95,96,79,101,105,108,40,45,14,77,80,24,25,26,84,61,85,62],doubli:[90,11,101,104,27,41,105,125,86],whenev:[35,57,69,7,29,36,94,15,103,25,101,9,10,107,141,66,120,61,128],remot:[37,115,106,11,43,62],remov:[0,90,79,103,27,106,108,32,65,67,35,8,9,39,116,117,44,118,120,15,75,76,50,52,77,78,20,55,57,24,25,12,84,105,61],dant:47,ringstruct:[57,30,52,114,27,32,66],architect:139,stale:[1,128,91,8,108,45,41,42,56,86],cleaner:[87,50,16],"0b00":40,grarup:47,overran:26,maximum_s:[112,109],dedic:[140,7,25],entireti:35,arenacreatevm:21,table_delet:41,violat:[87,92,14,96,135,99,101,103,105,106,108,66,85],splai:[34,103,72,77],exec:[74,73,123],unsur:[82,93],reach:[0,88,90,91,24,96,15,16,103,9,106,108,137,66,81,12,41,56,141],ringinit:[27,114],poolclassmvstruct:20,splat:[11,2,135,101,113,39,105,41],destruct:[46,7,30,72,53,116],mpscawl:11,sv_onstack:81,memorandum:47,cdr:[26,61,84],penalti:106,tag_mask:120,poolisvalid:75,iec:[79,49,91,47,25],hit:[67,97,23,96,15,100,39,26,106,108,140,92],btfindlong:29,longest:[66,85],him:46,statist:[35,58,50,40,21,45],"0x0000000100068050":26,wrote:[14,49],art:[96,25],dump:[74,114,77,3,80,118],invis:[77,11],"00000001078c85b8":21,mutabl:[75,70,24,96,99,107],arg:[30,4,107,2,65,109,125,48,112,37,115,39,41,43,44,45,119,13,11,54,55,126,57,28,138,61,141],ari:47,arm:92,barn:[139,47],bufferfinishmethod:107,lastrembembereds:141,nailed:30,unixi:69,various:37,mpsevent:21,induc:25,sole:102,awl_pool:[115,11],succeed:[66,14,30,61],rarer:90,solv:[46,47,24,96,9,105,41,61],mps_ld_add:[128,41],classnam:54,"1003ff000":21,satisfi:[119,88,90,93,29,112,24,133,130,103,55,125,39,105,108,117,100,141,61,62],context:[135,57,91,93,70,85,51,25,52,9,3,72,61,118,105,125,81,55,56,141],songworm:47,sweep:[34,58,47,29,2,92,14,91,97,39,25,9,105,116,95,33,43,141,28,96,62],arbitrarili:[103,19,107,61],mistak:[20,125,26,19,93],topla:47,java:[87,46,47,88,16,25,100,101,135,105,106,108],due:[1,67,35,91,23,88,94,24,96,116,25,100,74,112,135,105,106,108,125,12],clocks_per_sec:49,dup:80,strategi:[67,48,57,75,93,47,70,24,72,77,9,105,91,12],"0x00000001003f9a80":26,demand:[36,134,106,108],henriksson:47,batch:25,ramp_rel:20,behavior:[46,91,47,24,16,25,105],rit:[12,107],rip:[69,25],rid:35,mps_key_chain:[37,2,4,41,43,44,61],minim:[67,74,29,47,102,24,96,7,25,117,77,104,19,54,61,85],shire:139,sqlite3:6,"000ae039733592f9":21,higher:[88,35,57,49,8,120,25,39,99,107,80,61],x86:[1,6,132,21,92],wherea:[91,96,64,102],segbufclass:[35,107],thereund:77,bartlett:[96,105,47,25],robust:[74,46,90,29,16,103,138,80,44],provabl:[90,97,61],amcscannail:26,stateless:[50,72],lower:[68,57,69,8,79,104,107,96,45],"0001d69e01000000":123,propos:[46,47,24,52,134,77,80],epcor:[69,29,36,77,18,12],table_:[128,61,41],baroqu:78,"0x00000001003fb148":26,relianc:79,mps_lib_assert_fail_instal:[14,49],theoret:[46,91,130],addrinfram:7,cierniak:47,tracefinish:[20,12],xcodeproj:6,overcompens:96,rossum:25,collect:[0,1,89,90,91,92,93,88,94,95,96,121,130,99,101,87,104,64,106,108,32,109,66,67,34,35,125,47,7,132,71,8,9,72,38,115,39,40,11,42,43,12,45,74,46,120,141,75,13,41,14,15,16,138,139,131,37,20,21,55,126,127,128,58,24,49,82,25,61,60,112,135,26,134,105,86,140,28,62],arthur:47,pithi:116,global:[105,106,108,6,80,69,70,8,40,116,46,120,75,41,52,66,56,127,24,26,54,139,61,85],understood:[57,106],unspecifi:[106,29],consciou:47,surpris:46,prot:[57,8,51,78,85,32,81,28,56],prop:103,block_on_client_with_timeout:45,undon:121,leftmost:[93,29],prod:85,proc:[47,36],lose:[68,90,7,88,94,111,114,105],segstruct:[20,30,15,35],reservoirinit:63,squeez:100,cutoff:131,digraph:89,artifici:[15,47],fledg:10,lone:[20,24],fast:[1,90,91,92,29,97,103,105,107,54,125,93,112,39,40,46,75,47,21,58,133,134,60,84,137,61],adjac:[63,46,90,91,92,88,133,18,19,83],arithmet:66,nepot:95,event_wd:80,shdepth:15,repeatedli:[88,112,97,77,105,28,45],uncontrol:[49,21],mrglinkseg:57,consist:[63,87,90,91,83,96,2,107,108,54,67,36,114,9,40,132,45,74,120,75,14,52,77,20,66,55,127,57,119,70,125,26,61,85,141],confusingli:[106,25],caller:[103,75,94,121,52,99,39,116,32,65,12,61,85],highlight:[125,47,41],btsize:[20,29],reg_scan:120,event_label:21,threadspac:69,kathryn:47,tracequantum:[26,12],nick:[139,47],nice:[24,130,107,77],btdestroi:29,users:21,meaning:[8,10,130,21,23],"001b":21,"001a":21,vigil:40,amsss:39,vice:[67,8,11,25,41,30],spanpool:20,mps_arena_unsafe_expose_remember_protect:45,edg:[87,89,24,104,105,95],gmake:6,cmpf:41,spector:139,"0x0000000100005e30":26,mps_args_:44,finaltest:60,mainstream:88,amcss:[130,6,80,66],whiteset:50,electron:[96,16,85,47],tracescansegr:26,relev:[87,88,89,90,91,92,29,96,97,99,100,101,102,103,104,105,106,108,32,69,93,120,50,16,78,57,24,61,85,141],mps_io_creat:[74,49],maxsiz:[20,103,48],rankbufclass:107,pleas:[1,59,14,16,79,136,26,20,6,140,125],hinder:[75,12],smaller:[35,91,23,2,92,24,97,133,77,105,108,138,66,62],memset:[49,66,26],mps_build_eg:132,fold:77,compareequ:[66,103],compat:[69,59,80,72,83,32,65,54,81,66,56],lockclaimglobalrecurs:70,compar:[46,91,47,29,49,8,7,103,25,100,9,18,106,66,56,92],mainlin:85,segsplitmethod:30,formatdestroi:75,chose:104,mps_args_non:[65,125,44,61,41],youngest:[87,68],"0x0000000100067ca1":26,survivor:[35,58,37],traceflip:12,larger:[88,90,91,92,29,95,97,104,105,106,71,39,40,45,46,16,18,19,55,128,58,24,133,25,112,61],typic:[87,88,89,90,91,92,29,94,96,97,99,101,102,103,104,64,106,108,32,54,67,93,59,132,112,8,80,9,11,45,46,120,75,14,116,16,78,19,20,21,55,57,79,24,49,133,82,25,125,118,105,61,128],kurtz:25,poolframeselectmethod:7,forbid:[15,51,123],appli:[96,99,101,103,105,107,32,67,69,59,40,116,12,120,51,77,19,20,125,57,61,141],app:6,apt:6,mps_frame_class_t:7,api:[52,118],duck:25,fee:[20,59],from:[0,1,2,3,6,59,8,9,10,11,12,13,15,16,18,19,20,21,23,24,25,27,28,29,30,32,35,36,37,39,40,41,42,43,45,46,47,49,50,52,53,54,55,56,57,60,61,62,63,64,65,66,67,68,69,71,72,73,74,75,77,78,79,80,81,82,84,85,87,88,89,90,91,92,93,94,95,96,97,130,99,101,102,103,104,105,106,107,108,109,112,113,115,116,118,119,120,121,124,125,126,128,132,133,134,135,131,137,138,140,141],frob:[27,85],bufferreserv:[75,107],usr:6,inet:74,sort:[0,89,92,96,105,106,5,80,67,35,114,46,128,66,55,57,24,21,3,28,85,141],clever:[24,39,50,23,77],freetre:103,tag_data:77,messagetyp:[32,57],mps_fmt_create_:55,rare:[87,69,93,91,14,8,97,125,39,104,3,19,107,108,20,105,61],mps_pf_:[85,132],augment:[32,94],stoutamir:139,annot:[75,72,25,40,80,85],annoi:20,plinth:[0,34,66,14,49,80,79,74,108,6,73,21,86],endian:123,tracescanseg:26,proof:[14,39],"0x00000001003f9ae0":26,tag:[91,92,93,94,99,101,103,104,105,106,108,69,72,10,40,11,46,120,50,77,79,125,55,57,82,25,61,26,84,41,85,86],tab:20,serial:[74,69,47,49,8,123,107,66,141],minlength:29,six:[48,47,132,103,106,6],"0x10012a5a0":26,brian:47,sig:[75,47,30,52,114,137,10,3,32,65,54,81,28,56,141],memoiz:[96,91,85],instead:[125,90,91,29,97,79,101,103,104,105,106,32,65,109,54,67,7,11,8,9,39,10,40,14,43,73,45,119,46,50,13,49,41,121,77,19,21,81,117,56,57,66,24,25,26,84,85],msdn:85,"1078c85b8":21,hazard:57,attent:46,mps_arena_releas:[82,26,45],light:46,chapman:47,freebsd:[1,132,26,6,140,85],reg_root:[120,61],elif:85,ouput:45,minnow:12,whilst:[35,57,103,116,12,141],poolclassmv:75,newsgroup:52,poolclassmf:75,bye:0,uninitialis:[130,108],crash:[14,80,16,135,45],nextnod:27,deathtim:24,awlsegalloc:141,arenadestroi:[121,57,75,130],successor:103,edit:[20,8,36],tran:[57,69,8,114,134,3],trap:[47,7,96,116,39,107,108,125],objreturn:141,attrfre:66,our:[74,57,69,24,8,16,79,123,107,41,32,75,21,81,12,66,56,62],mps_arena_collect:[37,26,45,108],out:[1,88,61,91,29,94,95,30,97,130,99,100,102,103,90,64,116,108,32,134,66,67,48,35,93,59,8,80,104,39,40,11,42,96,45,74,46,50,14,15,16,52,77,128,19,53,20,21,81,55,56,57,58,23,79,2,24,25,28,125,135,26,84,105,41,85,141],locusinit:24,categori:[35,75,21,106,66,80,86],stroustrup:[46,25],iam4cc:132,mrgseg:57,make_symbol:[125,41],rampramp:20,powerpc:[6,99,132],york:47,mps_fmt_create_a:[61,55,41],mps_mortal:58,promptli:[0,88,130,16,9,106,125],transfer:[74,96,97,105,108],popfram:7,isbn:47,traceband:12,proflig:57,port_clos:41,echo:21,btcreat:29,unknown:[0,1,48,112,14,101],capac:[0,46,35,58,71,37,43,61,96],inner:[91,29],shell:21,"__del__":25,startup:60,juli:47,transistor:105,lockreleaseglob:70,diminish:71,diag_decl:50,tr99:47,holland:47,tr94:47,emac:[0,87,25],tractp:63,"0x00007fff91aeed46":[21,26],cohen:47,linker:105,disjoint:24,job001989:130,diverg:35,rout:[74,72],contraven:54,"0x7fff5fbff7d0":26,which:[0,3,6,7,8,9,10,12,14,16,18,19,20,21,23,24,25,26,27,28,29,30,32,35,36,39,40,41,42,44,45,46,47,68,49,50,51,52,53,54,55,56,57,58,59,61,62,63,64,65,66,67,48,69,70,72,73,74,75,77,78,79,80,81,84,85,87,88,89,90,91,92,93,94,95,96,97,130,99,100,101,102,103,104,105,106,107,108,110,112,113,114,116,117,118,119,120,121,123,124,125,126,128,129,132,133,134,135,131,137,140,141],r_o:140,divers:50,combat:11,who:[0,74,46,14,52,25],mpslib:[49,6,73],patchi:106,intern_str:41,nostop:26,judici:[46,103],why:[0,29,125,35,69,72,39,10,49,46,50,14,15,130,52,20,66,57,58,24,134,135,26,41,62],make_port:41,old_symtab_root:61,dens:29,"_io":[79,99],lockclaimrecurs:70,mpsacl:45,determin:[0,87,90,91,93,88,30,97,99,100,101,102,103,104,105,106,107,108,32,5,134,80,67,35,69,113,7,36,8,9,72,39,40,41,42,117,12,45,119,46,120,11,51,52,77,128,53,20,66,55,56,116,57,24,82,25,61,125,135,84,138,141,28,85,62],xavier:47,arenacheck:8,parentclassnam:54,overflow:[20,39,15,46],untermin:65,locat:[0,88,89,91,92,29,94,96,97,99,101,103,64,106,107,108,66,34,35,93,70,112,8,72,9,11,45,119,120,14,41,16,77,128,19,53,141,54,55,127,57,58,79,24,49,133,61,125,135,121,84,105,86,140,28,62],local:[88,90,91,92,93,95,96,97,99,102,103,104,105,106,6,125,70,9,39,10,40,74,46,120,47,49,50,16,79,54,55,24,133,84,61,85],contribut:[67,139,23,52],approv:59,make_str:[26,41],succe:[0,46,35,8,15,130,77,56,125,81,12,45],mps_arg_:[119,98,65,125,44,61,45],unstructur:13,caudil:47,sus8gc:132,partit:[35,47,95,8,72,134,103,106,12],view:[1,67,75,92,93,70,24,8,99,88,77],modulo:128,disastr:32,modula:[87,16,25],knowledg:[112,133,50,16,52,105,54,61],writefa:123,writefb:123,writefc:123,veljko:47,writefx:123,writefu:123,writefw:123,writefp:123,modulu:29,mps_os_fr:132,closer:133,entranc:27,overlarg:19,favor:46,entrant:[14,103,55,106],crude:94,amen:66,job:[74,46,37,16,69],entir:[29,96,99,103,27,116,108,35,7,71,9,40,11,45,46,50,16,80,56,57,24,82,25,134,105,141],amer:47,swift:91,barrett:[139,47],mps_pool_creat:[119,13,112,37,115,4,11,138,43,109,126],april:[47,107],detlef:47,grain:[87,35,75,95,8,15,134,101,39,30,28,141],committe:25,mps_fmt_isfwd_t:[55,99,61],mps_key_awl_find_depend:[41,44,11],mps_root_create_t:[120,61,41],arriv:101,arena_high:138,walk:[77,55,116],respect:[67,57,69,92,29,70,14,30,104,52,25,61,39,93,105,24,103,66,8,128],seligmann:47,platform:[1,87,29,95,97,79,101,21,106,108,6,109,80,34,69,36,112,117,73,76,49,52,18,20,66,56,126,127,132,25,134,138,62,140,61,85,86],decent:62,compos:[20,133,47],compon:[67,46,59,36,8,52,25,78,18,106,20,6],ruleset:50,epdldebugpoolclassstruct:54,present:[67,87,70,49,131,50,16,104,84,105,116,41,32,130,66,12,61,85,62],vanilla:39,corrigendum:47,unsuit:9,talpin:[47,25,106],sanctifi:66,observ:[74,46,92,93,97,135,87],failstart:20,layer:[74,69,133,16,39,105],refr:57,customis:[49,85,47],shieldexpos:15,motiv:[18,93,25],attrfmt:[66,116],lightweight:[72,7],r2000:132,protspong:85,foreign:[88,62,13,56,108],cross:[67,91,141],member:[90,69,132,24,8,130,25,103,104,79,114,84,91,66,139],largest:[93,132,24,103,101,39,19],difficult:[46,90,93,88,96,135,25,9,26,114,107],leaf_pool:41,heapsort:100,wordroundup:66,mutual:[70,47,107,62],retriv:130,student:25,collat:[50,130],firstli:[8,96,80,40,25],english:[20,91,3,58],obtain:[0,35,91,59,14,96,133,25,134,102,105,32,20,66,45],tcp:[74,80],metrowerk:[6,85,132],amcwhiten:35,heavili:46,simultan:[1,46,58,24,108,130,41,91,141],"00000001003fe000":21,rapid:[103,47,25,117],elsevi:47,alloct:77,hall:47,other:[0,5,6,7,8,9,10,11,12,14,16,18,19,20,21,23,24,25,26,29,30,35,36,37,39,40,41,43,45,46,50,51,52,54,55,56,57,58,59,61,62,1,64,66,67,48,69,70,71,72,75,76,77,78,79,80,81,82,84,85,87,88,89,90,91,92,93,94,95,96,97,99,102,103,104,105,106,107,108,112,113,114,115,116,118,119,120,130,123,124,125,126,128,133,134,135,137,138,140,141],nickb:12,"0x00000001003fb0a0":26,jython:25,poolfreep:20,assert:[0,91,93,100,106,2,35,69,29,10,40,49,118,74,14,116,123,21,61,26,84,137,41,85,86],know:[1,87,89,91,29,94,30,130,79,100,102,103,107,108,66,67,35,9,39,40,44,45,46,120,14,50,16,77,19,54,55,56,23,24,12,26,118,84,141,61,62],press:47,redesign:[80,25],lockclaim:70,ahem:20,incred:[123,114],safest:84,instat:15,unord:57,subsystem:[74,34,50,72,47],loseg:28,exceed:[66,14,8,19],growth:24,"export":69,superclass:[54,77,30,28,107],smoothli:[58,61],mps_class:55,subramanian:47,amcgen:35,leaf:[34,55,97,13,93,88,71,84,40,102,105,4,107,41,33,28,62],lead:[90,58,92,93,94,133,96,97,104,26,105,138],leak:[0,46,47,96,97,16,25,87,105,19,32],leah:139,leav:[46,35,90,7,29,88,24,39,77,9,105,40,49,65,45,92],mps_ld_isstal:[97,128,41],leader:20,weslei:47,investig:[87,24,43,114,46],"11a":103,"enum":[74,20,57,69,65],lostruct:28,obei:[61,106],ssw3i6mv:85,after:[0,88,90,91,92,128,30,2,103,106,107,108,32,6,54,67,35,113,36,71,8,9,114,115,39,40,41,44,96,45,74,46,120,75,14,130,51,52,77,78,19,20,21,55,57,24,49,70,133,82,25,12,125,135,26,131,118,84,140,61,85,62],mps_message_gc_live_s:[130,58],toolchain:[6,132],column:[20,21,80,107,132],btre:29,datagram:74,constructor:[46,90,91,93,25,61],disabl:[0,7,8,50,40,32],own:[63,1,91,30,130,102,104,27,106,107,6,134,54,67,70,8,114,39,49,45,74,46,120,14,41,16,52,77,123,20,66,81,133,25,28,125,105,61],domain:[46,25],automat:[1,87,90,91,93,106,96,2,130,99,100,101,64,4,107,108,33,6,109,34,35,112,37,9,38,115,39,41,43,45,119,46,120,13,47,14,11,16,77,131,19,138,125,81,55,126,116,58,79,24,25,61,113,84,105,141,140,28,62],warranti:[20,59],mps_class_mvff:[48,44,138],van:[114,25],val:[65,10,44],lv2:69,indira:47,unreason:[130,75],appl:[21,26,47,25,100],lockreleaseglobalrecurs:70,"var":[54,114,85,62],reservoirdeposit:63,unwrap:[101,82,106],splaynodedescribemethod:103,made:[63,90,92,29,99,100,103,105,107,54,35,93,70,8,39,40,41,12,45,46,14,116,52,77,128,21,57,23,24,36,25,125,139,85],ams_index:39,whether:[0,87,91,29,88,94,30,97,99,103,106,107,108,32,66,67,48,35,69,59,132,8,80,9,114,39,40,41,42,12,45,46,120,116,121,52,51,77,53,20,54,55,56,128,7,125,118,84,138,141,61,62],o1alcc:132,troubl:[46,57,90],record:[0,88,90,91,29,97,101,105,107,110,67,35,93,8,40,45,49,21,81,56,128,25,118,140,28,141],below:[1,91,29,130,103,116,107,32,6,21,35,70,71,8,72,9,41,45,46,120,14,11,16,51,77,54,57,58,24,132,133,28,125,135,26,84,61,85,141],supplant:25,meaningless:39,multic:[96,114],sptab:61,resunimpl:[66,51],zvi:47,buckets_skip:41,percent:24,book:[68,139,16],bool:[63,35,57,7,29,66,8,80,51,114,52,103,10,107,42,65,54,30,141],sick:47,siginvalid:[8,114],junk:[107,141],pooldestroi:[75,24,12,116],june:47,ismut:107,experienc:46,scientif:25,reliabl:[1,46,120,128,119,25,67,9,26,85,107,41,125,61,45],emerg:[35,8,72,135,40,41,20],auxiliari:[106,99,53,62],mps_collect:45,invari:[35,57,99,14,30,121,25,101,104,105,72,53,116,141],emeri:47},objtypes:{"0":"std:option","1":"std:envvar","2":"c:function","3":"c:macro","4":"c:type"},titles:["12. Messages","1. Overview of the Memory Pool System","18. Debugging pools","3. Transliterating the alphabet into hexadecimal","5. AMCZ (Automatic Mostly-Copying Zero-rank)","47. Software versions","2. Building the Memory Pool System","1. Allocation frame protocol","2. Arena","3. Recycling techniques","6. Checking","7. AWL (Automatic Weak Linked)","44. Tracer","8. LO (Leaf Object)","3. Error handing","38. Shield","1. Overview","<no title>","48. Virtual mapping","15. Segregated allocation caches","4. C Style – formatting","19. Telemetry","Memory Management Glossary","36. The generic scanner","16. MPS Configuration","4. Memory management in various languages","4. Debugging with the Memory Pool System","6. Ring data structure","24. LO pool class","4. Bit tables","37. Segment data structure","Memory Management Glossary","17. Client message protocol","Pool reference","Memory Pool System","21. AMC pool class","46. Library version mechanism","4. AMC (Automatic Mostly-Copying)","Introduction to memory management","22. AMS pool class","2. The critical path through the MPS","6. Advanced topics","11. The generic fix function","6. AMS (Automatic Mark and Sweep)","2. Keyword arguments","4. Arenas","5. Frequently Asked Questions","Bibliography","27. MVFF pool class","21. Plinth","9. Diagnostic feedback","28. The protection module","33. POSIX thread extensions","35. Root manager","32. Protocol inheritance","7. Object formats","30. Linux implementation of protection module","26. MRG pool class","11. Garbage collection","Memory Pool System Kit Open Source License","Tests","3. Garbage collecting a language with the Memory Pool System","1. Choosing a pool class","34. The low-memory reservoir","17. Allocation frames","5. Keyword arguments in the MPS","45. General MPS types","8. Collection framework","40. Stack scanner for Digital Unix on Alpha","12. C interface design","15. The lock module","5. Tuning the Memory Pool System for performance","Old design","14. Library interface","13. I/O subsystem","43. Thread safety in the MPS","Design","19. Debugging features for client objects","51. VM for Solaris","1. Interface conventions","41. Telemetry","31. SunOS 4 protection module","Memory Management Glossary: U","Memory Management Glossary: Q","8. Scanning","1. MPS Configuration","Reference","Memory Management Glossary: G","Memory Management Glossary: F","Memory Management Glossary: E","Memory Management Glossary: D","Memory Management Glossary: C","Memory Management Glossary: B","Memory Management Glossary: A","Memory Management Glossary: O","Memory Management Glossary: N","Memory Management Glossary: M","Memory Management Glossary: L","Memory Management Glossary: K","Memory Management Glossary: I","Memory Management Glossary: H","Memory Management Glossary: W","Memory Management Glossary: V","39. Splay trees","Memory Management Glossary: T","Memory Management Glossary: S","Memory Management Glossary: R","5. Allocation buffers and allocation points","Memory Management Glossary: P","10. MV (Manual Variable)","Memory Management Glossary: Z","MV pool class","12. MVT (Manual Variable Temporal)","20. Weak references","7. Signatures in the MPS","13. SNC (Stack No Checking)","7. Pool class interface","29. ANSI implementation of protection module","42. Thread Manager","5. Pools","10. Roots","10. Finalization","25. MFS pool class","52. The WriteF function","50. VM for Digital Unix","6. Allocation","9. MFS (Manual Fixed Small)","Guide","14. Location dependency","49. ANSI fake VM","18. GC messages","16. Allocation patterns","22. Platforms","2. Allocation techniques","3. Virtual Memory Arena","13. Finalization","Contact us","20. Pool and pool class mechanisms","11. MVFF (Manual Variable First Fit)","Acknowledgements","9. Threads","23. AWL pool class"],objnames:{"0":["std","option","option"],"1":["std","envvar","environment variable"],"2":["c","function","C function"],"3":["c","macro","C macro"],"4":["c","type","C type"]},filenames:["topic/message","guide/overview","topic/debugging","design/guide.hex.trans","pool/amcz","design/version","guide/build","design/alloc-frame","design/arena","mmref/recycle","design/check","pool/awl","design/trace","pool/lo","topic/error","design/shield","mmref/begin","glossary/_Sidebar","design/vm","topic/cache","design/guide.impl.c.format","topic/telemetry","glossary/index","design/scan","design/locus","mmref/lang","guide/debug","design/ring","design/poollo","design/bt","design/seg","glossary/home","design/message","pool/index","index","design/poolamc","design/version-library","pool/amc","mmref/index","design/poolams","design/critical-path","guide/advanced","design/fix","pool/ams","topic/keyword","topic/arena","mmref/faq","mmref/bib","design/poolmvff","topic/plinth","design/diag","design/prot","design/pthreadext","design/root","design/protocol","topic/format","design/protli","design/poolmrg","topic/collection","copyright","design/tests","guide/lang","pool/intro","design/reservoir","topic/frame","design/keyword-arguments","design/type","design/collection","design/sso1al","design/interface-c","design/lock","guide/perf","design/old","design/lib","design/io","design/thread-safety","design/index","design/object-debug","design/vmso","topic/interface","design/telemetry","design/protsu","glossary/u","glossary/q","topic/scanning","design/config","topic/index","glossary/g","glossary/f","glossary/e","glossary/d","glossary/c","glossary/b","glossary/a","glossary/o","glossary/n","glossary/m","glossary/l","glossary/k","glossary/i","glossary/h","glossary/w","glossary/v","design/splay","glossary/t","glossary/s","glossary/r","design/buffer","glossary/p","pool/mv","glossary/z","design/poolmv","pool/mvt","topic/weak","design/sig","pool/snc","design/class-interface","design/protan","design/thread-manager","topic/pool","topic/root","design/finalize","design/poolmfs","design/writef","design/vmo1","topic/allocation","pool/mfs","guide/index","topic/location","design/vman","design/message-gc","topic/pattern","topic/platform","mmref/alloc","design/arenavm","topic/finalization","contact","design/pool","pool/mvff","mmref/credit","topic/thread","design/poolawl"]})
\ No newline at end of file
diff --git a/mps/manual/html/topic/allocation.html b/mps/manual/html/topic/allocation.html
index d3bcee08cac..b5b4f1649e4 100644
--- a/mps/manual/html/topic/allocation.html
+++ b/mps/manual/html/topic/allocation.html
@@ -255,10 +255,10 @@ 
                                                                                                        Navigation
                                                                                                        
 
 
                                                                                                        The usual implementation of the allocation point protocol in C
 is thus:
                                                                                                        
-
                                                                                                        mps_addr_t p;
-obj_t obj;
+
                                                                                                        mps_addr_t p;
+obj_t obj;
 do {
-    mps_res_t res = mps_reserve(&p, ap, size);
+    mps_res_t res = mps_reserve(&p, ap, size);
     if (res != MPS_RES_OK) /* handle the error */;
     /* p is now an ambiguous reference to the reserved block */
     obj = p;
@@ -362,18 +362,18 @@ 
                                                                                                        Navigation
                                                                                                        
 
                                                                                                        
 
                                                                                                        6.4. Example: allocating a symbol
                                                                                                        
 
                                                                                                        typedef struct symbol_s {
-    type_t type;                  /* TYPE_SYMBOL */
+    type_t type;                  /* TYPE_SYMBOL */
     size_t length;                /* length of symbol string (excl. NUL) */
     char string[1];               /* symbol string, NUL terminated */
-} symbol_s, *symbol_t;
+} symbol_s, *symbol_t;
 
-symbol_t make_symbol(size_t length, char string[])
+symbol_t make_symbol(size_t length, char string[])
 {
-    symbol_t symbol;
-    mps_addr_t addr;
+    symbol_t symbol;
+    mps_addr_t addr;
     size_t size = ALIGN(offsetof(symbol_s, string) + length+1);
     do {
-        mps_res_t res = mps_reserve(&addr, ap, size);
+        mps_res_t res = mps_reserve(&addr, ap, size);
         if (res != MPS_RES_OK) error("out of memory in make_symbol");
         symbol = addr;
         symbol->type = TYPE_SYMBOL;
@@ -438,21 +438,21 @@ 
                                                                                                        Navigation
                                                                                                        
 
                                                                                                        6.6. Example: inserting into a doubly linked list
                                                                                                        
 
                                                                                                        This example contains several mistakes. See the highlighted lines:
                                                                                                        
 
                                                                                                        typedef struct link_s {
-    type_t type;                       /* TYPE_LINK */
+    type_t type;                       /* TYPE_LINK */
     /* all three of these pointers are fixed: */
     struct link_s *prev;
     struct link_s *next;
-    obj_t obj;
-} link_s, *link_t;
+    obj_t obj;
+} link_s, *link_t;
 
 /* insert 'obj' into the doubly-linked list after 'head' */
-link_t insert_link(link_t head, obj_t obj)
+link_t insert_link(link_t head, obj_t obj)
 {
-    mps_addr_t p;
-    link_t link;
+    mps_addr_t p;
+    link_t link;
     size_t size = ALIGN(sizeof(link_s));
     do {
-        mps_res_t res = mps_reserve(&p, ap, size);
+        mps_res_t res = mps_reserve(&p, ap, size);
         if (res != MPS_RES_OK) error("out of memory");
         link = p;
         link->type = TYPE_LINK;
@@ -478,13 +478,13 @@ 
                                                                                                        Navigation
                                                                                                        
 scan method, so it must be initialized before the call to commit.
                                                                                                        • 
 
 
                                                                                                        A correct version of insert_link looks like this:
                                                                                                        
-
                                                                                                        link_t insert_link(link_t head, obj_t obj)
+
                                                                                                        link_t insert_link(link_t head, obj_t obj)
 {
-    mps_addr_t p;
-    link_t link;
+    mps_addr_t p;
+    link_t link;
     size_t size = ALIGN(sizeof(link_s));
     do {
-        mps_res_t res = mps_reserve(&p, ap, size);
+        mps_res_t res = mps_reserve(&p, ap, size);
         if (res != MPS_RES_OK) error("out of memory");
         link = p;
         link->type = TYPE_LINK;
@@ -598,9 +598,9 @@ 
                                                                                                        Navigation
                                                                                                        
 
                                                                                                        The type of the structure used to represent allocation
 points:
                                                                                                        
 
                                                                                                        typedef struct mps_ap_s {
-    mps_addr_t init;
-    mps_addr_t alloc;
-    mps_addr_t limit;
+    mps_addr_t init;
+    mps_addr_t alloc;
+    mps_addr_t limit;
     /* ... private fields ... */
 } mps_ap_s;
 
                                                                                                        
diff --git a/mps/manual/html/topic/arena.html b/mps/manual/html/topic/arena.html
index 129b3133dab..f887e06add6 100644
--- a/mps/manual/html/topic/arena.html
+++ b/mps/manual/html/topic/arena.html
@@ -212,9 +212,9 @@ 
                                                                                                        Navigation
                                                                                                        
 
                                                                                                        starting with version 1.112.
                                                                                                        
 
                                                                                                        When using mps_arena_create(), pass the size and base
 address like this:
                                                                                                        
-
                                                                                                        mps_res_t mps_arena_create(mps_arena_t *arena_o,
-                           mps_arena_class_t mps_arena_class_cl,
-                           size_t size, mps_addr_t base)
+
                                                                                                        mps_res_t mps_arena_create(mps_arena_t *arena_o,
+                           mps_arena_class_t mps_arena_class_cl,
+                           size_t size, mps_addr_t base)
 
                                                                                                        
 
                                                                                                        
 
                                                                                                        
@@ -303,8 +303,8 @@ 
                                                                                                        Navigation
                                                                                                        
 
                                                                                                        starting with version 1.112.
                                                                                                        
 
                                                                                                        When using mps_arena_create(), pass the size like
 this:
                                                                                                        
-
                                                                                                        mps_res_t mps_arena_create(mps_arena_t *arena_o,
-                           mps_arena_class_t arena_class_vm(),
+
                                                                                                        mps_res_t mps_arena_create(mps_arena_t *arena_o,
+                           mps_arena_class_t arena_class_vm(),
                            size_t size)
 
                                                                                                        
 
                                                                                                        
diff --git a/mps/manual/html/topic/cache.html b/mps/manual/html/topic/cache.html
index 950113af945..bf81292eb50 100644
--- a/mps/manual/html/topic/cache.html
+++ b/mps/manual/html/topic/cache.html
@@ -70,7 +70,7 @@ 
                                                                                                        Navigation
                                                                                                        
 number of relatively short-lived 8-byte objects, we might create a
 cache as follows:
                                                                                                        
 
                                                                                                        mps_sac_class_s classes[3] = {{8, 100, 10}, {128, 8, 1}};
-mps_sac_t sac;
+mps_sac_t sac;
 
 res = mps_sac_create(&sac, pool, sizeof classes / sizeof classes[0], classes);
 if (res != MPS_RES_OK)
@@ -83,8 +83,8 @@ 
                                                                                                        Navigation
                                                                                                        
 (using mps_sac_free() or MPS_SAC_FREE_FAST()) return
 the block to the appopriate free list for its size. For example:
                                                                                                        
 
                                                                                                        Foo *foo;
-mps_addr_t p;
-mps_res_t res;
+mps_addr_t p;
+mps_res_t res;
 
 res = mps_sac_alloc(&p, sac, sizeof *foo, false);
 if (res != MPS_RES_OK)
diff --git a/mps/manual/html/topic/collection.html b/mps/manual/html/topic/collection.html
index 202c1cfc462..0add97f6924 100644
--- a/mps/manual/html/topic/collection.html
+++ b/mps/manual/html/topic/collection.html
@@ -56,6 +56,12 @@ 
                                                                                                        Navigation
                                                                                                        
             
   
                                                                                                        
 
                                                                                                        11. Garbage collection
                                                                                                        
+
                                                                                                        The arena contains a garbage collector that
+coordinates the collection of garbage in all of its
+automatically managed
+pools. The collector efficiently traces references between
+roots and pools, and between objects in different pools. It is
+capable of collecting many automatically managed pools simultaneously.
                                                                                                        
 
                                                                                                        
 
                                                                                                        11.1. Generation chains
                                                                                                        
 
                                                                                                        A generation chain describes the structure of the
@@ -74,8 +80,8 @@ 
                                                                                                        Navigation
                                                                                                        
     { 2048, 0.4 },
 };
 
-mps_chain_t chain;
-mps_res_t res;
+mps_chain_t chain;
+mps_res_t res;
 res = mps_chain_create(&chain, arena,
                        sizeof(gen_params) / sizeof(gen_params[0]),
                        gen_params);
diff --git a/mps/manual/html/topic/debugging.html b/mps/manual/html/topic/debugging.html
index 536ec8cd2ac..9a061c7c8a8 100644
--- a/mps/manual/html/topic/debugging.html
+++ b/mps/manual/html/topic/debugging.html
@@ -115,8 +115,8 @@ 
                                                                                                        Navigation
                                                                                                        
    (void *)"postpost", 8,
    (void *)"freefree", 8,
 };
-mps_pool_t pool;
-mps_res_t res;
+mps_pool_t pool;
+mps_res_t res;
 MPS_ARGS_BEGIN(args) {
     MPS_ARGS_ADD(args, MPS_KEY_POOL_DEBUG_OPTIONS, &debug_options);
     MPS_ARGS_ADD(args, MPS_KEY_FORMAT, &fmt);
diff --git a/mps/manual/html/topic/error.html b/mps/manual/html/topic/error.html
index 552a9a09e61..f3f21ae658a 100644
--- a/mps/manual/html/topic/error.html
+++ b/mps/manual/html/topic/error.html
@@ -216,16 +216,27 @@ 
                                                                                                        3.1. Result codesDebugging with the Memory Pool System) without
 luck, get in touch.
                                                                                                        
-
                                                                                                        If you are running your MPS-enabled program from Emacs via the
-compile command, you will probably want to recognize MPS
-assertions automatically, by adding the following to your .emacs:
                                                                                                        
-
                                                                                                        (add-to-list 'compilation-error-regexp-alist
-             '("MPS ASSERTION FAILURE: .*\n\\(.*\\)\n\\([0-9]+\\)" 1 2))
-
                                                                                                        
-
                                                                                                        
+
                                                                                                        
+
                                                                                                        3.2.1. Assertion handling
                                                                                                        
+
                                                                                                        When the MPS detects an assertion failure, it calls the plinth
+function mps_lib_assert_fail(). Unless you have replaced the plinth, this behaves as follows:
                                                                                                        
+
                                                                                                          
+
                                                                                                        • In the cool variety, print the assertion message to
+standard error and terminate the program by calling abort().
                                                                                                          • 
+
                                                                                                        • In the hot and rash varieties, print the assertion
+message to standard error and do not terminate the program.
                                                                                                          • 
+
                                                                                                        
+
                                                                                                        You can change this behaviour by providing your own plinth, or using
+mps_lib_assert_fail_install().
                                                                                                        
+
                                                                                                        In many applications, users don’t want their program terminated when
+the MPS detects an error, no matter how severe. A lot of MPS
+assertions indicate that the program is going to crash very soon, but
+there still may be a chance for a user to get some useful results or
+save their work. This is why the default assertion handler only
+terminates in the cool variety.
                                                                                                        
 
                                                                                                        
 
                                                                                                        
-
                                                                                                        3.3. Common assertions and their causes
                                                                                                        
+
                                                                                                        3.2.2. Common assertions and their causes
                                                                                                        
 
                                                                                                        This section lists some commonly encountered assertions and suggests
 likely causes. If you encounter an assertion not listed here (or an
 assertion that is listed here but for which you discovered a different
@@ -276,34 +287,40 @@ 
                                                                                                        3.1. Result codesformatted object was updated in some way that has a race
 condition?
            • +
            -

            3.4. Varieties

            +

            3.3. Varieties

            The MPS has three behaviours with respect to internal checking and telemetry, which need to be selected at compile time, by defining one of the following preprocessor constants. If none is specified then CONFIG_VAR_HOT is the default.

            -
            +
            CONFIG_VAR_COOL

            The cool variety is intended for development and testing.

            -

            All functions check the consistency of their data structures and -may assert, including functions on the critical path.

            +

            All functions check the consistency of their data structures and may +assert, including functions on the critical path. +Furthermore, in the default ANSI Library the default assertion +handler will terminate the program. See +mps_lib_assert_fail_install().

            All events are sent to the telemetry stream, including events on the critical path.

            -
            +
            CONFIG_VAR_HOT

            The hot variety is intended for production and deployment.

            Some functions check the consistency of their data structures and -may assert, namely those not on the critical path.

            +may assert, namely those not on the critical path. However, +in the default ANSI Library, the default assertion handler will not +terminate the program. See mps_lib_assert_fail_install().

            Some events are sent to the telemetry stream, namely those not on the critical path.

            -
            +
            CONFIG_VAR_RASH

            The rash variety is intended for mature integrations, or for @@ -329,9 +346,12 @@

            Table Of Contents

            diff --git a/mps/manual/html/topic/finalization.html b/mps/manual/html/topic/finalization.html index 39588e3ffd2..c940d178e5a 100644 --- a/mps/manual/html/topic/finalization.html +++ b/mps/manual/html/topic/finalization.html @@ -62,7 +62,7 @@

            Navigation

            connection. When the block dies, the corresponding resource must be released. This procedure is known as finalization.

            A block requiring finalization must be registered by calling mps_finalize():

            -
            mps_addr_t ref = block_requiring_finalization;
+
            mps_addr_t ref = block_requiring_finalization;
 mps_finalize(arena, &ref);
 
            
 
            
diff --git a/mps/manual/html/topic/format.html b/mps/manual/html/topic/format.html
index a0130e3b6b3..d6ae60eb446 100644
--- a/mps/manual/html/topic/format.html
+++ b/mps/manual/html/topic/format.html
@@ -114,9 +114,9 @@ 
            Navigation
            
     obj_pad
 };
 
-mps_pool_t obj_pool;
-mps_fmt_t obj_fmt;
-mps_res_t res;
+mps_pool_t obj_pool;
+mps_fmt_t obj_fmt;
+mps_res_t res;
 
 res = mps_fmt_create_A(&obj_fmt, arena, &obj_fmt_s);
 if (res != MPS_RES_OK) error("Couldn't create obj format");
@@ -136,13 +136,13 @@ 
            Navigation
            
 
            The type of the structure used to create an object format
 of variant A.
            
 
            typedef struct mps_fmt_A_s {
-    mps_align_t     align;
-    mps_fmt_scan_t  scan;
-    mps_fmt_skip_t  skip;
-    mps_fmt_copy_t  copy;
-    mps_fmt_fwd_t   fwd;
-    mps_fmt_isfwd_t isfwd;
-    mps_fmt_pad_t   pad;
+    mps_align_t     align;
+    mps_fmt_scan_t  scan;
+    mps_fmt_skip_t  skip;
+    mps_fmt_copy_t  copy;
+    mps_fmt_fwd_t   fwd;
+    mps_fmt_isfwd_t isfwd;
+    mps_fmt_pad_t   pad;
 } mps_fmt_A_s;
 
            
 
            
@@ -193,14 +193,14 @@ 
            Navigation
            
 
            The type of the structure used to create an object format
 of variant B.
            
 
            typedef struct mps_fmt_B_s {
-    mps_align_t     align;
-    mps_fmt_scan_t  scan;
-    mps_fmt_skip_t  skip;
-    mps_fmt_copy_t  copy;
-    mps_fmt_fwd_t   fwd;
-    mps_fmt_isfwd_t isfwd;
-    mps_fmt_pad_t   pad;
-    mps_fmt_class_t mps_class;
+    mps_align_t     align;
+    mps_fmt_scan_t  scan;
+    mps_fmt_skip_t  skip;
+    mps_fmt_copy_t  copy;
+    mps_fmt_fwd_t   fwd;
+    mps_fmt_isfwd_t isfwd;
+    mps_fmt_pad_t   pad;
+    mps_fmt_class_t mps_class;
 } mps_fmt_B_s;
 
            
 
            
@@ -227,12 +227,12 @@ 
            Navigation
            
 
            The type of the structure used to create an object format
 of variant auto-header.
            
 
            typedef struct mps_fmt_auto_header_s {
-    mps_align_t     align;
-    mps_fmt_scan_t  scan;
-    mps_fmt_skip_t  skip;
-    mps_fmt_fwd_t   fwd;
-    mps_fmt_isfwd_t isfwd;
-    mps_fmt_pad_t   pad;
+    mps_align_t     align;
+    mps_fmt_scan_t  scan;
+    mps_fmt_skip_t  skip;
+    mps_fmt_fwd_t   fwd;
+    mps_fmt_isfwd_t isfwd;
+    mps_fmt_pad_t   pad;
     size_t          mps_headerSize;
 } mps_fmt_auto_header_s;
 
            
diff --git a/mps/manual/html/topic/index.html b/mps/manual/html/topic/index.html
index b39060a0a04..b58dccb4bf1 100644
--- a/mps/manual/html/topic/index.html
+++ b/mps/manual/html/topic/index.html
@@ -71,9 +71,12 @@ 
            Navigation
            
 
          • 2. Keyword arguments
            • 
 
          • 3. Error handing
 
            • 
 
          • 4. Arenas
            • @@ -152,7 +152,8 @@

            Navigation

            value io again.

            Note

            -

            In the ANSI I/O module, mpsioan.c, this calls fclose.

            +

            In the ANSI I/O module, mpsioan.c, this calls +fclose().

            @@ -168,7 +169,8 @@

            Navigation

            Returns MPS_RES_OK if successful.

            Note

            -

            In the ANSI I/O module, mpsioan.c, this calls fwrite.

            +

            In the ANSI I/O module, mpsioan.c, this calls +fwrite().

            @@ -190,7 +192,8 @@

            Navigation

            event data.

            Note

            -

            In the ANSI I/O module, mpsioan.c, this calls fflush.

            +

            In the ANSI I/O module, mpsioan.c, this calls +fflush().

            @@ -218,13 +221,13 @@

            Navigation

            instance, with getrusage():

            #include <sys/resource.h>
 
-mps_clock_t mps_clock(void) {
+mps_clock_t mps_clock(void) {
     struct rusage s;
     int res = getrusage(RUSAGE_SELF, &s);
     if (res != 0) {
         /* handle error */
     }
-    return ((mps_clock_t)s.ru_utime.tv_sec) * 1000000 + s.ru_utime.tv_usec;
+    return ((mps_clock_t)s.ru_utime.tv_sec) * 1000000 + s.ru_utime.tv_usec;
 }
            @@ -245,17 +248,41 @@

            Navigation

            void mps_lib_assert_fail(const char *message)
            -

            Report an assertion failure and abort.

            +

            Report an assertion failure.

            message is a NUL-terminated string describing the assertion failure.

            Note

            In the ANSI Library module, mpsliban.c, this reports the -failure using fprintf(stderr, "...%s...", message) and -terminates the program by calling abort.

            +failure using fprintf(stderr, "...%s...", message) and, in +the cool variety, terminates the program by +calling abort(). You can change this behaviour with +mps_lib_assert_fail_install(). For a discussion of the +default behaviour, see Assertion handling.

            +
            +
            +extern mps_lib_assert_fail_t mps_lib_assert_fail_install(mps_lib_assert_fail_t handler)
            +

            This function customises the behaviour of the default assertion handler +in the ANSI Library module. It is not otherwise required by the MPS +and you need not implement it if you are providing an alternative plinth.

            +

            If you’re using the ANSI Library module, you can use this function +to change the behaviour of the MPS when an assertion fails. For +example, you could terminate the program in the hot +variety too. (The MPS test programs do exactly that.)

            +

            handler is the assertion handler to install.

            +

            Returns the previously installed handler.

            +
            + +
            +
            +typedef void (*mps_lib_assert_fail_t)(const char *, unsigned, const char *)
            +

            The type of assertion handlers passed to and returned by +mps_lib_assert_fail_install().

            +
            +
            mps_lib_FILE
            @@ -276,11 +303,12 @@

            Navigation

            Return the character written if successful, or mps_lib_get_EOF() if not.

            This function is intended to have the same semantics as the -fputc function of the ANSI C Standard (ISO/IEC 9899:1990 §7.11.7.3).

            +fputc() function of the ANSI C Standard (ISO/IEC +9899:1990 §7.11.7.3).

            Note

            In the ANSI Library module, mpsliban.c, this is a simple -wrapper around fputc.

            +wrapper around fputc().

            @@ -291,13 +319,14 @@

            Navigation

            s is the NUL-terminated string.

            stream is the stream.

            This function is intended to have the same semantics as the -fputs function of the ANSI C Standard (ISO/IEC 9899:1990 §7.11.7.4).

            +fputs() function of the ANSI C Standard (ISO/IEC +9899:1990 §7.11.7.4).

            Return a non-negative integer if successful, or mps_lib_get_EOF() if not.

            Note

            In the ANSI Library module, mpsliban.c, this is a simple -wrapper around fputs.

            +wrapper around fputs().

            @@ -350,7 +379,7 @@

            Navigation

            int mps_lib_memcmp(const void *s1, const void *s2, size_t n)

            A plinth function similar to the standard C -function memcmp.

            +function memcmp().

            s1 and s2 point to blocks of memory to be compared.

            n is the size of the blocks.

            @@ -358,12 +387,12 @@

            Navigation

            zero, accordingly as the block pointed to by s1 is greater than, equal to, or less than the block pointed to by s2.

            This function is intended to have the same semantics as the -memcmp function of the ANSI C Standard (ISO/IEC +memcmp() function of the ANSI C Standard (ISO/IEC 9899:1990 §7.11.4.1).

            Note

            In the ANSI Library module, mpsliban.c, this is a simple -wrapper around memcmp.

            +wrapper around memcmp().

            @@ -371,20 +400,20 @@

            Navigation

            void *mps_lib_memcpy(void *dest, const void *source, size_t n)

            A plinth function similar to the standard C -function memcpy.

            +function memcpy().

            dest points to the destination.

            source points to the source.

            n is the number of bytes to copy from source to dest.

            Returns dest.

            This function is intended to have the same semantics as the -memcpy function of the ANSI C Standard (ISO/IEC +memcpy() function of the ANSI C Standard (ISO/IEC 9899:1990 §7.11.2.1).

            The MPS never passes overlapping blocks to mps_lib_memcpy().

            Note

            In the ANSI Library module, mpsliban.c, this is a simple -wrapper around memcpy.

            +wrapper around memcpy().

            @@ -392,18 +421,18 @@

            Navigation

            void *mps_lib_memset(void *s, int c, size_t n)

            A plinth function similar to the standard C -function memset.

            +function memset().

            s points to the block to fill with the byte c.

            c is the byte to fill with (when converted to unsigned char).

            n is the size of the block.

            Returns s.

            This function is intended to have the same semantics as the -memset function of the ANSI C Standard (ISO/IEC +memset() function of the ANSI C Standard (ISO/IEC 9899:1990 §7.11.6.1).

            Note

            In the ANSI Library module, mpsliban.c, this is a simple -wrapper around memset.

            +wrapper around memset().

            Note

            diff --git a/mps/manual/html/topic/root.html b/mps/manual/html/topic/root.html index 3b8534782a4..cfb1f324254 100644 --- a/mps/manual/html/topic/root.html +++ b/mps/manual/html/topic/root.html @@ -76,6 +76,7 @@

            Navigation

            no two roots may overlap (that is, each reference is fixed by at most one root). Roots may be:

              +
            1. in registers;
            2. on the program’s control stack;
            3. in the program’s static data;
            4. in heap not managed by the MPS (provided that you destroy @@ -124,7 +125,7 @@

              Navigation

            5. mps_root_create_table_masked() if the root consists of a table of tagged references;
            6. mps_root_create_reg() if the root consists of the -registers and control stack of a thread. See +registers and control stack of a thread. See Thread roots below.
            @@ -168,8 +169,8 @@

            Navigation

            the stack frame below any potential roots.

            For example, here’s the code from the toy Scheme interpreter that registers a thread root and then calls the program:

            -
            mps_thr_t thread;
-mps_root_t reg_root;
+
            mps_thr_t thread;
+mps_root_t reg_root;
 int exit_code;
 void *marker = &marker;
 
@@ -499,17 +500,17 @@ 
            Navigation
            
 /* Global symbol table. */
 size_t symtab_size;
 struct {
-    obj_t symbol;
-    obj_t value;
+    obj_t symbol;
+    obj_t value;
 } *symtab;
 
-mps_res_t res;
-mps_root_t root;
+mps_res_t res;
+mps_root_t root;
 res = mps_root_create_table_masked(&root, arena,
                                    mps_rank_exact(),
-                                   (mps_rm_t)0,
+                                   (mps_rm_t)0,
                                    symtab, symtab_size * 2,
-                                   (mps_word_t)TAG_MASK);
+                                   (mps_word_t)TAG_MASK);
 if (res != MPS_RES_OK) errror("can't create symtab root");
 
            
 
            
diff --git a/mps/manual/html/topic/scanning.html b/mps/manual/html/topic/scanning.html
index 104ad4b6a14..b704b13aa49 100644
--- a/mps/manual/html/topic/scanning.html
+++ b/mps/manual/html/topic/scanning.html
@@ -121,12 +121,12 @@ 
            Navigation
            
 might look like this:
            
 
            if (MPS_FIX1(ss, obj->ref)) {
     /* strip the tag */
-    mps_addr_t p = obj->ref & ~0x7;
-    mps_res_t res = MPS_FIX2(ss, &p);
+    mps_addr_t p = obj->ref & ~0x7;
+    mps_res_t res = MPS_FIX2(ss, &p);
     if (res != MPS_RES_OK) return res;
     /* restore the tag and update reference */
-    mps_word_t tag = obj->ref & 0x7;
-    obj->ref = (obj_t)((char *)p + tag);
+    mps_word_t tag = obj->ref & 0x7;
+    obj->ref = (obj_t)((char *)p + tag);
 }
 
            
 
            
@@ -154,7 +154,7 @@ 
            Navigation
            
 references to non-references, on how often genuine references turn out
 to be “of interest”, and what kind of code the compiler has
 generated. There is no substitute for measurement.
            
-
            See The critical path through the MPS.
            
+
            See design-critical-path.
            
 
            
 
            Note
            
 
            In one application with a high proportion of unboxed
@@ -244,11 +244,11 @@ 
            Navigation
            
 is not defined by the C standard. See Type punning.
            
 
            
 
            Here’s the Scheme scanner:
            
-
            static mps_res_t obj_scan(mps_ss_t ss, mps_addr_t base, mps_addr_t limit)
+
            static mps_res_t obj_scan(mps_ss_t ss, mps_addr_t base, mps_addr_t limit)
 {
     MPS_SCAN_BEGIN(ss) {
         while (base < limit) {
-            obj_t obj = base;
+            obj_t obj = base;
             switch (obj->type.type) {
                 case TYPE_PAIR:
                     FIX(obj->pair.car);
@@ -366,10 +366,10 @@ 
            Navigation
            
 data_scan. In order to ensure that the scan state is passed
 correctly to data_scan, the call must be wrapped in
 MPS_FIX_CALL().
            
-
            mps_res_t obj_scan(mps_ss_t ss, mps_addr_t base, mps_addr_t limit)
+
            mps_res_t obj_scan(mps_ss_t ss, mps_addr_t base, mps_addr_t limit)
 {
-    obj_t obj;
-    mps_res_t res;
+    obj_t obj;
+    mps_res_t res;
     MPS_SCAN_BEGIN(ss) {
         for (obj = base; obj < limit; obj++) {
             if (MPS_FIX12(ss, &obj->left) != MPS_RES_OK)
diff --git a/mps/manual/html/topic/weak.html b/mps/manual/html/topic/weak.html
index d00cd6d929b..14f63e3bef1 100644
--- a/mps/manual/html/topic/weak.html
+++ b/mps/manual/html/topic/weak.html
@@ -78,14 +78,14 @@ 
            Navigation
            
 reclaimed.
            
 
            For example, a scan method for objects in an AWL pool might
 look like this:
            
-
            mps_res_t obj_scan(mps_ss_t ss, mps_addr_t base, mps_addr_t limit)
+
            mps_res_t obj_scan(mps_ss_t ss, mps_addr_t base, mps_addr_t limit)
 {
     MPS_SCAN_BEGIN(ss) {
         while (base < limit) {
-            obj_t obj = base;
-            mps_addr_t p = obj->ref;
+            obj_t obj = base;
+            mps_addr_t p = obj->ref;
             if (MPS_FIX1(ss, p)) {
-                mps_res_t res = MPS_FIX2(ss, &p);
+                mps_res_t res = MPS_FIX2(ss, &p);
                 if (res != MPS_RES_OK) return res;
                 if (p == NULL) {
                     /* reference was splatted */
diff --git a/mps/manual/source/design/alloc-frame.rst b/mps/manual/source/design/alloc-frame.rst
deleted file mode 100644
index 021e0e1f137..00000000000
--- a/mps/manual/source/design/alloc-frame.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: allocation frames; design
-
-.. _design-alloc-frame:
-
-.. include:: ../../converted/alloc-frame.rst
diff --git a/mps/manual/source/design/arena.rst b/mps/manual/source/design/arena.rst
deleted file mode 100644
index 6b89e3948c2..00000000000
--- a/mps/manual/source/design/arena.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: arena; design
-
-.. _design-arena:
-
-.. include:: ../../converted/arena.rst
diff --git a/mps/manual/source/design/arenavm.rst b/mps/manual/source/design/arenavm.rst
deleted file mode 100644
index 08734427eb9..00000000000
--- a/mps/manual/source/design/arenavm.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-.. index::
-   pair: virtual memory arena; design
-   pair: VM arena; design
-
-.. _design-arenavm:
-
-.. include:: ../../converted/arenavm.rst
diff --git a/mps/manual/source/design/bt.rst b/mps/manual/source/design/bt.rst
deleted file mode 100644
index f8ac21cb720..00000000000
--- a/mps/manual/source/design/bt.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: bit tables; design
-
-.. _design-bt:
-
-.. include:: ../../converted/bt.rst
diff --git a/mps/manual/source/design/buffer.rst b/mps/manual/source/design/buffer.rst
deleted file mode 100644
index 3166612e78f..00000000000
--- a/mps/manual/source/design/buffer.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: buffers; design
-
-.. _design-buffer:
-
-.. include:: ../../converted/buffer.rst
diff --git a/mps/manual/source/design/check.rst b/mps/manual/source/design/check.rst
deleted file mode 100644
index 024f8b2809a..00000000000
--- a/mps/manual/source/design/check.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: checking; design
-
-.. _design-check:
-
-.. include:: ../../converted/check.rst
diff --git a/mps/manual/source/design/class-interface.rst b/mps/manual/source/design/class-interface.rst
deleted file mode 100644
index e7be02d9418..00000000000
--- a/mps/manual/source/design/class-interface.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: class interface; design
-
-.. _design-class-interface:
-
-.. include:: ../../converted/class-interface.rst
diff --git a/mps/manual/source/design/collection.rst b/mps/manual/source/design/collection.rst
deleted file mode 100644
index ba882faa0d2..00000000000
--- a/mps/manual/source/design/collection.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: collection framework; design
-
-.. _design-collection:
-
-.. include:: ../../converted/collection.rst
diff --git a/mps/manual/source/design/config.rst b/mps/manual/source/design/config.rst
deleted file mode 100644
index 9958ebcbced..00000000000
--- a/mps/manual/source/design/config.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: configuration; design
-
-.. _design-config:
-
-.. include:: ../../converted/config.rst
diff --git a/mps/manual/source/design/critical-path.rst b/mps/manual/source/design/critical-path.rst
deleted file mode 100644
index 8bf3f0c5c44..00000000000
--- a/mps/manual/source/design/critical-path.rst
+++ /dev/null
@@ -1,8 +0,0 @@
-.. index::
-   single: critical path
-   single: path; critical
-   single: Memory Pool System; critical path
-
-.. _design-critical-path:
-
-.. include:: ../../converted/critical-path.rst
diff --git a/mps/manual/source/design/diag.rst b/mps/manual/source/design/diag.rst
deleted file mode 100644
index 324c983e480..00000000000
--- a/mps/manual/source/design/diag.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: diagnostic feedback; design
-
-.. _design-diag:
-
-.. include:: ../../converted/diag.rst
diff --git a/mps/manual/source/design/finalize.rst b/mps/manual/source/design/finalize.rst
deleted file mode 100644
index 9cd0521e392..00000000000
--- a/mps/manual/source/design/finalize.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: finalization; design
-
-.. _design-finalize:
-
-.. include:: ../../converted/finalize.rst
diff --git a/mps/manual/source/design/fix.rst b/mps/manual/source/design/fix.rst
deleted file mode 100644
index 2d11b05a35f..00000000000
--- a/mps/manual/source/design/fix.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: fix function; design
-
-.. _design-fix:
-
-.. include:: ../../converted/fix.rst
diff --git a/mps/manual/source/design/guide.hex.trans.rst b/mps/manual/source/design/guide.hex.trans.rst
deleted file mode 100644
index 3c877c5ad08..00000000000
--- a/mps/manual/source/design/guide.hex.trans.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: hexadecimal; transliterating
-
-.. _design-guide.hex.trans:
-
-.. include:: ../../converted/guide.hex.trans.rst
diff --git a/mps/manual/source/design/guide.impl.c.format.rst b/mps/manual/source/design/guide.impl.c.format.rst
deleted file mode 100644
index a98deb9d3e7..00000000000
--- a/mps/manual/source/design/guide.impl.c.format.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-.. index::
-   pair: C language; formatting guide
-   pair: C language formatting; guide
-
-.. _design-guide.impl.c.format:
-
-.. include:: ../../converted/guide.impl.c.format.rst
diff --git a/mps/manual/source/design/interface-c.rst b/mps/manual/source/design/interface-c.rst
deleted file mode 100644
index ec60c8dea25..00000000000
--- a/mps/manual/source/design/interface-c.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: C interface; design
-
-.. _design-interface-c:
-
-.. include:: ../../converted/interface-c.rst
diff --git a/mps/manual/source/design/io.rst b/mps/manual/source/design/io.rst
deleted file mode 100644
index 8307f55bbad..00000000000
--- a/mps/manual/source/design/io.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: I/O subsystem; design
-
-.. _design-io:
-
-.. include:: ../../converted/io.rst
diff --git a/mps/manual/source/design/keyword-arguments.rst b/mps/manual/source/design/keyword-arguments.rst
deleted file mode 100644
index eb21b41d92a..00000000000
--- a/mps/manual/source/design/keyword-arguments.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: keyword arguments; design
-
-.. _design-keyword-arguments:
-
-.. include:: ../../converted/keyword-arguments.rst
diff --git a/mps/manual/source/design/lib.rst b/mps/manual/source/design/lib.rst
deleted file mode 100644
index 3235f61e15c..00000000000
--- a/mps/manual/source/design/lib.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: library interface; design
-
-.. _design-lib:
-
-.. include:: ../../converted/lib.rst
diff --git a/mps/manual/source/design/lock.rst b/mps/manual/source/design/lock.rst
deleted file mode 100644
index ceb782a14c1..00000000000
--- a/mps/manual/source/design/lock.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: locking; design
-
-.. _design-lock:
-
-.. include:: ../../converted/lock.rst
diff --git a/mps/manual/source/design/locus.rst b/mps/manual/source/design/locus.rst
deleted file mode 100644
index 12cc91255fb..00000000000
--- a/mps/manual/source/design/locus.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: locus manager; design
-
-.. _design-locus:
-
-.. include:: ../../converted/locus.rst
diff --git a/mps/manual/source/design/message-gc.rst b/mps/manual/source/design/message-gc.rst
deleted file mode 100644
index 881aee07424..00000000000
--- a/mps/manual/source/design/message-gc.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: garbage collection messages; design
-
-.. _design-message-gc:
-
-.. include:: ../../converted/message-gc.rst
diff --git a/mps/manual/source/design/message.rst b/mps/manual/source/design/message.rst
deleted file mode 100644
index 12413437cbd..00000000000
--- a/mps/manual/source/design/message.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-.. index::
-   pair: messages; design
-   single: client message protocol
-
-.. _design-message:
-
-.. include:: ../../converted/message.rst
diff --git a/mps/manual/source/design/object-debug.rst b/mps/manual/source/design/object-debug.rst
deleted file mode 100644
index 0c82ad04912..00000000000
--- a/mps/manual/source/design/object-debug.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: debugging; design
-
-.. _design-object-debug:
-
-.. include:: ../../converted/Object-debug.rst
diff --git a/mps/manual/source/design/pool.rst b/mps/manual/source/design/pool.rst
deleted file mode 100644
index 992eac425ff..00000000000
--- a/mps/manual/source/design/pool.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: pool class mechanism; design
-
-.. _design-pool:
-
-.. include:: ../../converted/pool.rst
diff --git a/mps/manual/source/design/poolamc.rst b/mps/manual/source/design/poolamc.rst
deleted file mode 100644
index e5ce5abc6fd..00000000000
--- a/mps/manual/source/design/poolamc.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-.. index::
-   pair: AMC pool class; design
-   single: pool class; AMC design
-
-.. _design-poolamc:
-
-.. include:: ../../converted/poolamc.rst
diff --git a/mps/manual/source/design/poolams.rst b/mps/manual/source/design/poolams.rst
deleted file mode 100644
index 2b092b2f709..00000000000
--- a/mps/manual/source/design/poolams.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-.. index::
-   pair: AMS pool class; design
-   single: pool class; AMS design
-
-.. _design-poolams:
-
-.. include:: ../../converted/poolams.rst
diff --git a/mps/manual/source/design/poolawl.rst b/mps/manual/source/design/poolawl.rst
deleted file mode 100644
index afd53b5b7db..00000000000
--- a/mps/manual/source/design/poolawl.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-.. index::
-   pair: AWL pool class; design
-   single: pool class; AWL design
-
-.. _design-poolawl:
-
-.. include:: ../../converted/poolawl.rst
diff --git a/mps/manual/source/design/poollo.rst b/mps/manual/source/design/poollo.rst
deleted file mode 100644
index eb26ff1d60a..00000000000
--- a/mps/manual/source/design/poollo.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-.. index::
-   pair: LO pool class; design
-   single: pool class; LO design
-
-.. _design-poollo:
-
-.. include:: ../../converted/poollo.rst
diff --git a/mps/manual/source/design/poolmfs.rst b/mps/manual/source/design/poolmfs.rst
deleted file mode 100644
index e8e23c4d6be..00000000000
--- a/mps/manual/source/design/poolmfs.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-.. index::
-   pair: MFS pool class; design
-   single: pool class; MFS design
-
-.. _design-poolmfs:
-
-.. include:: ../../converted/poolmfs.rst
diff --git a/mps/manual/source/design/poolmrg.rst b/mps/manual/source/design/poolmrg.rst
deleted file mode 100644
index 3afcf8f48e1..00000000000
--- a/mps/manual/source/design/poolmrg.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-.. index::
-   pair: MRG pool class; design
-   single: pool class; MRG design
-
-.. _design-poolmrg:
-
-.. include:: ../../converted/poolmrg.rst
diff --git a/mps/manual/source/design/poolmvff.rst b/mps/manual/source/design/poolmvff.rst
deleted file mode 100644
index b247a72c17e..00000000000
--- a/mps/manual/source/design/poolmvff.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-.. index::
-   pair: MVFF pool class; design
-   single: pool class; MVFF design
-
-.. _design-poolmvff:
-
-.. include:: ../../converted/poolmvff.rst
diff --git a/mps/manual/source/design/prot.rst b/mps/manual/source/design/prot.rst
deleted file mode 100644
index f2a8d3a2ede..00000000000
--- a/mps/manual/source/design/prot.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: protection interface; design
-
-.. _design-prot:
-
-.. include:: ../../converted/prot.rst
diff --git a/mps/manual/source/design/protan.rst b/mps/manual/source/design/protan.rst
deleted file mode 100644
index 7463e528871..00000000000
--- a/mps/manual/source/design/protan.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-.. index::
-   pair: ANSI; protection interface design
-   pair: ANSI protection interface; design
-
-.. _design-protan:
-
-.. include:: ../../converted/protan.rst
diff --git a/mps/manual/source/design/protli.rst b/mps/manual/source/design/protli.rst
deleted file mode 100644
index 7088c71988c..00000000000
--- a/mps/manual/source/design/protli.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-.. index::
-   pair: Linux; protection interface design
-   pair: Linux protection interface; design
-
-.. _design-protli:
-
-.. include:: ../../converted/protli.rst
diff --git a/mps/manual/source/design/protocol.rst b/mps/manual/source/design/protocol.rst
deleted file mode 100644
index 45b574e4301..00000000000
--- a/mps/manual/source/design/protocol.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: protocol inheritance; design
-
-.. _design-protocol:
-
-.. include:: ../../converted/protocol.rst
diff --git a/mps/manual/source/design/protsu.rst b/mps/manual/source/design/protsu.rst
deleted file mode 100644
index 150f715cce3..00000000000
--- a/mps/manual/source/design/protsu.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-.. index::
-   pair: SunOS 4; protection interface design
-   pair: SunOS 4 protection interface; design
-
-.. _design-protsu:
-
-.. include:: ../../converted/protsu.rst
diff --git a/mps/manual/source/design/pthreadext.rst b/mps/manual/source/design/pthreadext.rst
deleted file mode 100644
index 78f20721ec8..00000000000
--- a/mps/manual/source/design/pthreadext.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: POSIX thread extensions; design
-
-.. _design-pthreadext:
-
-.. include:: ../../converted/pthreadext.rst
diff --git a/mps/manual/source/design/reservoir.rst b/mps/manual/source/design/reservoir.rst
deleted file mode 100644
index e954bdc62ab..00000000000
--- a/mps/manual/source/design/reservoir.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: reservoir; design
-
-.. _design-reservoir:
-
-.. include:: ../../converted/reservoir.rst
diff --git a/mps/manual/source/design/ring.rst b/mps/manual/source/design/ring.rst
deleted file mode 100644
index 09d1afbb04e..00000000000
--- a/mps/manual/source/design/ring.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: ring structure; design
-
-.. _design-ring:
-
-.. include:: ../../converted/ring.rst
diff --git a/mps/manual/source/design/root.rst b/mps/manual/source/design/root.rst
deleted file mode 100644
index b42b179d6b0..00000000000
--- a/mps/manual/source/design/root.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: root manager; design
-
-.. _design-root:
-
-.. include:: ../../converted/root.rst
diff --git a/mps/manual/source/design/scan.rst b/mps/manual/source/design/scan.rst
deleted file mode 100644
index 68c52fa8e22..00000000000
--- a/mps/manual/source/design/scan.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: generic scanner; design
-
-.. _design-scan:
-
-.. include:: ../../converted/scan.rst
diff --git a/mps/manual/source/design/seg.rst b/mps/manual/source/design/seg.rst
deleted file mode 100644
index a3b4889fd91..00000000000
--- a/mps/manual/source/design/seg.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: segments; design
-
-.. _design-seg:
-
-.. include:: ../../converted/seg.rst
diff --git a/mps/manual/source/design/shield.rst b/mps/manual/source/design/shield.rst
deleted file mode 100644
index c5f85fdcdff..00000000000
--- a/mps/manual/source/design/shield.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: shield; design
-
-.. _design-shield:
-
-.. include:: ../../converted/shield.rst
diff --git a/mps/manual/source/design/sig.rst b/mps/manual/source/design/sig.rst
deleted file mode 100644
index 674a47e2bfd..00000000000
--- a/mps/manual/source/design/sig.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-.. index::
-   pair: structure signatures; design
-   single: signatures
-
-.. _design-sig:
-
-.. include:: ../../converted/sig.rst
diff --git a/mps/manual/source/design/splay.rst b/mps/manual/source/design/splay.rst
deleted file mode 100644
index 79400def8b5..00000000000
--- a/mps/manual/source/design/splay.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: splay trees; design
-
-.. _design-splay:
-
-.. include:: ../../converted/splay.rst
diff --git a/mps/manual/source/design/sso1al.rst b/mps/manual/source/design/sso1al.rst
deleted file mode 100644
index a95baff3217..00000000000
--- a/mps/manual/source/design/sso1al.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-.. index::
-   pair: Digital Unix on Alpha stack scanner; design
-   pair: Digital Unix on Alpha; stack scanner design
-
-.. _design-sso1al:
-
-.. include:: ../../converted/sso1al.rst
diff --git a/mps/manual/source/design/telemetry.rst b/mps/manual/source/design/telemetry.rst
deleted file mode 100644
index 58b119aff6b..00000000000
--- a/mps/manual/source/design/telemetry.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: telemetry; design
-
-.. _design-telemetry:
-
-.. include:: ../../converted/telemetry.rst
diff --git a/mps/manual/source/design/thread-manager.rst b/mps/manual/source/design/thread-manager.rst
deleted file mode 100644
index 8719f6f3272..00000000000
--- a/mps/manual/source/design/thread-manager.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: thread manager; design
-
-.. _design-thread-manager:
-
-.. include:: ../../../design/thread-manager.txt
diff --git a/mps/manual/source/design/thread-safety.rst b/mps/manual/source/design/thread-safety.rst
deleted file mode 100644
index 05966e4b8c4..00000000000
--- a/mps/manual/source/design/thread-safety.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: thread safety; design
-
-.. _design-thread-safety:
-
-.. include:: ../../converted/thread-safety.rst
diff --git a/mps/manual/source/design/trace.rst b/mps/manual/source/design/trace.rst
deleted file mode 100644
index caacef96048..00000000000
--- a/mps/manual/source/design/trace.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: tracer; design
-
-.. _design-trace:
-
-.. include:: ../../converted/trace.rst
diff --git a/mps/manual/source/design/type.rst b/mps/manual/source/design/type.rst
deleted file mode 100644
index 6026dc77cbd..00000000000
--- a/mps/manual/source/design/type.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: general types; design
-
-.. _design-type:
-
-.. include:: ../../converted/type.rst
diff --git a/mps/manual/source/design/version-library.rst b/mps/manual/source/design/version-library.rst
deleted file mode 100644
index 2ec9e1ac384..00000000000
--- a/mps/manual/source/design/version-library.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: library version mechanism; design
-
-.. _design-version-library:
-
-.. include:: ../../converted/version-library.rst
diff --git a/mps/manual/source/design/version.rst b/mps/manual/source/design/version.rst
deleted file mode 100644
index 65b3e5bea8e..00000000000
--- a/mps/manual/source/design/version.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-.. index::
-   pair: software versions; design
-   single: versions; design
-
-.. _design-version:
-
-.. include:: ../../converted/version.rst
diff --git a/mps/manual/source/design/vm.rst b/mps/manual/source/design/vm.rst
deleted file mode 100644
index 65668442aec..00000000000
--- a/mps/manual/source/design/vm.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: virtual mapping; design
-
-.. _design-vm:
-
-.. include:: ../../converted/vm.rst
diff --git a/mps/manual/source/design/vman.rst b/mps/manual/source/design/vman.rst
deleted file mode 100644
index 215ef64a71e..00000000000
--- a/mps/manual/source/design/vman.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: ANSI fake VM; design
-
-.. _design-vman:
-
-.. include:: ../../converted/vman.rst
diff --git a/mps/manual/source/design/vmo1.rst b/mps/manual/source/design/vmo1.rst
deleted file mode 100644
index c43336d1b39..00000000000
--- a/mps/manual/source/design/vmo1.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: VM for Digital Unix; design
-
-.. _design-vmo1:
-
-.. include:: ../../converted/vmo1.rst
diff --git a/mps/manual/source/design/vmso.rst b/mps/manual/source/design/vmso.rst
deleted file mode 100644
index 127df7df9d1..00000000000
--- a/mps/manual/source/design/vmso.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: VM for Solaris; design
-
-.. _design-vmso:
-
-.. include:: ../../converted/vmso.rst
diff --git a/mps/manual/source/design/writef.rst b/mps/manual/source/design/writef.rst
deleted file mode 100644
index a771bd72375..00000000000
--- a/mps/manual/source/design/writef.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-.. index::
-   pair: WriteF function; design
-
-.. _design-writef:
-
-.. include:: ../../converted/writef.rst
diff --git a/mps/manual/source/diagrams/logo.png b/mps/manual/source/diagrams/logo.png
index 42756c08d7a..f60476aa6ca 100644
Binary files a/mps/manual/source/diagrams/logo.png and b/mps/manual/source/diagrams/logo.png differ
diff --git a/mps/manual/source/diagrams/logo.svg b/mps/manual/source/diagrams/logo.svg
deleted file mode 100644
index 46b2ba9de02..00000000000
--- a/mps/manual/source/diagrams/logo.svg
+++ /dev/null
@@ -1,104 +0,0 @@
-
-
-
-
-  
-    
-  
-  
-  
-    
-      
-        image/svg+xml
-        
-      
-    
-  
-  
-    MEMORY
-    POOL
-    SYSTEM
-  
-
diff --git a/mps/manual/source/extensions/mps/designs.py b/mps/manual/source/extensions/mps/designs.py
index ceab31b888c..f4a3fd0c861 100644
--- a/mps/manual/source/extensions/mps/designs.py
+++ b/mps/manual/source/extensions/mps/designs.py
@@ -26,7 +26,7 @@
 
 mode = re.compile(r'\.\. mode: .*\n')
 prefix = re.compile(r'^:Tag: ([a-z][a-z.0-9-]*[a-z0-9])$', re.MULTILINE)
-rst_tag = re.compile(r'^:(?:Author|Date|Status|Revision|Copyright|Organization|Format):.*?$\n', re.MULTILINE)
+rst_tag = re.compile(r'^:(?:Author|Date|Status|Revision|Copyright|Organization|Format|Index terms):.*?$\n', re.MULTILINE | re.IGNORECASE)
 mps_tag = re.compile(r'_`\.([a-z][A-Za-z.0-9_-]*[A-Za-z0-9])`:')
 mps_ref = re.compile(r'`(\.[a-z][A-Za-z.0-9_-]*[A-Za-z0-9])`_(?:        )?')
 funcdef = re.compile(r'^``([^`]*\([^`]*\))``$', re.MULTILINE)
@@ -78,8 +78,25 @@ def citation_sub(m):
         result += ' "{title}".'.format(**groups)
     return result
 
+index = re.compile(r'^:Index\s+terms:(.*$\n(?:[ \t]+.*$\n)*)', re.MULTILINE | re.IGNORECASE)
+
+# 
+index_term = re.compile(r'^\s*(\w+):\s*(.*?)\s*$', re.MULTILINE)
+
+def index_sub(m):
+    s = '\n.. index::\n'
+    for term in index_term.finditer(m.group(1)):
+        s += '   %s: %s\n' % (term.group(1), term.group(2))
+    s += '\n'
+    return s
+
 def convert_file(name, source, dest):
     s = open(source).read()
+    # We want the index directive to go right at the start, so that it leads
+    # to the whole document.
+    m = index.search(s)
+    if m:
+        s = index_sub(m) + s
     s = mode.sub(r'', s)
     s = prefix.sub(r'.. mps:prefix:: \1', s)
     s = rst_tag.sub(r'', s)
@@ -99,7 +116,7 @@ def convert_file(name, source, dest):
     except:
         pass
     with open(dest, 'w') as out:
-        # out.write('.. _design-{0}:\n\n'.format(name))
+        out.write('.. _design-{0}:\n\n'.format(name))
         out.write(s)
 
 # Mini-make
@@ -107,7 +124,7 @@ def convert_updated(app):
     app.info(bold('converting MPS design documents'))
     for design in glob.iglob('../design/*.txt'):
         name = os.path.splitext(os.path.basename(design))[0]
-        converted = 'converted/%s.rst' % name
+        converted = 'source/design/%s.rst' % name
         if (not os.path.isfile(converted) or
             os.path.getmtime(converted) < os.path.getmtime(design)):
             app.info('converting design %s' % name)
diff --git a/mps/manual/source/pool/mfs.rst b/mps/manual/source/pool/mfs.rst
index 66071937bcf..20d58e4cf35 100644
--- a/mps/manual/source/pool/mfs.rst
+++ b/mps/manual/source/pool/mfs.rst
@@ -99,8 +99,8 @@ MFS interface
     For example::
 
         MPS_ARGS_BEGIN(args) {
-            MPS_ARGS_ADD(ARGS, MPS_KEY_MFS_UNIT_SIZE, 1024);
-            MPS_ARGS_ADD(ARGS, MPS_KEY_EXTEND_BY, 1024 * 1024);
+            MPS_ARGS_ADD(args, MPS_KEY_MFS_UNIT_SIZE, 1024);
+            MPS_ARGS_ADD(args, MPS_KEY_EXTEND_BY, 1024 * 1024);
             MPS_ARGS_DONE(args);
             res = mps_pool_create_k(&pool, arena, mps_class_mfs(), args);
         } MPS_ARGS_END(args);
diff --git a/mps/manual/source/pool/mv.rst b/mps/manual/source/pool/mv.rst
index c2c6bca7163..7d9b32cbf8c 100644
--- a/mps/manual/source/pool/mv.rst
+++ b/mps/manual/source/pool/mv.rst
@@ -93,9 +93,9 @@ MV interface
     For example::
 
         MPS_ARGS_BEGIN(args) {
-            MPS_ARGS_ADD(ARGS, MPS_KEY_MEAN_SIZE, 32);
-            MPS_ARGS_ADD(ARGS, MPS_KEY_MAX_SIZE, 1024);
-            MPS_ARGS_ADD(ARGS, MPS_KEY_EXTEND_BY, 1024 * 1024);
+            MPS_ARGS_ADD(args, MPS_KEY_MEAN_SIZE, 32);
+            MPS_ARGS_ADD(args, MPS_KEY_MAX_SIZE, 1024);
+            MPS_ARGS_ADD(args, MPS_KEY_EXTEND_BY, 1024 * 1024);
             MPS_ARGS_DONE(args);
             res = mps_pool_create_k(&pool, arena, mps_class_mfs(), args);
         } MPS_ARGS_END(args);
diff --git a/mps/manual/source/pool/mvff.rst b/mps/manual/source/pool/mvff.rst
index c7f358abcdb..4f105bffc28 100644
--- a/mps/manual/source/pool/mvff.rst
+++ b/mps/manual/source/pool/mvff.rst
@@ -164,12 +164,12 @@ MVFF interface
     For example::
 
         MPS_ARGS_BEGIN(args) {
-            MPS_ARGS_ADD(ARGS, MPS_KEY_EXTEND_BY, 1024 * 1024);
-            MPS_ARGS_ADD(ARGS, MPS_KEY_MEAN_SIZE, 32);
-            MPS_ARGS_ADD(ARGS, MPS_KEY_ALIGN, 8);
-            MPS_ARGS_ADD(ARGS, MPS_KEY_MVFF_ARENA_HIGH, 1);
-            MPS_ARGS_ADD(ARGS, MPS_KEY_MVFF_SLOT_HIGH, 1);
-            MPS_ARGS_ADD(ARGS, MPS_KEY_MVFF_FIRST_FIT, 0);
+            MPS_ARGS_ADD(args, MPS_KEY_EXTEND_BY, 1024 * 1024);
+            MPS_ARGS_ADD(args, MPS_KEY_MEAN_SIZE, 32);
+            MPS_ARGS_ADD(args, MPS_KEY_ALIGN, 8);
+            MPS_ARGS_ADD(args, MPS_KEY_MVFF_ARENA_HIGH, 1);
+            MPS_ARGS_ADD(args, MPS_KEY_MVFF_SLOT_HIGH, 1);
+            MPS_ARGS_ADD(args, MPS_KEY_MVFF_FIRST_FIT, 0);
             MPS_ARGS_DONE(args);
             res = mps_pool_create_k(&pool, arena, mps_class_mvff(), args);
         } MPS_ARGS_END(args);
diff --git a/mps/manual/source/pool/mvt.rst b/mps/manual/source/pool/mvt.rst
index dd2c1ba79df..84192aa19a8 100644
--- a/mps/manual/source/pool/mvt.rst
+++ b/mps/manual/source/pool/mvt.rst
@@ -182,11 +182,11 @@ MVT interface
     For example::
 
         MPS_ARGS_BEGIN(args) {
-            MPS_ARGS_ADD(ARGS, MPS_KEY_MIN_SIZE, 4);
-            MPS_ARGS_ADD(ARGS, MPS_KEY_MEAN_SIZE, 32);
-            MPS_ARGS_ADD(ARGS, MPS_KEY_MAX_SIZE, 1024);
-            MPS_ARGS_ADD(ARGS, MPS_KEY_MVT_RESERVE_DEPTH, 256);
-            MPS_ARGS_ADD(ARGS, MPS_KEY_MVT_FRAG_LIMIT, 0.5);
+            MPS_ARGS_ADD(args, MPS_KEY_MIN_SIZE, 4);
+            MPS_ARGS_ADD(args, MPS_KEY_MEAN_SIZE, 32);
+            MPS_ARGS_ADD(args, MPS_KEY_MAX_SIZE, 1024);
+            MPS_ARGS_ADD(args, MPS_KEY_MVT_RESERVE_DEPTH, 256);
+            MPS_ARGS_ADD(args, MPS_KEY_MVT_FRAG_LIMIT, 0.5);
             MPS_ARGS_DONE(args);
             res = mps_pool_create_k(&pool, arena, mps_class_mvt(), args);
         } MPS_ARGS_END(args);
diff --git a/mps/readme.txt b/mps/readme.txt
index 78eefa68b31..223862cc346 100644
--- a/mps/readme.txt
+++ b/mps/readme.txt
@@ -52,7 +52,7 @@ using it.  The basic case is straightforward on supported platforms
 
 This will produce an object file you can link with your project.  For
 details of how to configure the MPS, build libraries and tests, use
-IDEs, autoconf, etc. see `Building the MPS `_.
+IDEs, autoconf, etc. see `Building the MPS `__.
 
 For an example of using the MPS, see the `Scheme interpreter
 example `_.
@@ -81,7 +81,7 @@ that we are powerless to correct.  It is due to be fixed in Windows 8.
 
 The MPS is highly portable and has run on many other processors and
 operating systems in the past (see `Building the MPS
-`_). Most of the MPS is written in very pure
+`__). Most of the MPS is written in very pure
 ANSI C and compiles without warnings on anything.
 
 
diff --git a/mps/tool/testrun.bat b/mps/tool/testrun.bat
new file mode 100755
index 00000000000..49a12660783
--- /dev/null
+++ b/mps/tool/testrun.bat
@@ -0,0 +1,60 @@
+@rem $Id: //info.ravenbrook.com/project/mps/master/tool/testrun.sh#1 $
+@rem Copyright (c) 2013 Ravenbrook Limited. See end of file for license.
+
+@echo off
+
+set PFM=%1
+shift
+set VARIETY=%1
+shift
+
+set LOG=%TMP%\mps.%VARIETY%.log
+echo Logging test output to %LOG%
+
+:loop
+if "%1"=="" goto continue
+    echo Running %1
+    %PFM%\%VARIETY%\%1 >> %LOG%
+shift
+goto loop
+:continue
+
+@rem C. COPYRIGHT AND LICENSE
+@rem
+@rem Copyright (C) 2013 Ravenbrook Limited .
+@rem All rights reserved.  This is an open source license.  Contact
+@rem Ravenbrook for commercial licensing options.
+@rem 
+@rem Redistribution and use in source and binary forms, with or without
+@rem modification, are permitted provided that the following conditions are
+@rem met:
+@rem 
+@rem 1. Redistributions of source code must retain the above copyright
+@rem notice, this list of conditions and the following disclaimer.
+@rem 
+@rem 2. Redistributions in binary form must reproduce the above copyright
+@rem notice, this list of conditions and the following disclaimer in the
+@rem documentation and/or other materials provided with the distribution.
+@rem 
+@rem 3. Redistributions in any form must be accompanied by information on how
+@rem to obtain complete source code for this software and any accompanying
+@rem software that uses this software.  The source code must either be
+@rem included in the distribution or be available for no more than the cost
+@rem of distribution plus a nominal fee, and must be freely redistributable
+@rem under reasonable conditions.  For an executable file, complete source
+@rem code means the source code for all modules it contains. It does not
+@rem include source code for modules or files that typically accompany the
+@rem major components of the operating system on which the executable file
+@rem runs.
+@rem 
+@rem THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
+@rem IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+@rem TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
+@rem PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL THE
+@rem COPYRIGHT HOLDERS AND CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+@rem INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+@rem NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+@rem USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+@rem ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+@rem (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+@rem THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.