pike.git / multi-cpu.txt

version» Context lines:

pike.git/multi-cpu.txt:449:    so would require that thread too to be a proper pike thread with    pike stack etc; it seems better to keep it an "invisible"    low-level thread outside the "worker" threads. In programs with a    "backend thread" it could be useful to allow the gc thread wake up    the backend thread to let it execute the destruct calls.      j. The most bothersome problem is that things are no longer freed    right away when running out of refs. See issue "Immediate    destruct/free when refcount reaches zero".    - k. FIXME: How to solve weak refs? + k. Weak refs are handled with a separate refcount in each thing. That +  means things have two refcounts: One for weak refs and another for +  all refs. See also issue "Weak ref garbage collection".      l. One might consider separating the refcounts from the things by    using a hash table. This makes sense when considering that only    the collector thread is using the refcounts, thereby avoiding    false aliasing occurring from refcounter updates (and other gc    related flags) by that thread.       All the hash table lookups would however incur a significant    overhead in the gc thread. A better alternative would be to use a    bitmap based on the possible allocation slots used by the malloc
pike.git/multi-cpu.txt:703:   operator destructively grows the array to add new elements to the end   of it.      With the new gc approach, such single-refcount optimizations no longer   work in general. This is the case even if the micro-gc is implemented,   since stack refs aren't counted.      FIXME: List cases and discuss solutions.       + Issue: Weak ref garbage collection +  + When the two refcounters (one for total number of refs and another for + the number of weak refs) are equal then the thing is semantically + freed. The problem is that it still got refs which might be followed + later, so the gc cannot free it. +  + There are two ways to tackle this problem: +  + One alternative is to keep track of all the weak pointers that point + to each thing, so that they can be followed backwards and cleared when + only weak pointers are left. That tracking requires additional data + structures and the associated overhead, and clearing the other + pointers might require lock space locks to be taken. +  + Another alternative is to free all refs emanating from the thing with + only weak pointers left, and keep it as an empty structure (a + destructed object, an empty array/multiset/mapping, or an empty + skeleton program which contains no identifiers). This approach + requires a flag to recognize such semi-freed things, and that all code + that dereference weak pointers check for it. A problem is that data + blocks remain allocated longer than necessary, maybe even + indefinitely. That can be mitigated to some degree by shortening them + using realloc(3). +  +    Issue: Moving things between lock spaces      Things can be moved between lock spaces, or be made thread local or   disowned. In all these cases, one or more things are given explicitly.   It's natural if not only those things are moved, but also all other   things in the same source lock space that are referenced from the   given things and not from anywhere else (this operation is the same as   Pike.count_memory does). In the case of making things thread local or   disowned, it is also necessary to check that the explicitly given   things aren't referenced from elsewhere.