← index #1161PR #1230
Related · high · value 0.566
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

Garbage collector documentation

closedby vitiralopened 2015-05-05updated 2015-05-06

This is to prepare for #1168. I would appreciate any comments on this documentation before I continue with making it apply to standard malloc/free.

Also, I am considering implementing a standard NEXT macro that gets the next piece of allocated memory -- this way the entire memory can easily be stepped through. All micro memory allocators that I have encountered (including tinymem) support this, so I think it should be a requirement for any memory manager that micro-python plugs into.

In addition, I think any memory manager we plug into should be able to do in-place marking of memory -- something that is also not necessarily supported with standard malloc/free.

Both of these requirements will increase the speed and reduce the memory consumption (and complexity) of any memory manager used by micropython.

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