> > Something about the whole setup just feels wrong. GC shouldn't be this > > intrusive. And it definitely shouldn't slow down the common case by > > making the compiler defensively reload a buffer pointer every few > > instructions (it'll be cached, but it fouls up reordering.) > > Alright. Today I discovered tracked headers. :) > > What are wrong with these for hashtable buckets? These are headers, and > so are immobile. You can allocate lots of them without having to pay much > of a price in terms of instructions.
Well, for one, this isn't the intended use of these tracked headers. From my recent understading of how they should work: - They must be larger than a Buffer, and be a buffer header. - They will eventually get collected like regular headers. - They will be DOD'ed in the same manner as regular headers. All of which combines to mean that the above proposed use for tracked headers is incorrect. But perhaps there is a place for a small object allocator? Guidelines for it would be: non-moving (non-copying, non-compacting) one size per pool similar to tracked header support headers can be implemented on top of the small object allocator Hashtables, with a bunch of small buckets with pointers between them, could be implemented below buffer headers. They would avoid the overhead of a full buffer header per bucket, but would require the hashtable to maintain them manually (which thet current hashtable code does anyway, iirc). Pros: - not stuck with using headers for everything. keys could use a small object allocator (SOA) - see any traditional SOA for their advantages over generic memory pools Cons: - see previous email...cache coherency - see previous email...lack of automatic GC Any others? Thoughts on why we should/shouldn't implement this kind of thing in parrot, below the buffer level? Thanks, Mike Lambert PS: In case you're confused...yes, I was replying to myself. :)
