1. 20 Feb, 2018 1 commit
  2. 19 Feb, 2018 4 commits
  3. 11 Dec, 2017 1 commit
    • Damien George's avatar
      py: Introduce a Python stack for scoped allocation. · 02d830c0
      Damien George authored
      This patch introduces the MICROPY_ENABLE_PYSTACK option (disabled by
      default) which enables a "Python stack" that allows to allocate and free
      memory in a scoped, or Last-In-First-Out (LIFO) way, similar to alloca().
      A new memory allocation API is introduced along with this Py-stack.  It
      includes both "local" and "nonlocal" LIFO allocation.  Local allocation is
      intended to be equivalent to using alloca(), whereby the same function must
      free the memory.  Nonlocal allocation is where another function may free
      the memory, so long as it's still LIFO.
      Follow-up patches will convert all uses of alloca() and VLA to the new
      scoped allocation API.  The old behaviour (using alloca()) will still be
      available, but when MICROPY_ENABLE_PYSTACK is enabled then alloca() is no
      longer required or used.
      The benefits of enabling this option are (or will be once subsequent
      patches are made to convert alloca()/VLA):
      - Toolchains without alloca() can use this feature to obtain correct and
        efficient scoped memory allocation (compared to using the heap instead
        of alloca(), which is slower).
      - Even if alloca() is available, enabling the Py-stack gives slightly more
        efficient use of stack space when calling nested Python functions, due to
        the way that compilers implement alloca().
      - Enabling the Py-stack with the stackless mode allows for even more
        efficient stack usage, as well as retaining high performance (because the
        heap is no longer used to build and destroy stackless code states).
      - With Py-stack and stackless enabled, Python-calling-Python is no longer
        recursive in the C mp_execute_bytecode function.
      The micropython.pystack_use() function is included to measure usage of the
      Python stack.
  4. 08 Dec, 2017 2 commits
  5. 07 Dec, 2017 1 commit
  6. 29 Nov, 2017 1 commit
  7. 04 Oct, 2017 1 commit
    • Damien George's avatar
      all: Remove inclusion of internal py header files. · a3dc1b19
      Damien George authored
      Header files that are considered internal to the py core and should not
      normally be included directly are:
          py/nlr.h - internal nlr configuration and declarations
          py/bc0.h - contains bytecode macro definitions
          py/runtime0.h - contains basic runtime enums
      Instead, the top-level header files to include are one of:
          py/obj.h - includes runtime0.h and defines everything to use the
              mp_obj_t type
          py/runtime.h - includes mpstate.h and hence nlr.h, obj.h, runtime0.h,
              and defines everything to use the general runtime support functions
      Additional, specific headers (eg py/objlist.h) can be included if needed.
  8. 15 Aug, 2017 1 commit
  9. 31 Jul, 2017 1 commit
  10. 18 Jul, 2017 1 commit
    • Damien George's avatar
      py: Add optional Python-stack memory region. · aca930d3
      Damien George authored
      This patch adds an optional Python-stack memory region, in addition to
      the C stack and the Python heap.  The Python stack is enabled by the
      MICROPY_ENABLE_PYSTACK option (it's disabled by default).  And then the
      memory for the Python stack is initialised via:
          mp_pystack_init(pystack_start, pystack_end);
      With this feature enabled the memory for the call frame of a Python
      function is allocated from this region, rather than from the C stack
      or heap.  The advantage of using the Python stack is that it is very
      fast to allocate/deallocate, it is deterministic, and allows better
      control over how much C stack is used.
  11. 14 Jul, 2017 2 commits
  12. 12 Jul, 2017 1 commit
  13. 12 Apr, 2017 1 commit
    • Damien George's avatar
      py/gc: Execute finaliser code in a protected environment. · c7e8c6f7
      Damien George authored
      If a finaliser raises an exception then it must not propagate through the
      GC sweep function.  This patch protects against such a thing by running
      finaliser code via the mp_call_function_1_protected call.
      This patch also adds scheduler lock/unlock calls around the finaliser
      execution to further protect against any possible reentrancy issues: the
      memory manager is already locked when doing a collection, but we also don't
      want to allow any scheduled code to run, KeyboardInterrupts to interupt the
      code, nor threads to switch.
  14. 26 Aug, 2016 1 commit
  15. 20 Jul, 2016 1 commit
    • Paul Sokolovsky's avatar
      py/gc: Implement GC running by allocation threshold. · 93e353e3
      Paul Sokolovsky authored
      Currently, MicroPython runs GC when it could not allocate a block of memory,
      which happens when heap is exhausted. However, that policy can't work well
      with "inifinity" heaps, e.g. backed by a virtual memory - there will be a
      lot of swap thrashing long before VM will be exhausted. Instead, in such
      cases "allocation threshold" policy is used: a GC is run after some number of
      allocations have been made. Details vary, for example, number or total amount
      of allocations can be used, threshold may be self-adjusting based on GC
      outcome, etc.
      This change implements a simple variant of such policy for MicroPython. Amount
      of allocated memory so far is used for threshold, to make it useful to typical
      finite-size, and small, heaps as used with MicroPython ports. And such GC policy
      is indeed useful for such types of heaps too, as it allows to better control
      fragmentation. For example, if a threshold is set to half size of heap, then
      for an application which usually makes big number of small allocations, that
      will (try to) keep half of heap memory in a nice defragmented state for an
      occasional large allocation.
      For an application which doesn't exhibit such behavior, there won't be any
      visible effects, except for GC running more frequently, which however may
      affect performance. To address this, the GC threshold is configurable, and
      by default is off so far. It's configured with gc.threshold(amount_in_bytes)
      call (can be queries without an argument).
  16. 30 Jun, 2016 2 commits
  17. 28 Jun, 2016 5 commits
  18. 12 May, 2016 2 commits
  19. 11 May, 2016 2 commits
  20. 27 Dec, 2015 1 commit
    • Paul Sokolovsky's avatar
      py/gc: Improve mark/sweep debug output. · 3ea03a11
      Paul Sokolovsky authored
      Previously, mark operation weren't logged at all, while it's quite useful
      to see cascade of marks in case of over-marking (and in other cases too).
      Previously, sweep was logged for each block of object in memory, but that
      doesn't make much sense and just lead to longer output, harder to parse
      by a human. Instead, log sweep only once per object. This is similar to
      other memory manager operations, e.g. an object is allocated, then freed.
      Or object is allocated, then marked, otherwise swept (one log entry per
      operation, with the same memory address in each case).
  21. 18 Dec, 2015 1 commit
    • Damien George's avatar
      py/gc: When printing info, use %u instead of UINT_FMT for size_t args. · acaccb37
      Damien George authored
      Ideally we'd use %zu for size_t args, but that's unlikely to be supported
      by all runtimes, and we would then need to implement it in mp_printf.
      So simplest and most portable option is to use %u and cast the argument
      to uint(=unsigned int).
      Note: reason for the change is that UINT_FMT can be %llu (size suitable
      for mp_uint_t) which is wider than size_t and prints incorrect results.
  22. 17 Dec, 2015 3 commits
  23. 02 Dec, 2015 1 commit
  24. 29 Nov, 2015 2 commits
  25. 07 Nov, 2015 1 commit
    • Dave Hylands's avatar
      py: Clear finalizer flag when calling gc_free. · 7f3c0d1e
      Dave Hylands authored
      Currently, the only place that clears the bit is in gc_collect.
      So if a block with a finalizer is allocated, and subsequently
      freed, and then the block is reallocated with no finalizer then
      the bit remains set.
      This could also be fixed by having gc_alloc clear the bit, but
      I'm pretty sure that free is called way less than alloc, so doing
      it in free is more efficient.