Leopold Toetsch <[EMAIL PROTECTED]> writes: > > 1) Freezing at the destruction level may *not* use any additional memory > > for object traversal
This is a really hard problem. In some early experiments with destruction ordering (one of the problems wich need iteration) I didn't get around with allocating new memory, or recursing on the stack. It may be that we can get arround with a second pointer, but I'm not sure. > What is "Freezing at the destruction level"? Is this anyhow related to > destruction ordering? > > > Note that I do *not* want to have multiple object traversal systems in > > parrot! We have one for DOD, and proposals have ranged upwards from there. > > No. That is *not* happening--the chance for error is significant, the > > side-effects of the error annoying and tough to track down for complex > > cases (akin to the trouble with tracking down GC issues), and just not > > necessary. (Perhaps desirable for speed/space reasons, but desirable > > isn't necessary) I did some benchmarking (to test our hash implementation, but thats a different story). One thing I found out: We are completely dominated by gc. I'm not sure if it was trace_systemareas or the mark method, but don't put any load on mark. mark should be as fast as possible. The other uses of traverse for freeze, dump, destruction-ordering etc. are all more or less called on user request, so the user needs to know its cost. One other thing that makes mark different. If we ever want to use a copying collector (Which is not reachable currently because of the conservative stack-walking) The mark routine needs to know about the moving of objects. All other traverse routine never get this problem. > DOD's mark() routine has different requirements then a general > traverse() for freeze(), chill(), clone(), and destruction ordering. > Using just mark() will have these side effects that you want to avoid. My words. mark() is not traverse() also they do similar things. > A general traverse() can be depth first of breadth first, mark() isn't > required do have any specific ordering as long as it sets live bits > everywhere. > > mark() is called permanently in a running interpreter, that does non > trivial things. There are shortcuts for scalars, DOD is highly optimized > not to destroy cache coherency. Using mark() also implies to back out > my small PMC patches. All the advantages of smaller scalars are gone > then. This ist just on more thing of mark() speed. > While freeze() and friends have to pull in each PMC into the cache, just > setting the live bit on a PMC hasn't. Further: Lukes proposal for > speeding up timely destruction puts objects either in front or at the > end of the next_for_GC chain. This IMHO implies that mark() is unusable > as your general and solely iterator. > > > ... This is something that's hidden under a number of layers > > of API, so regardless of the outcome it doesn't affect the assembly, PMC, > > or runtime API. > > So when its hidden, I really don't understand, why you are insisting on > an (IMHO) suboptimal design. We have at the moment 15 (in words fifteen) vtable slots for dividing/remainder, 5 for multiplikation, 24 for bitwise ops. So bloating the vtable is by design, but it is the end of world if we special case the most often called function and have 2 (in words two) walking functions. Sorry, I think there are other places in the vtable which need some cleanup. > > The thread-safety is an issue, > > While all schemes aren't thread-safe from user level (e.g. > manually sorting an array containing shared PMCs, while it gets > frozen), your scheme isn't thread-safe at low-level, as the next_for_GC > pointer inside the PMC is used as a duplicate marker. But if a user > changes shared resources its a user problem. We only guarantee atomic > updates per PMC (s. P6E p 86f by Dan). The thread safty is less a problem for marking. It only needs to make sure that other threads don't munge the data they are walking. Write barriers or mutexes might help here. But how to freeze an object of an other thread? This needs to freeze the whole thread. > > Dan > > Comments addressing all these issues are highly welcome, > leo I think we should address this issue like experimentalists: Create the general traverse function. (No don't call it mark). Implement freeze, dump, destruction ordering using this function. When this all is running, port the mark function to use this new functionality. Benchmark, and watch the speedup of the brandnew design (or just find out that the slowdown is not bad enough to satisfy two walking functions). When the benchmarking is done lets descide if we need only one walk-function, and only than remove the mark function. bye boe -- Juergen Boemmels [EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
