"Steve Fink (via RT)" wrote: > > # New Ticket Created by Steve Fink > # Please include the string: [netlabs #574] > # in the subject line of all future correspondence about this issue. > # <URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=574 > > > Here's the ultimate point of that flurry of patches. This implements > hashtables, albeit with some... arguable implementation decisions. > > These hashtables accept only keys as strings, but natively store all > sorts of various types as values (in other words, not just PMCs). > > The straightforward implementation using the preexisting memory > management code would have required seven separately addressable wads > of memory. With the sized buffer pools, these hashtables use five: > 1 The PMC > 2 The overall hashtable header (a subclass of a Buffer) > 3 An array of pointers to buckets, stored in the above header's bufstart > 4 A Buffer header for the pool of buckets themselves > 5 The array of available buckets > > The array of pointers to buckets could be stored in the same buffer as > the buckets themselves, reducing the total number of objects to three, > but then there would be two very different beasts pointed to by the > same Buffer header subclass, complicating the addressing, so I opted > to keep them separate. The costs would be less for a hashtable that > stored only PMC*'s, however. > > The most potentially controversial attribute of these hashtables is > the use of direct memory pointers to and between the buckets. These > pointers are invalidated every time buffers are compacted, so at the > beginning of every public entry point, restore_invariants() is called. > It checks to see if the buckets have moved (they're the only things > pointed to directly), and if so, they are swept through and adjusted > to the new position. The same routine is used to resize the table when > it reaches 80% full. It's very similar to the DOD sweep phase. > > I tried using indexes for everything, but they cluttered the code too > much and it got hard to tell what was going on. But it would probably > be faster that way. > > This patch requires all of my recently posted patches except for the > cleanup patch. It will compile and even appear to work if you leave > out the sized buffer pool patch, but if you turn on GC_DEBUG it will > break very quickly.
Many thanks. We should be able to get somewhere now... Applied. -- Jeff <[EMAIL PROTECTED]>
