1. 12 Jan, 2015 1 commit
  2. 11 Jan, 2015 1 commit
  3. 08 Jan, 2015 1 commit
  4. 07 Jan, 2015 1 commit
  5. 01 Jan, 2015 2 commits
  6. 05 Nov, 2014 1 commit
  7. 31 Oct, 2014 1 commit
  8. 24 Oct, 2014 1 commit
  9. 23 Oct, 2014 2 commits
  10. 17 Oct, 2014 1 commit
  11. 16 Oct, 2014 1 commit
  12. 15 Oct, 2014 1 commit
  13. 28 Aug, 2014 2 commits
    • Damien George's avatar
      py, gc: Further reduce heap fragmentation with new, faster gc alloc. · 516b09ef
      Damien George authored
      The heap allocation is now exactly as it was before the "faster gc
      alloc" patch, but it's still nearly as fast.  It is fixed by being
      careful to always update the "last free block" pointer whenever the heap
      changes (eg free or realloc).
      
      Tested on all tests by enabling EXTENSIVE_HEAP_PROFILING in py/gc.c:
      old and new allocator have exactly the same behaviour, just the new one
      is much faster.
      516b09ef
    • Damien George's avatar
      py: Reduce fragmentation of GC heap. · b796e3d8
      Damien George authored
      Recent speed up of GC allocation made the GC have a fragmented heap.
      This patch restores "original fragmentation behaviour" whilst still
      retaining relatively fast allocation.  This patch works because there is
      always going to be a single block allocated now and then, which advances
      the gc_last_free_atb_index pointer often enough so that the whole heap
      doesn't need scanning.
      
      Should address issue #836.
      b796e3d8
  14. 22 Aug, 2014 1 commit
    • Damien George's avatar
      py: Speed up GC allocation. · d5e7f6e3
      Damien George authored
      This simple patch gives a very significant speed up for memory allocation
      with the GC.
      
      Eg, on PYBv1.0:
      tests/basics/dict_del.py: 3.55 seconds -> 1.19 seconds
      tests/misc/rge_sm.py:     15.3 seconds -> 2.48 seconds
      d5e7f6e3
  15. 08 Aug, 2014 1 commit
    • Damien George's avatar
      py: Fix bug where GC finaliser table was not completely zeroed out. · a1d3ee37
      Damien George authored
      This was a nasty bug to track down.  It only had consequences when the
      heap size was just the right size to expose the rounding error in the
      calculation of the finaliser table size.  And, a script had to allocate
      a small (1 or 2 cell) object at the very end of the heap.  And, this
      object must not have a finaliser.  And, the initial state of the heap
      must have been all bits set to 1.  All these conspire on the pyboard,
      but only if your run the script fresh (so unused memory is all 1's),
      and if your script allocates a lot of small objects (eg 2-char strings
      that are not interned).
      a1d3ee37
  16. 03 Jul, 2014 1 commit
  17. 01 Jul, 2014 1 commit
  18. 21 Jun, 2014 1 commit
  19. 18 Jun, 2014 2 commits
  20. 16 Jun, 2014 1 commit
  21. 13 Jun, 2014 2 commits
  22. 05 Jun, 2014 1 commit
  23. 10 May, 2014 1 commit
  24. 03 May, 2014 1 commit
    • Damien George's avatar
      Add license header to (almost) all files. · 04b9147e
      Damien George authored
      Blanket wide to all .c and .h files.  Some files originating from ST are
      difficult to deal with (license wise) so it was left out of those.
      
      Also merged modpyb.h, modos.h, modstm.h and modtime.h in stmhal/.
      04b9147e
  25. 26 Apr, 2014 1 commit
  26. 25 Apr, 2014 2 commits
    • Damien George's avatar
      py, gc: Zero out newly allocated blocks in the GC. · daab651c
      Damien George authored
      Also add some more debugging output to gc_dump_alloc_table().
      
      Now that newly allocated heap is always zero'd, maybe we just make this
      a policy for the uPy API to keep it simple (ie any new implementation of
      memory allocation must zero all allocations).  This follows the D
      language philosophy.
      
      Before this patch, a previously used memory block which had pointers in
      it may still retain those pointers if the new user of that block does
      not actually use the entire block.  Eg, if I want 5 blocks worth of
      heap, I actually get 8 (round up to nearest 4).  Then I never use the
      last 3, so they keep their old values, which may be pointers pointing to
      the heap, hence preventing GC.
      
      In rare (or maybe not that rare) cases, this leads to long, unintentional
      "linked lists" within the GC'd heap, filling it up completely.  It's
      pretty rare, because you have to reuse exactly that memory which is part
      of this "linked list", and reuse it in just the right way.
      
      This should fix issue #522, and might have something to do with
      issue #510.
      daab651c
    • Damien George's avatar
  27. 20 Apr, 2014 4 commits
  28. 09 Apr, 2014 1 commit
  29. 08 Apr, 2014 1 commit
  30. 05 Apr, 2014 2 commits