On Sun, Oct 13, 2013 at 7:22 AM, Bennie Kloosteman <[email protected]>wrote:
> That may be, but the possibility of stuck counts is likely a *good* thing >> from a concurrency scaling perspective. >> > > Possibly are you saying this because the stuck counts is a bit test or > because they are ignored ? i think this is 50/50 they were forced into > the cap by reusing the field but it doesnt match with there asertion that > nearly all counts are < 5. > It's good because once the count is stuck, no further increment/decrement behavior happens. It is the increment/decrement behavior that causes concurrency contention. They didn't explore highly concurrent programs, so I don't think there is any conflict between what I am saying and what they are saying about count demographics. In abstract, if you have a lot of threads installing counted references to the same object, you are likely looking at a problem that is inherently unscalable. The exception is references taken locally for *read* operations. Those are exactly the ones that benefit from "known live pointer" analysis. > Normal Jikes header is 16 bytes ( 32 bit) so adding a field would go to > 17or 20 .. and im not sure what happens to the object alignment , > paragraph alignment for header and body are nice . Obviously if the cost > went from 11 bytes to 12 it would have a lower impact . > The jikes header already has room for the stuff we are talking about. There is no need to add a byte. > Yes. Which is why you put the count bits in the least significant position >> of some aligned header word. :-) >> > > I know ,still need to mask it though or check for overflow . and you need > to make sure its 100% concurrent... > if ( abc.header & 0x8 != 5) > LOCK INCL abc.header; > But with deferred reference counting, most of these evaporate, and they can be applied by the collector itself. > Ok use overflow bit , so you have bit set and tst . Tricky.. > Nope. You have add, mask, and store. > I dont know if the <5 is common is because most objects are short lived > though... or whether long lived objects also have ref counts < 5. > Very few objects have long-term ref counts >2. There just aren't many data structures with a high in-degree. The objects that *do* have higher ref counts are the ones that are held for a long time by references coming from the stack. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
