On Fri, Oct 18, 2013 at 6:50 AM, Bennie Kloosteman <[email protected]>wrote:
> On Fri, Oct 18, 2013 at 2:08 AM, Jonathan S. Shapiro <[email protected]>wrote: > >> On Thu, Oct 17, 2013 at 10:31 AM, Bennie Kloosteman >> <[email protected]>wrote: >> >>> On Thu, Oct 17, 2013 at 11:21 PM, Jonathan S. Shapiro >>> <[email protected]>wrote: >>> >>>> For objects that are immutable by virtue of their static type, the bit >>>> can be tucked in the vtable. Those bits are a lot cheaper. >>>> >>> >>> If its only 20 objects at a time you dont need this at all just lookup >>> the type .. Obviosuly for URC when you do a whole nursery its a diffirent >>> story.. >>> >> >> That was my first thought as well, but it doesn't work. The problem is >> that statically frozen objects aren't frozen until their constructor is >> done running. If the constructor allocates it can trigger a GC while the >> object is still mutable. If the object gets forwarded during that phase, >> things can get messed up, and it's a rare enough case that you'd spend the >> rest of your adult life hunting it down. >> > > Yes i thought there was no reference until the constructor is finished but > the issue is other objects moving which it references while its mutating > them. > Actually, I don't think other objects moving is the issue, but I had missed the fact that there is not outstanding reference until the constructor completes (except that it turns out there *can* be one, because the /this/ pointer can leak, which is why init-only fields are currently busted in CLR. > Also what about defaulting to shallow const on all objects which would > then freeze and thaw as needed. > Unfortunately that creates a race condition. Suppose I forward an immutable object. I don't force a read barrier, because they're both equally good. If somebody "upgrades" the object to mutable, I retroactively need a read barrier. Depending on the mechanism used to implement the read barrier, I may or may not be able to put one in place that flexibly. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
