Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #5724 > unrolled thread

Why "lock" functionality is introduced for all the objects?

Back to article view | Back to comp.lang.java.programmer

Contents

  Why "lock" functionality is introduced for all the objects? Alex J <vstrength@gmail.com> - 2011-06-28 02:29 -0700
    Re: Why "lock" functionality is introduced for all the objects? Lew <noone@lewscanon.com> - 2011-06-28 07:33 -0400
      OT "sic" (was Re: Why "lock" functionality is introduced for all the objects? blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-06-28 15:56 +0000
        Re: OT "sic" (was Re: Why "lock" functionality is introduced for all the objects? Lew <noone@lewscanon.com> - 2011-06-28 12:19 -0400
      Re: Why "lock" functionality is introduced for all the objects? Michal Kleczek <kleku75@gmail.com> - 2011-06-28 18:41 +0200
        Re: Why "lock" functionality is introduced for all the objects? Lew <noone@lewscanon.com> - 2011-06-28 13:10 -0400
          Re: Why "lock" functionality is introduced for all the objects? Michal Kleczek <kleku75@gmail.com> - 2011-06-28 19:53 +0200
            Re: Why "lock" functionality is introduced for all the objects? Lew <noone@lewscanon.com> - 2011-06-28 14:13 -0400
              Re: Why "lock" functionality is introduced for all the objects? supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-06-28 14:23 -0400
                Re: Why "lock" functionality is introduced for all the objects? Lew <noone@lewscanon.com> - 2011-06-28 14:33 -0400
                  Re: Why "lock" functionality is introduced for all the objects? supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-06-28 14:52 -0400
                    Re: Why "lock" functionality is introduced for all the objects? Lew <noone@lewscanon.com> - 2011-06-28 16:20 -0400
                      Re: Why "lock" functionality is introduced for all the objects? supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-06-29 00:53 -0400
                        Re: Why "lock" functionality is introduced for all the objects? Lew <noone@lewscanon.com> - 2011-06-29 01:04 -0400
                          Re: Why "lock" functionality is introduced for all the objects? supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-06-29 01:43 -0400
                Re: Why "lock" functionality is introduced for all the objects? Patricia Shanahan <pats@acm.org> - 2011-06-28 11:42 -0700
                  Re: Why "lock" functionality is introduced for all the objects? supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-06-28 14:54 -0400
                    Re: Why "lock" functionality is introduced for all the objects? Patricia Shanahan <pats@acm.org> - 2011-06-28 12:34 -0700
                      Re: Why "lock" functionality is introduced for all the objects? markspace <-@.> - 2011-06-28 13:20 -0700
                        Re: Why "lock" functionality is introduced for all the objects? Patricia Shanahan <pats@acm.org> - 2011-06-28 13:44 -0700
                      Re: Why "lock" functionality is introduced for all the objects? supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-06-29 01:05 -0400
                    Re: Why "lock" functionality is introduced for all the objects? Lew <noone@lewscanon.com> - 2011-06-28 16:21 -0400
                      Re: Why "lock" functionality is introduced for all the objects? supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-06-29 01:06 -0400
                    Re: Why "lock" functionality is introduced for all the objects? BGB <cr88192@hotmail.com> - 2011-06-28 14:30 -0700
            Re: Why "lock" functionality is introduced for all the objects? Robert Klemme <shortcutter@googlemail.com> - 2011-06-29 18:56 +0200
        Re: Why "lock" functionality is introduced for all the objects? BGB <cr88192@hotmail.com> - 2011-06-28 13:43 -0700
          Re: Why "lock" functionality is introduced for all the objects? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-28 20:43 -0400
            Re: Why "lock" functionality is introduced for all the objects? BGB <cr88192@hotmail.com> - 2011-06-28 21:14 -0700
          Re: Why "lock" functionality is introduced for all the objects? supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-06-29 01:12 -0400
            Re: Why "lock" functionality is introduced for all the objects? Joshua Maurice <joshuamaurice@gmail.com> - 2011-07-01 18:28 -0700
              Re: Why "lock" functionality is introduced for all the objects? supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-02 00:19 -0400
            Re: Why "lock" functionality is introduced for all the objects? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-07-01 19:05 -0700
              Re: Why "lock" functionality is introduced for all the objects? supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-02 00:26 -0400
              Re: Why "lock" functionality is introduced for all the objects? BGB <cr88192@hotmail.com> - 2011-07-04 09:39 -0700
                Re: Why "lock" functionality is introduced for all the objects? supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-05 02:11 -0400
      Re: Why "lock" functionality is introduced for all the objects? Alex J <vstrength@gmail.com> - 2011-07-05 16:56 -0700
        Re: Why "lock" functionality is introduced for all the objects? "John B. Matthews" <nospam@nospam.invalid> - 2011-07-06 00:57 -0400
        Re: Why "lock" functionality is introduced for all the objects? supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-06 05:55 -0400
        Re: Why "lock" functionality is introduced for all the objects? Alex Shabanov <avshabanov@gmail.com> - 2011-08-02 05:05 -0700
    Re: Why "lock" functionality is introduced for all the objects? Lew <noone@lewscanon.com> - 2011-06-28 14:40 -0400
    Re: Why "lock" functionality is introduced for all the objects? Robert Klemme <shortcutter@googlemail.com> - 2011-06-29 19:15 +0200
    Re: Why "lock" functionality is introduced for all the objects? Tom Anderson <twic@urchin.earth.li> - 2011-06-30 23:04 +0100
      Re: Why "lock" functionality is introduced for all the objects? KitKat <kitkat_11697@gmail.example.com> - 2011-06-30 18:29 -0400
        Re: Why "lock" functionality is introduced for all the objects? Patricia Shanahan <pats@acm.org> - 2011-06-30 17:05 -0700
          Re: Why "lock" functionality is introduced for all the objects? KitKat <kitkat_11697@gmail.example.com> - 2011-06-30 20:17 -0400
            Re: Why "lock" functionality is introduced for all the objects? Tom Anderson <twic@urchin.earth.li> - 2011-07-01 21:22 +0100
        Re: Why "lock" functionality is introduced for all the objects? Tom Anderson <twic@urchin.earth.li> - 2011-07-01 21:40 +0100
          Re: Why "lock" functionality is introduced for all the objects? KitKat <kitkat_11697@gmail.example.com> - 2011-07-01 18:08 -0400
            Re: Why "lock" functionality is introduced for all the objects? BGB <cr88192@hotmail.com> - 2011-07-05 12:15 -0700
              Re: Why "lock" functionality is introduced for all the objects? KitKat <kitkat_11697@gmail.example.com> - 2011-07-05 15:30 -0400
                Re: Why "lock" functionality is introduced for all the objects? blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-05 21:10 +0000
                  Re: Why "lock" functionality is introduced for all the objects? BGB <cr88192@hotmail.com> - 2011-07-05 22:08 -0700
                  Re: Why "lock" functionality is introduced for all the objects? KitKat <kitkat_11697@gmail.example.com> - 2011-07-06 05:57 -0400
                    Re: Why "lock" functionality is introduced for all the objects? blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-06 17:07 +0000
                      Re: Why "lock" functionality is introduced for all the objects? Steve Erwin <trollHunter@Usenet.4.usenetizens.org.invalid> - 2011-07-07 04:08 +1000
                        Re: Why "lock" functionality is introduced for all the objects? blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-06 19:09 +0000
                          Re: Why "lock" functionality is introduced for all the objects? Steve Erwin <trollHunter@Usenet.4.usenetizens.org.invalid> - 2011-07-07 09:26 +1000
                            Re: Why "lock" functionality is introduced for all the objects? KitKat <kitkat_11697@gmail.example.com> - 2011-07-06 20:25 -0400
                              Re: Why "lock" functionality is introduced for all the objects? blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-07 19:37 +0000
                            Re: Why "lock" functionality is introduced for all the objects? blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-07 19:35 +0000
                              Re: Why "lock" functionality is introduced for all the objects? Steve Erwin <trollHunter@Usenet.4.usenetizens.org.invalid> - 2011-07-07 14:34 -0700
                                OT names/nyms/etc. (was Re: Why "lock" functionality is introduced for all the objects?) blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-08 17:19 +0000
                                  Re: OT names/nyms/etc. (was Re: Why "lock" functionality is introduced for all the objects?) Steve Erwin <trollHunter@Usenet.4.usenetizens.org.invalid> - 2011-07-09 05:41 +1000
                                    Re: OT names/nyms/etc. (was Re: Why "lock" functionality is introduced for all the objects?) blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-08 19:58 +0000
                                      Re: OT names/nyms/etc. (was Re: Why "lock" functionality is introduced for all the objects?) lewbloch <lewbloch@gmail.com> - 2011-07-08 13:45 -0700
                                        Re: OT names/nyms/etc. (was Re: Why "lock" functionality is introduced for all the objects?) Steve Erwin <trollHunter@Usenet.4.usenetizens.org.invalid> - 2011-07-10 01:50 -0400
                                          Re: OT names/nyms/etc. (was Re: Why "lock" functionality is introduced for all the objects?) blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-10 19:15 +0000
                                          Re: OT names/nyms/etc. (was Re: Why "lock" functionality is introduced for all the objects?) KitKat <kitkat_11697@gmail.example.com> - 2011-07-10 18:38 -0400
                                    Re: OT names/nyms/etc. (was Re: Why "lock" functionality is introduced for all the objects?) KitKat <kitkat_11697@gmail.example.com> - 2011-07-09 00:29 -0400
                                Re: Why "lock" functionality is introduced for all the objects? KitKat <kitkat_11697@gmail.example.com> - 2011-07-09 00:26 -0400
                        Re: Why "lock" functionality is introduced for all the objects? KitKat <kitkat_11697@gmail.example.com> - 2011-07-06 20:05 -0400
                          Re: Why "lock" functionality is introduced for all the objects? Steve Erwin <trollHunter@Usenet.4.usenetizens.org.invalid> - 2011-07-07 10:24 +1000
                            Re: Why "lock" functionality is introduced for all the objects? KitKat <kitkat_11697@gmail.example.com> - 2011-07-06 21:52 -0400
                              Re: Why "lock" functionality is introduced for all the objects? Steve Erwin <trollHunter@Usenet.4.usenetizens.org.invalid> - 2011-07-07 12:43 +1000
                                Re: Why "lock" functionality is introduced for all the objects? KitKat <kitkat_11697@gmail.example.com> - 2011-07-06 23:00 -0400
      Re: Why "lock" functionality is introduced for all the objects? Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 20:27 -0400
      Re: Why "lock" functionality is introduced for all the objects? Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 20:30 -0400
        Re: Why "lock" functionality is introduced for all the objects? Henderson <h1@g1.f1> - 2011-07-22 00:20 -0400
          Re: Why "lock" functionality is introduced for all the objects? Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 10:17 -0400
            Re: Why "lock" functionality is introduced for all the objects? Patricia Shanahan <pats@acm.org> - 2011-07-22 09:30 -0700
              Re: Why "lock" functionality is introduced for all the objects? Patricia Shanahan <pats@acm.org> - 2011-07-22 09:45 -0700
              Re: Why "lock" functionality is introduced for all the objects? Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 14:53 -0400
        Re: Why "lock" functionality is introduced for all the objects? v_borchert@despammed.com (Volker Borchert) - 2011-07-22 04:39 +0000
          Re: Why "lock" functionality is introduced for all the objects? Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 10:19 -0400
    Re: Why "lock" functionality is introduced for all the objects? Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 20:33 -0400
      Re: Why "lock" functionality is introduced for all the objects? Patricia Shanahan <pats@acm.org> - 2011-07-21 21:08 -0700
        Re: Why "lock" functionality is introduced for all the objects? Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 10:20 -0400

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#5763

On 28/06/2011 3:34 PM, Patricia Shanahan wrote:
> 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!
>
> The array may be shared by several String objects.

It usually won't be. Really, how often does anyone use .substring except 
for a very short-lived object that usually is fed directly into 
StringBuilder.append() or something that calls that under the hood, or 
else to an I/O write operation?

> In general, many trade-offs in Java, not just the decision to make every
> object capable of being a lock, assume that other considerations are
> more important than minimizing memory use. For example, caching the hash
> code pays four bytes per String in order to have a hash code that
> depends on the entire string, without paying the cost of calculating it
> repeatedly when a String is used as a hash table key.

Funnily enough, using four characters (if there are that many, else the 
whole string) from near the middle of the string would probably work 
nearly as well, even for the fairly common cases of many strings sharing 
a common prefix, suffix, or both. Strings with highly regular middles 
and variable ends are not very common by contrast. And what does that 
require?

int mid = length >> 1; // emphasizing that a cheap shift op works
int start = max(mid-2,0);
int end = min(mid+2, length);
int hash = 0;
int fct = 1;
for (int i = start; i < end; ++i) {
     hash += fct*content[i];
     fct *= 256;
}

For the common case of Latin-1 strings this turns the characters there 
into the hash bytes directly. Throw in some unicode characters and it 
gets a bit more interesting as the characters may affect two bytes of 
the hash each, except the last one of the four.

Of course, they could also have used a smarter caching strategy. When is 
hash caching useful? When the string's in a hash map and going to be 
looked up in it frequently. But this turns into two subcases:

1. The string already in the hash map is the same *object* as the
    string used for lookup.
2. The strings are not the same object, though they have the same
    content.

In the latter case, the string passed to get() is obviously not interned 
and is probably being constructed anew each time, likely from I/O reads. 
Caching its hash is useless since it's going to be GC'd and recreated 
sans cached hash. In the former case, the string probably *is* interned, 
in which case the smart place for the hash cache is in the *string 
interning table* rather than in the individual string objects, 
particularly if you could arrange the under-the-hood implementation to 
use an int[] to hold *all* the hashes instead of separate int fields all 
over the system.

> If, for your purposes, minimal memory use is very important, you may
> want to consider other languages with other trade-offs.

And here I thought they were trying to heavily push Java for use on 
mobile phones and other devices with limited memory.

[toc] | [prev] | [next] | [standalone]

#5751

On 06/28/2011 02:54 PM, 
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!

Much less than 50% of the object size here is for monitors.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#5764

On 28/06/2011 4:21 PM, Lew wrote:
> On 06/28/2011 02:54 PM,
> supercalifragilisticexpialadiamaticonormalizeringelimatisticantations
> wrote:
>> Oh, geez, even *more* overhead. And let's not forget the array has its
>> own
>> separate object header and length field!
>
> Much less than 50% of the object size here is for monitors.

Whoosh! Lew misses my point again, by a country mile no less. What a 
surprise.

[toc] | [prev] | [next] | [standalone]

#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...

[toc] | [prev] | [next] | [standalone]

#5776

On 28.06.2011 19:53, Michal Kleczek wrote:
> Lew wrote:
>
>> On 06/28/2011 12:41 PM, Michal Kleczek wrote:
>>> Lew wrote:
>>>
>>>> Alex J wrote:

<snip/>

> Yet in the end the community seems to agree not to use "synchronized"
> directly but rather use classes from java.util.concurrent (namely Lock and
> Condition). So is this keyword really that important?

Where do you take that from?  I know at least two cases from my recent 
development history where it came in extremely handy that all objects 
have a monitor.  In those cases where there were a lot of objects stored 
and we needed to synchronize on each individual object to prevent a 
bottleneck and allow scalability a solution using an implementation of 
java.util.concurrent.locks.Lock almost certainly would have used 
significantly more memory.

<snip/>

>> 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
> synchronize on is way lower than the number of all objects you create.

I'd say that heavily depends on the application type.  I don't think 
such a general statement is warranted.

<snip/>

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#5753

On 6/28/2011 9:41 AM, Michal Kleczek wrote:
> Lew wrote:
>
>> Alex J wrote:
>>> I'm curious why Java designers once decided to allow every object to
>>> be lockable (i.e. [sic] allow using lock on those).
>>
>> Because that makes it possible to do concurrent programming intrinsically.
>>
>
> Could you elaborate more on that?
> Do you mean there is no other way to do it?
>
> I find this question quite intriguing as well since it looks quite useless
> for example to be able to lock on java.lang.Integer instance (and it is
> strange for me that java.lang.Integer instance occupies much more memory as
> int). Surely a compromise must have been done taking into account various
> language features ("synchronized" keyword, lack of multiple inheritance,
> lack of closures) - but I am not that knowlegeable enough to explain this
> compromise in detail.
>

yeah...

they made every object lockable but not every object cloneable, where 
one would think cloning would be generally a higher priority.


I guess the alternative would require, say:
class Foo implements Lockable
{
	...
}

or at least:
synchronized class Foo
{
}
although this could be confusing/misleading.


>>> I know, that out of such a design decision every Java object contain
>>> lock index, i.e. new Object() results in allocation of at least 8
>>> bytes where 4 bytes is object index and 4 bytes is lock index on 32-
>>> bit JVM.
>>> I think that it just inefficient waste of space, because not all the
>>> objects requires to be lockable/waitable.
>>
>> Well, that's your opinion.
>>
>
> It is not only his opinion - the size of object header is important
> especially on memory constrained devices. But not only - there is a reason
> why UseCompressedOops flag was introduced in 64 bit HotSpot JVM.
>


there are also other possible implementation strategy (used in my own 
VM) where as opposed to a fixed per-object overhead, lock/wait/... are 
implemented internally via a magic table:
locked objects may be added to a table, and waiting threads may be 
suspended and added to a second table linked to the object in the first;
when a status change occurs, then the waiting threads are woken up, at 
which point they may do whatever (perform the operation, try to lock the 
object again, ...), and if they try to lock the object again and can't 
get a lock right away, then they go back to sleeping.

this strategy trades off some performance for not having to store 
per-object lock state (especially given this is a relatively rare 
operation IME).


>>> The better decision, IMHO, would be to introduce lock/wait mechanics
>>> for only, say, the Lockable descendants.
>>
>> Oh, yeah, your opinion is humble.
>>
>>> The current approach seems to be very simple, but is the performance
>>> penalty so small for not be taken into an account?
>>
>> Yes.  Nonexistent, really.
>>
>
> I wouldn't say so - see:
> http://wikis.sun.com/display/HotSpotInternals/CompressedOops
> Especially the sentence:
> "Memory is pretty cheap, but these days bandwidth and cache is in short
> supply"
>

yeah...

another bigger problem though is when one has multiple memory-hungry 
apps compete for the available memory (say, one has several apps each 
eating 1GB-3GB of RAM, and one only has 4GB), and one is left "computing 
at the speed of swap" especially when one only has 5400RPM drives...

in this case, smaller programs perform faster, as even when the rest of 
the system is bogged down with "the red HD light of doom", the app still 
keeps going ok mostly because its smaller footprint is like prone to 
getting swapped out, and because when it does get swapped, it can also 
pull things back in from disk much faster.

[toc] | [prev] | [next] | [standalone]

#5756

On 6/28/2011 4:43 PM, BGB wrote:
> [...]
> they made every object lockable but not every object cloneable, where
> one would think cloning would be generally a higher priority.

	class MySingleton implements Cloneable {
	    // What's wrong with this picture?
	}

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#5759

On 6/28/2011 5:43 PM, Eric Sosman wrote:
> On 6/28/2011 4:43 PM, BGB wrote:
>> [...]
>> they made every object lockable but not every object cloneable, where
>> one would think cloning would be generally a higher priority.
>
> class MySingleton implements Cloneable {
> // What's wrong with this picture?
> }
>

makes about as much sense as the ability to lock every object, including 
those where locking is not exactly sane or useful...

to be strictly sensible, one would have to do something special for 
lockable objects as well as cloneable ones...


it is like in ActionScript, which requires a special modifier for 
dynamic objects, even though one could allow people to freely shove 
custom fields and methods into instances of any object.

it made more sense to support non-dynamic objects as well, and actually 
have these as the default case (whereas it probably would have been less 
effort implementation-wise to simply only have dynamic objects and 
optimize the non-dynamic use cases).


or such...

[toc] | [prev] | [next] | [standalone]

#5765

On 28/06/2011 4:43 PM, BGB wrote:
> yeah...
>
> they made every object lockable but not every object cloneable, where
> one would think cloning would be generally a higher priority.

If they'd been smarter about managing mutability to begin with (e.g. 
fields immutable by default, objects normally immutable) cloning would 
not be a priority at all.

Sure, the boxed primitives and Strings are immutable, and that's about 
it. We've got mutable stuff out the wazoo, most of which probably 
shouldn't be -- java.util.Date, anyone? Not to mention java.awt.Point 
and friends. All those conundrums about whether Square should be a 
subclass of Rectangle, or Circle of Ellipse, go away if they aren't 
mutable. Then they clearly are subclasses. Mutable collections and 
arrays also make type reasoning more complicated and don't allow casting 
a List<Sub> to a List<Super> as then you might add a non-Sub Super to 
the list. If the list wasn't mutable there'd be no problem casting a 
List<Sub> to a List<Super>.

I could go on...but I won't.

[toc] | [prev] | [next] | [standalone]

#5816

On Jun 28, 10:12 pm,
supercalifragilisticexpialadiamaticonormalizeringelimatisticantations
<supercalifragilisticexpialadiamaticonormalizeringelimatisticantati...@averylongandannoyingdomainname.com>
wrote:
> On 28/06/2011 4:43 PM, BGB wrote:
>
> > yeah...
>
> > they made every object lockable but not every object cloneable, where
> > one would think cloning would be generally a higher priority.
>
> If they'd been smarter about managing mutability to begin with (e.g.
> fields immutable by default, objects normally immutable) cloning would
> not be a priority at all.
>
> Sure, the boxed primitives and Strings are immutable, and that's about
> it. We've got mutable stuff out the wazoo, most of which probably
> shouldn't be -- java.util.Date, anyone? Not to mention java.awt.Point
> and friends. All those conundrums about whether Square should be a
> subclass of Rectangle, or Circle of Ellipse, go away if they aren't
> mutable. Then they clearly are subclasses. Mutable collections and
> arrays also make type reasoning more complicated and don't allow casting
> a List<Sub> to a List<Super> as then you might add a non-Sub Super to
> the list. If the list wasn't mutable there'd be no problem casting a
> List<Sub> to a List<Super>.
>
> I could go on...but I won't.

