640409 - Optimize List<> to have all empty lists share a single stub ListData

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Virtual Machine, defect)

Description

[Steven Johnson]

To avoid null checks everywhere, List<> assumes that m_data is never null; however, this means that empty lists must pre-emptively allocate. Instead, perhaps we could allocate a single chunk of memory that would serve as the universal empty-list ListData, meaning empty lists (and list ctor execution) would be essentially free.

Comment 1

[Steven Johnson]

I toyed with implementing this, but the stumbling block I ran into is that the shared ListData needs to hold a GC*... so I can't just make it static data. The only global-ish reference passed in is a GC*, so we'd have to hang the empty-stub off of it somehow... which is an invasion of specialization I'm sure the GC guys would not approve of. Yuck.

Comment 2

[Tommy Reilly]

You could store the empty list pointer in AvmCore and get the AvmCore from the GC context variable mechanism.

Comment 3

[Steven Johnson]

Oh, do we still support that? That would work I guess. What's the overhead of loading via that mechanism?

Comment 4

[Tommy Reilly]

low.  its just indexing an array with a constant.

Comment 5

[Lars T Hansen]

(In reply to comment #3)
> Oh, do we still support that? That would work I guess. What's the overhead of
> loading via that mechanism?

It's still supported.  The API is a trifle bizarre IIRC, I don't know why "indexing with a constant" is needed when a simple type-safe accessor would have seemed more appropriate.

Comment 6

[Steven Johnson]

er, so why don't we do that everywhere?

Comment 7

[Lars T Hansen]

(In reply to comment #6)
> er, so why don't we do that everywhere?

I don't have an answer to that question, but presumably there aren't any advantages to replace working mechanisms (passing the GC, passing the toplevel) with a different mechanism just for the sake of changing the code.  Plus, there can be multiple toplevels per avmcore so sometimes the core won't be enough, I guess.