QUERY · ISSUE

constrained

openby peterhinchopened 2017-06-11updated 2017-07-02

docs

This has

gc.threshold((gc.mem_free() + gc.mem_alloc()) // 4)

which sets the threshold to 1/4 of the total RAM regardless of the amount allocated. Shouldn't this read

gc.threshold(gc.mem_free() // 4 + gc.mem_alloc())

to account for RAM already allocated?

CANDIDATE · PULL REQUEST

py/gc & esp32: Include largest free block in gc.mem_free() if MICROPY_GC_SPLIT_HEAP_AUTO is enabled

mergedby projectgusopened 2023-09-05updated 2023-09-19

port-esp32py-core

This is a follow-up to #12141 based on discussions in #12316, and changes the behaviour of the esp32 port only.

Add the "max new split" value to the result of gc.mem_free(), to give a more accurate impression of how much RAM is available for Python code to use.
Update esp32 docs to match, and clarify that gc.mem_alloc() and gc.mem_free() functions are relevant for Python allocations only.

This work was funded through GitHub Sponsors.

Assessment

Q Qwen · medium

The query (issue #3138) is about a documentation example in docs/reference/constrained that shows a potentially incorrect GC threshold calculation formula. The candidate (PR #12366) is a feature change to the ESP32 port that modifies how gc.mem_free() reports available memory by including split heap blocks. While both items involve gc.mem_free() and GC threshold concepts, they address different problems: the query is about a documentation formula correctness, while the PR is about memory reporting accuracy for a specific port. The PR does not resolve the documentation issue raised in the query.

Suggested action

Keep both items open. The query about the documentation formula should be addressed separately, possibly by updating the docs/reference/constrained documentation or clarifying the intended behavior.

gc threshold calculation in docs/reference/constrained

py/gc & esp32: Include largest free block in gc.mem_free() if MICROPY_GC_SPLIT_HEAP_AUTO is enabled

Keyboard