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

On Jun 28, 3:33 pm, Lew <no...@lewscanon.com> wrote:


..

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) {...} }
}


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.


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]


/cf/Friz.jpg