Re: Why "lock" functionality is introduced for all the objects?
On 06/28/2011 02:23 PM,
supercalifragilisticexpialadiamaticonormalizeringelimatisticantations wrote:
On 28/06/2011 2:13 PM, Lew wrote:
Michal Kleczek wrote:
Lew wrote:
Show me the numbers. What penalty?
It is (almost) twice as much memory as it could be and twice as much GC
cycles. Almost because in real world the number of objects that you
need to
Nonsense. It's an extra 4 bytes per object. Most objects are much larger
than 4 bytes,
Bullpuckey, other than that a nontrivial object is always at least 12 bytes
So 4 bytes overhead is less than 100%, as I said.
due to Java's bloated object headers plus alignment. Ignoring that, it's quite
common to have lots of small objects at runtime -- from boxed primitives (4
bytes for most and 8 bytes for Longs and Doubles, plus object headers) to
short strings (two bytes per character plus four for the length field = 8 for
a two-letter word and 4 for an empty string -- again, plus object headers) and
Most strings in a typical program are non-empty and generally longer than two
bytes. A good percentage are interned. Strings in many runtime contexts
refer to substrings of those already in memory, saving overhead.
Integer objects make up a small fraction of most programs. Many Integer
instances are shared, especially if one follows best practices. Not a lot of
memory pressure there.
Double and Long, even fewer.
the occasional content-free pure-behavior object (abstract factories, strategy
pattern implementations, event listeners, plus most of the things you'd use an
anonymous inner class for ...). Small collections are a bit larger but an 8
byte object header is still likely to be a fair percentage; and their
What percentage is "fair"? Surely less than 100%, as I claim.
\
iterators may contain as little as a single integer index plus a single
pointer (ArrayList's likely does) and so be the same size as a Long or a Double.
And then there's all the objects with one or two reference type fields. Four
bytes each, on a 32-bit JVM. You can't count the "nested" objects' own sizes,
because they each have their own object header.
Objects with many fields are quite a bit rarer than ones with only one or two
fields. *Classes* with many fields are less common, and usually there will be
fewer live instances at runtime.
Ultimately, overhead fraction = average bytes directly in fields (at most 4
for most fields on 32-bit systems, excepting long and double primitive fields)
divided by header size, where the average is over a *typical population of
live objects in a running system* rather than over a set of, say, classes in
use in a system.
You show only that the overhead of 4 bytes per object is less than 100% of the
object's memory footprint, which is what I said.
Which footprint can be reduced by HotSpot, to the point of pulling an object
out of the heap altogether.
Where are the numbers? Everyone's arguing from speculation. Show me the numbers.
Real numbers. From actual runs. What is the overhead, really? Stop making
shit up.
Show me the numbers.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg