← index #1161PR #1321
Related · high · value 0.324
QUERY · ISSUE

Towards possibility of precise garbage collector

openby pfalconopened 2015-03-17updated 2018-09-20
rfc

It seems that many approaches of further evolution of GC in uPy depend on being able to do precise GC, i.e. tell which fields with an object are pointers are which are not. To achieve this, each allocated memory block has to be explicitly typed (and from type, internal layout can be inferred). Way to achieve this while staying compatible with conservative GC and without updating code largely is to have to set of memory allocation routines: one set is to deal with uPy objects (which already have type header is structure member) and another set to deal with "raw" memory allocations (which will need type header added implicitly for precise GC, and nothing added for conservative GC).

We currently have ~dozen functions to do memalloc. The above means doubling them. Other approach would be to reserve all current functions to uPy objects, add just add 2 funcs for "raw" memory: m_malloc() (will use implicit "all pointers inside" type) and m_malloc_typed() which takes explicit type for allocation.

Other thoughts?

CANDIDATE · PULL REQUEST

py/gc.c: decouple gc_sweep from allocation/free operations

closedby vitiralopened 2015-06-12updated 2015-11-07

This commit is the first part in a series of commits to decouple
the alloc/dealloc component of the upython memory manager from the
garbage collector.

  • mem_free implemented to be independent of gc_free.
  • mem_first and mem_next functions for a standard api to walk
    through memory

This commit WILL have a small impact on performance. The mem_next
function is not quite as fast as the original implementation.
Also, mem_free performs some checks (in MEM_VALID) that have
essentially already been done by the loop.

I contend the following:

  • there is no way to make the "next" funcionality faster and allow
    it to be fully decoupled
  • we could make the mem_free function faster by implementing a
    mem_free_unsafe (or something) that would not perform the checks.
    This could be a macro for speed, and called by the mem_free
    function. Whether this complexity is required for the small
    increase in performance is up to the upython developers

Keyboard

j / / n
next pair
k / / p
previous pair
1 / / h
show query pane
2 / / l
show candidate pane
c
copy suggested comment
r
toggle reasoning
g i
go to index
?
show this help
esc
close overlays

press ? or esc to close

copied