[Oberon] Fw: FPGA - Bitmaps.Mod

[Andreas Pirklbauer]

Yes, mainly to keep fragmentation low, but also to keep the code of the garbage collector reasonably simple. See ch. 8.2., p. 105, of the book "Project Oberon "at

https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf <https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf>

for a description of the properties of the heuristics used (i.e. using 4 lists instead of 1). Another benefit of the choice of values for the sizes of heap records (32, 64, 128, n*256) is that it permits the easy merging of any two contiguous elements into an element of the next list. This of course also helps keeping fragmentation low.

As for “holes": In Oberon there are no holes per se in the memory area between Kernel.heapOrg and Kernel.heapLim (the “heap”) - in the sense that *each and every* block in that space is either (i) “free” (mark < 0), (ii), allocated and unmarked (mark = 0), or (iii) allocated and marked (mark > 0). By convention, for each block p, Mem[p+4] is *defined* to be the mark field, which allows the scan phase of the garbage collector to actually recognize the free blocks as such. Heap blocks can become *fragmented* though - in the sense that the both free and allocated blocks can be "spread out" throughout the heap space.

------------------------------------

Tomas Kral thomas.kral at email.cz Wed Apr 19 16:38:11 CEST 2017
Hi,
Yes, I can see now.

Oberon maintains distinct chains of 32,64,128, and multiple 256 byte
blocks. With the idea to prevent holes and fragmentation?

Many thanks
Tomas

On Wed, 19 Apr 2017 15:48:27 +0200
Andreas Pirklbauer <andreas_pirklbauer at yahoo.com <https://lists.inf.ethz.ch/mailman/listinfo/oberon>> wrote:

> Tomas,
> 
> The "size" of the heap record, as specified in the type descriptor,
> needs to satisfy certain criteria, in order for Kernel.New to work:
> a) it must include 8 bytes for the two hidden fields 'mk' and 'tag'
> b) the total must be 32, 64, 128 or n*256 bytes long.
> 
> 
> See module Memory.Mod on 
> 
> https://github.com/andreaspirklbauer/Oberon-generic-heap-allocation <https://github.com/andreaspirklbauer/Oberon-generic-heap-allocation>
> 
> to see how this can be done (first three lines of procedures
> Memory.New).
> 
> It's essential (!) to set size correctly, otherwise the garbage
> collector gets confused, as becomes evident when studying the code
> for procedures Kernel.Mark and Kernel.Scan (which obtains the size if
> a heap record by inspecting the size field in the type descriptor).
> If it's not a valid size, Kernel.Scan will insert it in the "n*256"
> list without the record actually being a multiple of 256. Bad!
> 
> 
> [Oberon] Fw: FPGA - Bitmaps.Mod
> 
> Tomas Kral thomas.kral at email.cz 
> Wed Apr 19 12:53:09 CEST 2017
> Previous message: [Oberon] Fw: FPGA - Bitmaps.Mod
> Next message: [Oberon] FPGA - Naming Conventions
> Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> Hi Andreas, Joerg, I have tried both methods suggested here. (a)
> without tag declaration, simply calling Kernel.New(b.base,
> SYSTEM.ADR(b.size)); (b) with tag declaration and persistence
> tag.size := <size of your object to be allocated>; tag.ext[0] := 0;
> tag.ext[1] := 0; tag.ext[2] := 0; tag.ptr := -1; Kernel.New(b.base,
> SYSTEM.ADR(tag.size)) They both seem to allocate a block of requested
> size, however when GC is run, sometimes heap is inconsistent and
> `System.Watch' reports strange
> 
> Sent from my iPhone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20170419/dbdb9b1a/attachment.html>