If you want a functional language, go use a functional language and
stop complaining that Java is not a functional language.

[toc] | [prev] | [next] | [standalone]

#5818

On 01/07/2011 9:28 PM, Joshua Maurice wrote:
> On Jun 28, 10:12 pm,
> supercalifragilisticexpialadiamaticonormalizeringelimatisticantations
> <supercalifragilisticexpialadiamaticonormalizeringelimatisticantati...@averylongandannoyingdomainname.com>
>> Sure, the boxed primitives and Strings are immutable, and that's about
>> it. We've got mutable stuff out the wazoo, most of which probably
>> shouldn't be -- java.util.Date, anyone? Not to mention java.awt.Point
>> and friends.
>
> If you want a functional language, go use a functional language and
> stop complaining that Java is not a functional language.

Contrary to popular belief, immutability is not solely useful in a 
functional language. In fact, OO languages benefit greatly if their 
"value types" (things you're likely to want to use as hash keys and to 
generally represent state) are immutable.

[toc] | [prev] | [next] | [standalone]

#5817

On 6/28/2011 10:12 PM, 
supercalifragilisticexpialadiamaticonormalizeringelimatisticantations wrote:
> If the list wasn't mutable there'd be no problem casting a
> List<Sub> to a List<Super>.

And then I'd complain because my program would be spending more time 
copying the values between immutable queues than actually doing work. As 
long as the language has the potential for mutable collections (which 
most people want for performance reasons), you have the potential for 
generics casting issues.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#5819

