> 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. >
They did consider it and JIkes allows extra test field but adding 4 bytes gave worse performance ( probably because going from 16 to 17 （ = 20) and stuffing up the allignment , then the way i read it they only had a few bits left so didnt test higher values just 5 for the 3 bits they had. Checked... Shahriya explored this and states that the capping provides a very minor improvement and the gain was made almost entirely by not using a new header field. Every header field has a significant cost they conclude... ( prob affected by Java small objects like Point and higher creation/copying costs , which also makes me think C++ no header and some bits in the pointer or for 64 bit have an option to use 32 bit pointers for higher performance but 4G heap else use 96 bit pointers ) . BTW When 1 field is 2-3 % (on Java) what is the "managed" overhead for having an object header ? Did they test this for the C++ runtime type system ( which went with putting it in the vtable) ? > >> >>> > >> Ok use overflow bit , so you have bit set and tst . Tricky.. >> > > Nope. You have add, mask, and store. > I suspect on value type system a seperate field is much faster as unlike Java you dont have the header cost on everything. If you can find a byte or word in the header ( or reference) and use non mask instruction that would be ideal. Anyway lots of testing...just the basics yet alone the storage ,tracer etc Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
