From: <don...@is...> - 2008-11-27 09:44:44
|
Vladimir Tzankov writes: I don't want to waste too much of the time you could be spending actually getting this stuff done, so I'll try to stick to the important part: Am I correct that the plan is that gc will be able to proceed without indefinite delay in all cases? The paragraph below indicates that this is not currently the case: > Currently the GC can suspend threads only in two cases. When thread > allocates heap object or when the thread is in (possibly) blocking > system (foreign) call. For the latter - all such possibly blocking > foreign calls should be found and "marked" (currently - streams and > file system operations are mostly marked). But the current case may not be (I hope is not) the goal. Is the goal, as I hope? That is, (1) all lisp code will be guaranteed to check within a short time (2) foreign code need not be stopped for GC to run Which implies that GC will never be delayed very long. > As you write below - checking whether GC waits on thread to be > suspended is almost zero cost - it is not a problem to add checks in > (bytecode) interpreter if needed. However depending where these > checks are put additional actions may be needed - at least putting > all objects in use to GC visible locations. I was imagining that the state at the end of every byte code instruction was understood by GC, but I suppose you could stop in some place where this was not the case, but where some other process could recognize and fix the problem. You might then view the extra process as an early phase of GC. > As I wrote above the foreign calls that may block should be > "marked" (enclosed in GC safe regions). If pointer in the heap is > passed to foreign code - the heap object should be "pinned" - so GC > (if happens) is not going to move it. This seems to be imposing restrictions on code that can block, whereas I want to instead impose restrictions on sections of code that access data that is accessed by GC. It seems fair to impose requirements on foreign code. I suggest the requirements be: (1) all access to GC sensitive data must be done inside a marked section (2) all marked sections are required to last a short time (in particular, if you want GC not to be delayed more than 1 sec you must ensure that your marked sections last less than 1 sec) Perhaps this is related to your remark about blocking? You should not block in a marked section since it then might violate this rule. (3) of course you must expect that a gc might occur between your marked sections - so you can't save any pointers to GC sensitive data from one marked section to the next. We have to specify what this GC sensitive data is. I presume at least the heap, but also some data on the stack and in registers? In particular, any foreign code that does not access the heap should be able to run in parallel with GC. |