Some more ideas ( i will think more deeply when i impliment it and understand all the limitations)
1. You could isolate cases where objects have a low number of references this creates a very narrow scope of change eg if an object only has 1 reference you can put a guard on the source object ( or even just the 4k around the field ) and move it . This will prevent it going on the stack or anywhere. 2. Use non closed heap areas ( asuming the heap can be divided , note they dont need to be closed but we do need to avoid frequent changes ie identify loops/ recursions ) and note which mutators have access to which regions ( eg when they change it is noted in a similar manner to ref counting eg lazy release so frequent changes dont incur a huge cost) ..if the from /to reference is not one of those areas for current mutators than they cant move , mutators will stall/spin when a region they request is unavailable due to a move. Basically a low cost ( CPU time not dev time) form of locking, trying to take advantage of the fact that some threads have very narrow allocations and dont really need to be stopped. 3. If you are using a mark sweep Nursery you have global pauses ( at least for the stack check even if using a non shared nursery) .. these may be small but provide a good opportunity to move the worst offenders. Ben Hmm. No, that's not quite it, because a reference could bounce back and > forth between two CPUs via the heap and this won't necessarily catch that > case. Darn. I really hate to put a forwarding check in the store barrier... > > OK. I don't have it yet. > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
