In the 32-bit CLR, the overhead is a syncblk and type handle, each 4 bytes. See ObjectInstance: http://msdn.microsoft.com/en-us/magazine/cc163791.aspx#S7
In Java, the situation is similar. Here's a quick blog entry mentioning it, though I originally researched it elsewhere: http://kohlerm.blogspot.com/2008/12/how-much-memory-is-used-by-my-java.html Clearly I meant the overhead of my code is 8 bytes/token. The tokens "long" values held in an array. Sam -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Johannes Luber Sent: Thursday, December 02, 2010 6:09 AM To: Terence Parr; [email protected] Cc: [email protected] Subject: Re: [antlr-dev] Alternative token storage mechanisms ; > > > > Memory – CommonToken (32-bit system): > > · 8 bytes overhead for being a class > > · 36 bytes overhead for member variables > > > > Memory – CommonToken (64-bit system): > > · 16 bytes overhead for being a class (I believe that’s the > object header size) > > · 44 bytes overhead for members IIRC, the object header part is merely a pointer to the type information, so I'm kinda surprised to see 8 bytes / 16 bytes instead 4 bytes / 8 bytes. You sure you measured correctly? > > > > Memory – SlimToken (32- or 64-bit systems): > > · 8 bytes total storage, and no allocations since it’s a > value type. > > Being pedantic here :), but value types still allocate memory. Usually on the stack, unless they are part of a class, which allocates them on the heap. Johannes -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail _______________________________________________ antlr-dev mailing list [email protected] http://www.antlr.org/mailman/listinfo/antlr-dev _______________________________________________ antlr-dev mailing list [email protected] http://www.antlr.org/mailman/listinfo/antlr-dev
