Vladimir Lipsky <[EMAIL PROTECTED]> wrote: >> From: "Leopold Toetsch" <[EMAIL PROTECTED]>
>> Seems that we got a problem on alphas then. I can see several solutions >> to accomodate such CPUs: > From my point of view, these solutions have the following merits and > demerits: >> - use only PMCs that don't cross cache lines > +) No need for memory barriers to preserve the order of read and write > operations > +) Lock-free read access, and thus, no CPU perfomance degradation > -) This would bloat the PMC size Not necessarily. It doesn't mean, that we blow up a PMC to 32 byte on i386. It means that when putting an arenas worth of PMCs onto the freelist, we could skip PMCs where str_val and vtable would cross cache-line boundaries. When such PMCs are then marked as being on the freelist they wouldn't cause a problem during DOD. It just wastes some memory by not using these PMCs. >> - lock all string vtable access > +) No need for memory barriers, since operating system's locking mechanisms > all have implied those > -) Acquiring a lock is a damn waste of time, the acquiring CPU is forced to > stall until the lock is released and reaches its cache. String functions are rather slow. As long as we have the copying GC, they need a lock on reading anyway. >> - move string pointer into PMC_EXT > +-) Being a nice idea on the whole, it's a lop-sided variant concerning the > other data primitives that a PMC can hold > -) It will break the current implementation of perstring.pmc, sarray.pmc, > scalar.pmc, and probably other code and pmc classes Strings did hang off PMC_data() not too long ago. Changing that wasn't much work. > -) Besides that I might expect that there are more disvantages Its a slowdown too. The PMC_EXT structures has to be allocated from its freelist. > 0x4C56 leo