On 01/07/2011 10:05 PM, Joshua Cranmer wrote:
> On 6/28/2011 10:12 PM,
> supercalifragilisticexpialadiamaticonormalizeringelimatisticantations
> wrote:
>> If the list wasn't mutable there'd be no problem casting a
>> List<Sub> to a List<Super>.
>
> And then I'd complain because my program would be spending more time
> copying the values between immutable queues than actually doing work. As
> long as the language has the potential for mutable collections (which
> most people want for performance reasons), you have the potential for
> generics casting issues.

Lists are, in my experience, typically constructed, then consumed; only 
infrequently is a mutable one maintained with recurring episodes of 
reading and writing over time. The common case could have been optimized 
with better support than the various Collections.unmodifiableFoo() 
methods provide. For example, if you could tag a list as not modifiable 
the compiler can both disallow writing through it and allow casting from 
UnmodifiableList<Sub> to UnmodifiableList<Super>. We kinda have that now 
in that we can cast List<Sub> to List<? extends Super> and then the 
compiler will indeed not let us add to it, but <? extends Super> is both 
awkward and not equal to Super. A lot of methods might be written to 
demand a List<Super> even if they won't modify the list, and will thus 
work with a List<? extends Super>. More generally it complicates 
generics. The fact of the matter is that <? extends X> is like of like 
"unmodifiable, and also <X>", at least for collections; a more clear way 
of (separately) expressing "unmodifiable" would have been nice.

