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

Making the memory manager more pluggable

closedby vitiralopened 2015-11-07updated 2021-04-20

This is the pull request for making the memory manager more pluggable -- i.e. separate the gc from the heap manager to allow advancements on both separately.

This is part of the solution for #1168 and is a rework of several PR attempts:

  • #1234
  • #1320
  • #1321

This PR attempts to consolodate the advice from those failed PR's and make a change that is as minimally invasive as possible to the existing code base and meets the coding guidlelines as much as possible.

The pull request uses the existing infrastructure to allow each build to select which garbage collector implementation it wants, either the original or the "basic" as the pluggable versions are being called. Eventually more gc implementations will be added, the next planned one is one that simply uses unix's malloc/free.

In addition, an astyle.fmt file has been added to the tools/ directory that should define a fair number of micropython's coding conventions so that new contributors can automatically get their code formatted correctly and painlessly. This file may be a work in progress.

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