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. Yeah, you could manage this by progressively bumping the VTable pointer, but I think that a [logical] bit flip is cleaner. Implementing the bit by having two copies of the VTable (one for RO objects and the other for RW objects) would work fine. That would let you move the bit into the VTable's RTTI word, where it's not in a performance critical place. > Hmm. For that matter, you could simply use VTable pairs for dynamically RO >> objects (one indicating RO, the other indicating RW). >> > > I was thinking of this for DB objects as well. > Yup. Once the rabbit's out in the open, you start noticing how fluffy and delicious looking it is. :-) shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