So, basically, what I'm saying is that we should have had some notion of 
constness in Java. :)

[toc] | [prev] | [next] | [standalone]

#5854

On 7/1/2011 7:05 PM, Joshua Cranmer wrote:
> On 6/28/2011 10:12 PM,
> supercalifragilisticexpialadiamaticonormalizeringelimatisticantations
> wrote:
>> If the list wasn't mutable there'd be no problem casting a
>> List<Sub> to a List<Super>.
>
> And then I'd complain because my program would be spending more time
> copying the values between immutable queues than actually doing work. As
> long as the language has the potential for mutable collections (which
> most people want for performance reasons), you have the potential for
> generics casting issues.
>

well, and probably putting more pressure on the garbage collector.

a great downside of using an FP-like style with a GC and a language/VM 
that generally lacks the concept of user-defined value-types is that it 
increases the amount of garbage produced (thus increasing the number of 
GC cycles).

a language with 'struct' need not have this issue, as then they can use 
it for implementing such value types.

but, I have seen cases where people have abused struct (mostly in C#), 
generally using references-to-struct for things which would probably 
have been better done with a heap-allocated class instance.


in my own personal language, it may be possible to create structs using 
a constructor and using 'final' on fields to create an immutable struct.


or such...

[toc] | [prev] | [next] | [standalone]

#5858

On 04/07/2011 12:39 PM, BGB wrote:
> On 7/1/2011 7:05 PM, Joshua Cranmer wrote:
>> On 6/28/2011 10:12 PM,
>> supercalifragilisticexpialadiamaticonormalizeringelimatisticantations
>> wrote:
>>> If the list wasn't mutable there'd be no problem casting a
>>> List<Sub> to a List<Super>.
>>
>> And then I'd complain because my program would be spending more time
>> copying the values between immutable queues than actually doing work. As
>> long as the language has the potential for mutable collections (which
>> most people want for performance reasons), you have the potential for
>> generics casting issues.
>
> well, and probably putting more pressure on the garbage collector.

Typical immutable usage-patterns create more pressure in one single 
predominant way: by producing more very-short-lived temporaries holding 
intermediate values. Assuming the JIT doesn't optimize those out of the 
heap altogether, they will die in edenspace which generally makes them 
extremely cheap (as the gc cost to clean up edenspace is proportional 
only to the number of survivors, not the number of dead objects). Where 
they can be a bit less cheap is that heap space requirements to avoid 
more major collections may be higher.

> a great downside of using an FP-like style with a GC and a language/VM
> that generally lacks the concept of user-defined value-types is that it
> increases the amount of garbage produced (thus increasing the number of
> GC cycles).

Don't forget that the JIT can optimize local temporary objects that 
escape analysis shows never leave the method scope (or have their 
identity hash code needed) into being defacto "value type" objects 
instead of heap objects.

[toc] | [prev] | [next] | [standalone]

#5877

On Jun 28, 3:33 pm, Lew <no...@lewscanon.com> wrote:
> Alex J wrote:
> > I'm curious why Java designers once decided to allow every object to
> > be lockable (i.e. [sic] allow using lock on those).
>
> Because that makes it possible to do concurrent programming intrinsically.

What I tried to say is that other design approaches make it possible
too.
IMO it is not that hard to write, say

(1)
public class SyncObj implements Lockable {
 public sychronized void foo() {...}

 public void bar() { synchronized (this) {...} }
}

(2)
public class ObjWithLock {
 private SimpleLock lock = new SimpleLock();

 public void bar() { synchronized (lock) {...} }
}

>
> > I know, that out of such a design decision every Java object contain
> > lock index, i.e. new Object() results in allocation of at least 8
> > bytes where 4 bytes is object index and 4 bytes is lock index on 32-
> > bit JVM.
> > I think that it just inefficient waste of space, because not all the
> > objects requires to be lockable/waitable.
>
> Well, that's your opinion.
>
> > The better decision, IMHO, would be to introduce lock/wait mechanics
> > for only, say, the Lockable descendants.
>
> Oh, yeah, your opinion is humble.

sorry for looking naive, but I'm trying to get in-depth knowledge,
that's why I asked this question.
Of course I didn't kept in mind that Java designers introduced
inefficient approach and my (or whoever else) option is the best.

>
> > The current approach seems to be very simple, but is the performance
> > penalty so small for not be taken into an account?
>
> Yes.  Nonexistent, really.

Several days ago I tried to figure out how much is the overhead
introduced by boxing operation.
Consider the following two classes, Foo and Bar, defined as follows:

public class Foo {
    private int a;

    private int b;

    public int getA() {
        return a;
    }

    public void setA(int a) {
        this.a = a;
    }

    public int getB() {
        return b;
    }

    public void setB(int b) {
        this.b = b;
    }

    @Override
    public String toString() {
        return "Bar#{ a = " + a + ", b = " + b + " }";
    }
}

public class Bar {
    private int a;

    private Integer b; // this is the only difference between Bar and
Foo.

    public int getA() {
        return a;
    }

    public void setA(int a) {
        this.a = a;
    }

    public Integer getB() {
        return b;
    }

    public void setB(Integer b) {
        this.b = b;
    }


    @Override
    public String toString() {
        return "Bar#{ a = " + a + ", b = " + b + " }";
    }
}


Then try to allocate 1000000 of each and put it to an array:

    public static final int ARR_SIZE = 1000000;

    private static void printMemUsage(String checkpoint) {
        System.out.println(MessageFormat.format("Mem usage at {0}:
total={1}, free={2}",
                checkpoint, Runtime.getRuntime().totalMemory(),
Runtime.getRuntime().freeMemory()));
    }

    private static void testBarAlloc() throws IOException {
        printMemUsage("enter testBarAlloc");

        final Bar[] barChunk = new Bar[ARR_SIZE];

        final long before = System.currentTimeMillis();

        for (int j = 0; j < ARR_SIZE; ++j) {
            final Bar bar = new Bar();
            bar.setA(-j);
            bar.setB(1 + j);
            barChunk[j] = bar;
        }

        final long total = System.currentTimeMillis() - before;
        System.out.println(MessageFormat.format("Bar alloc done; total
time: {0}", total));
        printMemUsage("bar alloc iteration");
        // ......
    }


On 32-bit Sun JVM 1.6.0_24 on my Mac OS X 10.6 I got approx 32000000
bytes overhead in case of using Bar (with Integer field) what in its
turn proves, that using Integer instead of int results in extra 32
bytes allocation per each object.

I may only guess that probably lock monitors also contributes to this
overhead but I can't figure out how much.
I've no option to run JVM with option that switches off lock
functionality completely out of language and internal object layout.

If I write the same by using plain C, I'd come up with the following
representation:

struct Integer {
 struct IntegerVptr * vmt; // pointer to virtual methods table

 int intValue;
}

struct Foo {
 struct FooVptr * vmt;

 int a;
 Integer * b;
}

comparing to

struct Bar {
 struct BarVptr * vmt;

 int a;
 int b;
}

we have 8 bytes overhead per each Foo instance (in case of
preallocating all the necessary object or by using the special purpose
fixed-size allocator).

Keeping in mind the difference C vs Java implementation I can only
speculate on how much lock functionality contributes to that overhead.

[snip]

>
> --
> Lew
> Honi soit qui mal y pense.http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#5880

In article 
<3d0a7034-5e01-476c-926d-1b99ab071357@x12g2000yql.googlegroups.com>,
 Alex J <vstrength@gmail.com> wrote:

> On 32-bit Sun JVM 1.6.0_24 on my Mac OS X 10.6

FYI: <http://support.apple.com/kb/DL1360>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[toc] | [prev] | [next] | [standalone]

#5889

On 05/07/2011 7:56 PM, Alex J wrote:
> public class Foo {
>      private int a;
>
>      private int b;

...

>
> public class Bar {
>      private int a;
>
>      private Integer b; // this is the only difference between Bar and
> Foo.

...

> using Integer instead of int results in extra 32
> bytes allocation per each object.

WTF? I'd have expected 12: 8 for the Integer's object header and 4 for 
its int field, the b fields in both Foo and Bar being 4 bytes so no 
change there.

Somewhere there's an extra 20 bytes per Bar or even per Integer being 
gobbled up.

[toc] | [prev] | [next] | [standalone]

#6738

On Jul 6, 3:56 am, Alex J <vstren...@gmail.com> wrote:
>...
> Keeping in mind the difference C vs Java implementation I can only
> speculate on how muchlockfunctionalitycontributes to that overhead.

BTW, if someone is still interested in the overhead:

$ANDROID_SOURCES/dalvik/vm/oo/Object.h introduces the following layout
behind the Object class:

typedef struct Object {
    /* ptr to class object */
    ClassObject*    clazz;

    /*
     * A word containing either a "thin" lock or a "fat" monitor.  See
     * the comments in Sync.c for a description of its layout.
     */
    u4              lock;
} Object;

So the memory overhead is known (and it is +4 bytes for all the
Objects no matter if they ever locked or not).

As for HotSpot JVM it is not that easy to find the distinctive layout
of the Object class.

>
> [snip]
> > --
> > Lew
> > Honi soit qui mal y pense.http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#5743

On 06/28/2011 01:33 PM, Stefan Ram wrote:
> Alex J<vstrength@gmail.com>  writes:
>> What do you think of it?
>
>    I do not think, but use a web search engine and find:
>
> http://c2.com/cgi/wiki?JavaObjectOverheadIsRidiculous

Refers to Java 1.2.2.  Things have changed significantly since then, including 
the loss of a word from object pointers.

> http://www.trevorpounds.com/blog/?p=351
>
>    . And here is a rationale given for why every object has a lock:
>
> http://forums.oracle.com/forums/thread.jspa?threadID=1140765
>
>    , that is, so that one can use »synchronized« on object
>    methods (which stands for »synchronized( this )«).

It is evident that Java's design introduces overhead.  Duh.  But it's not the 
wild claim of 100% overhead.  That's just stupid.

How much that overhead is in practice depends on HotSpot and what idioms would 
be needed to replace the lost feature of inbuilt synchronization.

Given that Java's design does introduce a cost, the question remains - for 
what benefit?  We give up some memory - did we save on developer cost?  Did we 
save on runtime crashes?  Did HotSpot optimize away the unused cruft?

We need to know the real numbers.  How much does Java's design cost an actual 
program, and what would it have cost that program to have lacked that design 
feature?

People are throwing around terms like "bloated" but only focusing on half the 
cost-benefit analysis, picking numbers out of their butts, and exaggerating 
those numbers to boot.  That can only lead to suboptimal decisions.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web