On Mon, Oct 14, 2013 at 5:57 PM, Jonathan S. Shapiro <[email protected]>wrote:
> Okay. So now for concurrent object forwarding. That is: forwarding > performed by a collector while the mutator is active. > > The first think to say is that I don't think a read barrier is sufficient. > All of the counting operations and optimizations look to me like they can > be done by a write barrier. Forwarding is very different. The problem as I > noted before, is that the mutator may perform reads from the wrong location > while forwarding is underway, and there is really no effective way to > compile this problem out. > ...if page-protection is in the mix, another option is similar to the C4 route. Before evacuating a block, read/write protect it. On fault, check if the object is relocated. If not, relocate it immediately (since it must be alive); either way, perform the read/write operation against the new location. A read-barrier at the time of loading pointer references tests their relocation state, and automatically fixes the source of the loaded reference if necessary, to avoid repeated faults for the same source data. (this is basically an on-demand remap. they call it a LVB=loaded-value-barrier, but if I understand it correctly it's more of a reference-load-read-barrier) Compared to (1) "page fault fail" strategy, the above strategy guarantees progress. Compared to (2) "page-fault code-translator-interpreter", the above strategy is much simpler. One could argue that the C4/LVB approach is somewhat related to (3) "nacl-like code emission". Both of them eat-address space by swizzling top-bits for other purposes. Though C4/LVB swizzles to store relocation state, manually updating pointers to new addresses during relocation. Though I admit I don't understand how you intend to apply an NACL like scheme to make "block remapping not necessary". I'm interested to know what you are thinking here. (4) "always use dynamic binary translation", I don't really understand. It sounds like #2. Except that if it happens all the time, where does the "dynamic" part come in? (5) again sounds like #2, but using soft-rendezvous instead of page faulting... which is nice if you want to avoid MMU dependencies.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
