Steve Fink wrote:
On Dec-31, Leopold Toetsch wrote:
I think, it moves the problems just around with a lot of overhead. E.g. cloning a PerlArray of 10^6 entries would need 1000 generations
I don't understand. The outer clone belongs to generation N. Then if
you called clone() individually on each PMC within the array, then by
default you wouldn't create any more generations at all.
Ah, ok. I thougt that at each dod run a new generation is started. But you seem to manage generation count manually.
I'm not convinced that's ever possible. What if an object overrides
its clone()?
The vtable->clone in core.ops would be surrounded by my proposed do_dod_run/block_DOD, so the clone function could be anything.
Wait. Dumb question: is clone a shallow or deep copy?
Deep and recursive. BTW recursively marking was declined becaus of stack usage - what about clone?
By rearraning code and disabling DOD during clone (when needed), it should be possible to avoid walking the processor stack/regs alltogether.
Yes, I'm hoping there's some solution where things that have full knowledge of what might happen can make use of it and gain speed in the common case, while there's still a safe mechanism for things that are too difficult or impossible to predict in advance. So we can start with the easy approach, and then optimize them into the more detailed approach if needed. Or something. My hands are getting tired from all the waving around.
I think its time to do some coding. leo
