Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail
From: BGB <cr88192@hotmail.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: Why "lock" functionality is introduced for all the objects?
Date: Tue, 28 Jun 2011 14:30:10 -0700
Organization: albasani.net
Lines: 44
Message-ID: <iudhca$jcf$1@news.albasani.net>
References: <d0bb9e06-16f0-4282-a37e-47e9ca9630ec@r2g2000vbj.googlegroups.com> <iuce66$2nh$1@news.albasani.net> <iud083$2jr$1@news.onet.pl> <iud1u5$f4r$1@news.albasani.net> <iud4f6$lcm$1@news.onet.pl> <iud5js$nno$1@news.albasani.net> <iud66f$8al$1@speranza.aioe.org> <J5KdnRBP4eYkvZfTnZ2dnUVZ_jqdnZ2d@earthlink.com> <iud80u$ci0$2@speranza.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.albasani.net vtCtAC7582d+M7aED0kFjn2XeexblWq4X3YwwNF0p8VfYhm571RwzxAoPHw47cWo1rOQZs3Odbvann0dberQFm4jejh4URRpoECk6YKfSkaIuo+xTHzsVO9H8Ca2F6yV
NNTP-Posting-Date: Tue, 28 Jun 2011 21:34:02 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="27G+qakr/FLwd8umHHrDmNsVzPM4WPIaVcmyz6t7jr9XSZNE3S9d5N1tEFATPacH/b4jbdUIJ/ujpyNx9THJyL4KWqoM+D+BI7ScQE1VvLeqhGwxoWsEJXo5R3/oYwPn"; mail-complaints-to="abuse@albasani.net"
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
In-Reply-To: <iud80u$ci0$2@speranza.aioe.org>
Cancel-Lock: sha1:mqhmXCZBP1p64fB6J/LclbJ4R6k=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5755

On 6/28/2011 11:54 AM, 
supercalifragilisticexpialadiamaticonormalizeringelimatisticantations wrote:
> On 28/06/2011 2:42 PM, Patricia Shanahan wrote:
>> Each String instance has the following fields:
>>
>> private final char value[];
>> private final int offset;
>> private final int count;
>> private int hash;
>>
>> There are 12 bytes in addition to the char array. The offset and count
>> fields allow quick sub-string construction, and hash is used to cache
>> the hashCode result.
>
> Oh, geez, even *more* overhead. And let's not forget the array has its
> own separate object header and length field!


going OT:

these sorts of issues were one reason why in my own VM and 
custom-designed language, string types are built into the VM. this 
allows somewhat reducing the costs of storing a string (but, yes, many 
more string operations are O(n), such as getting the length or accessing 
a character by index...).

many other types are built into the VM, and it also has "fixnum" and 
"flonum" types (basically, where an integer or floating-point value is 
encoded directly into the pointer, via tagging magic, allowing avoiding 
the overhead of using object-based boxes).

as-is though, the per-object memory cost is a little steep though 
(creating a simple class instance will take around 48 bytes, mostly 
header overhead...), partly related to some fancy features supported by 
the OO facilities (and maintaining isolation between the OO facilities 
and the GC, adding a layer of GC memory-object-headers).

partly it is not as big of a killer though, as most common small types 
are built directly into the VM, rather than existing as classes or 
instances.


or such...