523582 - Incorrect free list management in GCHeap

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Garbage Collection (mmGC), defect, P2)

Description

[Lars T Hansen]

Instrumentation shows that the last free list (the one reserved for large blocks) ends up holding a number of smaller blocks.  During one run of ATS the distribution of sizes (in number of blocks) in the last free list was this:

  29: count=53 volume=37144K
     3 29 32 32 33 33 33 33 33 33 33 33 33 33 33 34 34 34 34 34 34 35 35 35 35 35 36 36 36 36 36 36 37 38 39 40 46 47 48 49 50 54 55 55 56 57 58 64 68 81 100 145 7045

Yet this list should be reserved for blocks of size at least 128.  This is not a critical leak because in practice most of the small blocks are coalesced with other free blocks and end up moving off this list in time, but it's a bug nonetheless.

Comment 1

[Tommy Reilly]

I think you'll find those are decommitted blocks, this is by design, we want to consume committed free blocks before getting to decommitted ones, look for "back of the bus" in the code.

Comment 2

[Lars T Hansen]

I'm looking at that code right now, and it doesn't make a whole lot of sense to me yet.  What/where is the logic that ensures that those blocks are moved off a list where they won't be found by an allocation request?

Comment 3

[Tommy Reilly]

Alloc searches from a starting pointer determined by size to the request to the end of the freelist

Comment 4

[Lars T Hansen]

That probably makes sense, but instrumentation shows that many of the free lists have some uncommitted blocks on them after a sufficiently long run.  So I question the consistency of the approach - based on what you write above, uncommitted blocks should end up in the last free list so that we bias against them, yet they do appear elsewhere.

Comment 5

[Lars T Hansen]

What we have probably works - since coalescing of committed/uncommitted blocks during allocation does not pay attention to free list structure - but it requires a rethink.  If it's true that all decommitted blocks should be in the last free list then there's no need to be looking for decommitted blocks when searching the smaller free lists (and indeed uncommitted blocks may usefully be off on their own list entirely?)  However decommitted blocks definitely end up in the other free lists at this time, AllocBlock places them there when it splits a large uncommitted block into a smaller committed part and an uncommitted tail.

Comment 6

[Tommy Reilly]

for the future I imagined the memory in the committed blocks themselves would be used to thread the freelists (because the HeapBlocks would be gone) and we can keep decommitted blocks separate.

Comment 7

[jewellery]

I have a problem when I run .\platform\win32\obj_9\shell\Debug_Debugger\avm.exe hello.abc(windows)

flash.utils:IDataInputAssertion failed:"((!"a URI that is used in unversioned form must not later be used in versioned form"))" (“..\\..\\core\\AvmCore.cpp”:5376)
avmplus crash:exception 0x80000003 occurred

why?

Comment 8

[Felix S. Klock II [:pnkfelix, :fklock]]

(In reply to jewellery from comment #7)
> I have a problem when I run
> .\platform\win32\obj_9\shell\Debug_Debugger\avm.exe hello.abc(windows)
> 
> flash.utils:IDataInputAssertion failed:"((!"a URI that is used in
> unversioned form must not later be used in versioned form"))"
> (“..\\..\\core\\AvmCore.cpp”:5376)
> avmplus crash:exception 0x80000003 occurred
> 
> why?

I don't know.  But its probably unrelated to this Bugzilla ticket.

I would recommend posting a new bug report, including all of the following:

* The revision number of tamarin-redux you are building from
* The version number of asc.jar you used to build hello.abc
* The actual file for hello.abc
* If possible, the source for hello.as

If you need help with the process, you can contact me in the short term, or in the longer term, the tamarin-devel mailing list:
  https://mail.mozilla.org/listinfo/tamarin-devel
might be a good place to ask for assistance.