Author: Armin Rigo <[email protected]>
Branch:
Changeset: r888:73ad02610b81
Date: 2014-02-27 09:55 +0100
http://bitbucket.org/pypy/stmgc/changeset/73ad02610b81/
Log: Fix comments (only, for now)
diff --git a/c7/stm/gcpage.c b/c7/stm/gcpage.c
--- a/c7/stm/gcpage.c
+++ b/c7/stm/gcpage.c
@@ -5,16 +5,12 @@
static void setup_gcpage(void)
{
- /* NB. the very last page is not used, which allows a speed-up in
- reset_all_creation_markers() */
char *base = stm_object_pages + END_NURSERY_PAGE * 4096UL;
- uintptr_t length = (NB_PAGES - END_NURSERY_PAGE - 1) * 4096UL;
+ uintptr_t length = (NB_PAGES - END_NURSERY_PAGE) * 4096UL;
_stm_largemalloc_init_arena(base, length);
uninitialized_page_start = stm_object_pages + END_NURSERY_PAGE * 4096UL;
uninitialized_page_stop = stm_object_pages + NB_PAGES * 4096UL;
-
- assert(GC_MEDIUM_REQUEST >= (1 << 8));
}
static void teardown_gcpage(void)
diff --git a/c7/stm/gcpage.h b/c7/stm/gcpage.h
--- a/c7/stm/gcpage.h
+++ b/c7/stm/gcpage.h
@@ -1,14 +1,14 @@
/* Outside the nursery, we are taking from the highest addresses
- complete pages, one at a time, which uniformly contain objects
- of size "8 * N" for some N in range(2, GC_N_SMALL_REQUESTS). We
- are taking from the lowest addresses "large" objects, which are
- guaranteed to be at least 256 bytes long (actually 288),
- allocated by largemalloc.c.
+ complete pages, one at a time, which uniformly contain objects of
+ size "8 * N" for some N in range(2, GC_N_SMALL_REQUESTS). We are
+ taking from the lowest addresses "large" objects, which are at least
+ 128 bytes long, allocated by largemalloc.c. The limit was picked
+ from a run a PyPy, showing that (in this case) the number of
+ allocations of at least 128 bytes is a lot below 1%.
*/
-#define GC_N_SMALL_REQUESTS 36
-#define GC_MEDIUM_REQUEST (GC_N_SMALL_REQUESTS * 8)
+#define GC_N_SMALL_REQUESTS 16
static char *uninitialized_page_start; /* within segment 0 */
diff --git a/c7/stm/list.h b/c7/stm/list.h
--- a/c7/stm/list.h
+++ b/c7/stm/list.h
@@ -73,7 +73,8 @@
/* The tree_xx functions are, like the name hints, implemented as a tree,
supporting very high performance in TREE_FIND in the common case where
there are no or few elements in the tree, but scaling correctly
- if the number of items becomes large. */
+ if the number of items becomes large (logarithmically, rather
+ than almost-constant-time with hash maps, but with low constants). */
#define TREE_BITS 4
#define TREE_ARITY (1 << TREE_BITS)
diff --git a/c7/stm/nursery.c b/c7/stm/nursery.c
--- a/c7/stm/nursery.c
+++ b/c7/stm/nursery.c
@@ -89,7 +89,7 @@
char *realobj = REAL_ADDRESS(STM_SEGMENT->segment_base, obj);
size_t size = stmcb_size_rounded_up((struct object_s *)realobj);
- if (1 /*size >= GC_MEDIUM_REQUEST*/) {
+ if (1 /*size >= GC_N_SMALL_REQUESTS*8*/) {
/* case 1: object is not small enough.
Ask gcpage.c for an allocation via largemalloc. */
_______________________________________________
pypy-commit mailing list
[email protected]
https://mail.python.org/mailman/listinfo/pypy-commit
