Author: Armin Rigo <[email protected]>
Branch: timelog
Changeset: r1117:3649d0fe67de
Date: 2014-03-29 15:58 +0100
http://bitbucket.org/pypy/stmgc/changeset/3649d0fe67de/
Log: Simplify the API a lot, by considering that recording several logs
is a job outside the scope of stmgc.
diff --git a/c7/timelog.txt b/c7/timelog.txt
--- a/c7/timelog.txt
+++ b/c7/timelog.txt
@@ -37,33 +37,27 @@
(less than 5 times slower than a RDTSC instruction, which is itself
not safe in the presence of threads migrating among CPUs)
-- record a fixed number of entries, as a fixed-size heapq list, with
- higher recorded times sorted first; the entry with the lowest amount
- of time is dropped.
-
-- if there are several aborts from what is logically the same starting
+- record only the highest-time entry. The user of the library is
+ responsible for getting and clearing it often enough if it wants
+ more details. [[ For example, it may want to maintain a heapq
+ with several entries, but that's not the job of stmgc. Moreover,
+ if there are several aborts from what is logically the same starting
place and which ends with the same traceback, we'd like to regroup them
and report them only once with the number of consecutive occurrences
and the total time; doing that before inserting the entries in the heapq
list is needed, as otherwise if we have a lot of quick aborts they
would all be lost as not contributing significant time individually.
+ ]]
API of stmgc.h
==============
-- timelogs are always thread-local. We have APIs to create, clear and
- destroy them; recorded entries go to all active timelogs of this thread.
-
- the traceback reports are based on the user of the library pushing and
popping stack entries to the current stack in every thread.
-- we have APIs to enumerate a timelog's current entries, and enumerate
- each traceback's recorded frames.
-
-- we can get directly the traceback of the transaction that aborted just
- now. If the user determines it should be merged with an older
- traceback, he calls a merge function.
+- we have a simple API to get and clear the traceback and reason of the
+ single report with the highest recorded time, for the current thread.
Tracebacks
@@ -77,12 +71,11 @@
the common case of objects freed shortly after being allocated.
We record one traceback pointer for every old object written during this
-transaction. It could be avoided only if we are running with no timelog
-at all (not just none in this thread), but it's probably not worth the
+transaction. It could be avoided only if we disable all reports (not
+just the one in this thread), but it's probably not worth the
optimization.
This is all thread-local, with the exception of when we record another
thread's traceback. To implement this, we clone the complete traceback
into the other thread's local allocator. It should be fine because it
-is only needed when we have already determined that this entry has an
-important enough recorded time to be worth storing.
+is only needed once, on abort.
_______________________________________________
pypy-commit mailing list
[email protected]
https://mail.python.org/mailman/listinfo/pypy-commit
