question on memory allocation and class instance

[Jimmy Zhang]

hi, I have a couple of questions that I would like someone to take a look,
1. java.lang.Object is the super class for all, does that mean a simple
instantiation of any class
will automatically create a java.lang.Object instance, so any simple object
allocation will create
at least two classes.

2. In Java, if I want to allocate a memory block of 1M, does the JVM have to
ensure the existence
of such memory block, even it has to join and recombine smaller blocks. Is
it more expensive with
a GC enabled language than C/C++

Thanks,
Jimmy

 

[Tony Morris]

hi, I have a couple of questions that I would like someone to take a look,
1. java.lang.Object is the super class for all, does that mean a simple
instantiation of any class
will automatically create a java.lang.Object instance, so any simple object
allocation will create
at least two classes.

You have some reading to do.
The answer is no, but not because there is the possibility that the answer
could be yes.
The reason the answer is no is because the question has no context.
The term "object allocation will create at least two classes." makes
absolutely no sense.

Do you "typewriters eat cauliflower spaghetti car window divided under forty
dinosaurs" ?
The answer is no, because the question makes no sense.

2. In Java, if I want to allocate a memory block of 1M, does the JVM have to
ensure the existence
of such memory block, even it has to join and recombine smaller blocks. Is
it more expensive with
a GC enabled language than C/C++

Again, impossible to answer.
Have you tried to "allocate a memory block of 1M" ?
You can't have, since it makes no sense in the context of the Java 2
Programming Language.

http://java.sun.com/tutorial
Good luck !

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Jimmy Zhang]

Don't know what you are trying to get across, in particular, I have tried to
allocate a block of 1MB, didn't have
any problem in Java1, or 2.
What is the context are you trying to have?
I am just asking if a single allocation of one object will in fact return
two object, one of them linked to java.lang.Object?
Your comment is nevertheless weird and interesting.

 

[Tony Morris]

I am just asking if a single allocation of one object will in fact return

two object, one of them linked to java.lang.Object?

This is completely out of context - it makes no sense at all.


Post the source code where you believe you have allocated a memory block of
1MB.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Woebegone]

Don't know what you are trying to get across, in particular, I have tried to
allocate a block of 1MB, didn't have
any problem in Java1, or 2.
What is the context are you trying to have?
I am just asking if a single allocation of one object will in fact return
two object, one of them linked to java.lang.Object?
Your comment is nevertheless weird and interesting.

blocks.

Hi Jimmy,

Every object in Java is ... an Object. Allocation (instantiation) via new
creates and returns a reference to one object. Java's intrinsic polymorphism
means that the object may be referenced as an instance of any class it
extends (including Object) or of any interface it implements, as well as its
own static type. One object, potentially many types.

As for your question about memory allocation, Java doesn't allow such an
operation. You can allocate objects, whose size might approximate 1MB, but
that (the size) is not up to you as a programmer to determine. Of course,
you could I suppose guess that "new byte[1000000]" would allocate about 1MB,
but that's not the same as e.g. a "malloc(1000000)" since Java has no
equivalent of a void*. Is that what you're driving at? Once you have that
MB, you can't share it around if things get tight for your program. Also,
although polymorphic, Java is very strongly typed, so there's no way to cast
your byte[] into e.g. a Widget. This is part of the reason your original
question lacked context.

If you're thinking of simply having your program claim an arbitrary hunk of
heap memory "just in case," you might look at the -Xms flag for the JVM.

HTH, Regards,
Sean.

 

[Chris Uppal]

hi, I have a couple of questions that I would like someone to take a look,
1. java.lang.Object is the super class for all, does that mean a simple
instantiation of any class
will automatically create a java.lang.Object instance, so any simple
object allocation will create
at least two classes.

As Tony Moris said, you are having difficulty with the terminology which makes
it difficult to understand your question.

If what you are asking is "does creating an instance of a subclass of Object
automatically create an instance of Object too ?" then the answer is no. Each
instance of a subclass contains slots to hold the fields it inherits from its
superclasses, as well as the slots needed for the fields defined in that class,
so -- in a very loose sense -- it contains the superclass "object" nested
within it. But there is only one object.

If that isn't what you meant then I suggest you ask again.

2. In Java, if I want to allocate a memory block of 1M, does the JVM have
to ensure the existence
of such memory block, even it has to join and recombine smaller blocks. Is
it more expensive with
a GC enabled language than C/C++

If you ask for -- say -- an array of a million bytes, then its up to the Java
runtime to try to find the memory to satsify the request. *How* it does that
is implementation-dependent, but common implementation techniques would involve
doing a GC if the memory isn't immediately available. That is implementation
dependent too, but common GC techniques have the effect of compacting memory so
that available smaller blocks would be swept up into a larger single block.

There is really no way to compare the "expense" with C/C++ here, since C has
explicit pointers there is no (normal) way for the memory subsystem to move
allocated blocks around at runtime. Hence C malloc() cannot shuffle the heap
to remove fragmentation. (I'm sure it'd be possible to create a C
implementation that used an extra level of indirection in it's "pointers" to
allow such reshuffling, but that largely defeats the point of using C in the
first place, and I'm not aware of any such implementations).

BTW, there is nothing to say that the byte[1000000] has to be allocated in a
contiguous chunk by the Java runtime. It could be -- say -- allocated as a
number of unrelated 16K chunks. There is no way to tell using Java (or even
JNI) whether the runtime does that. I don't know of any implementations that
*do* do it, but there *might* be some -- it might make sense on
resource-restricted devices for instance, especially if they don't use a
compacting GC.

-- chris

 

[Albert Deinbeck]

hi, I have a couple of questions that I would like someone to take a look,
1. java.lang.Object is the super class for all, does that mean a simple
instantiation of any class
will automatically create a java.lang.Object instance, so any simple object
allocation will create
at least two classes.

2. In Java, if I want to allocate a memory block of 1M, does the JVM have to
ensure the existence
of such memory block, even it has to join and recombine smaller blocks. Is
it more expensive with
a GC enabled language than C/C++

Thanks,
Jimmy

Hi Jimmy,
I would like to try and clear up some misconceptions you seem to have.
1. One class has multiple instances. The class holds the methods, the
instance the variables.
2. java.lang.Object only defines methods, so nothing is added to child class
instances. (as far as I know ?)
3. java.lang.Object class exists only once (per classloader). All other
classes refer to it. Again, this reference is in the class, not in every
instance.
4. If java.lang.Object would define variables, they would be part of every
class instance.
5. The parent classes of a class do not produce seperate instances. If you
have A extends B extends C and you create new A() you get 1 (one) object,
not 3 refering to each other.

6. You cannot allocate a memory block of 1M. You can make an object which
can hold the same data as a 1M block can.
byte[1000000] is not guaranteed to be a block of 1M. It is guaranteed to
refer to 1000000 primitives of type 'byte'.
7.The VM is free to allocate an array in one block or in several pieces. You
cannot predict what the VM will do.
8. There is no such thing as a pointer in java. myArray[123] is NOT
*(myArray+123*sizeof(Element))
9. Java GC is more expensive than C/C++ in terms of runtime. However, it is
much more secure in terms of memory leaks.

Albert

 

[Thomas Richter]

Hi,

There is really no way to compare the "expense" with C/C++ here, since C has
explicit pointers there is no (normal) way for the memory subsystem to move
allocated blocks around at runtime. Hence C malloc() cannot shuffle the heap
to remove fragmentation. (I'm sure it'd be possible to create a C
implementation that used an extra level of indirection in it's "pointers" to
allow such reshuffling, but that largely defeats the point of using C in the
first place, and I'm not aware of any such implementations).

FYI, and as a side remark, early versions of MacOs did just that. The
corresponding construct was called "a handle", and the kernel (the
memory manager) reshuffled the heap when required. All that in C (or
in pascal).

So long,
Thomas

 

[Tim Ward]

FYI, and as a side remark, early versions of MacOs did just that. The
corresponding construct was called "a handle", and the kernel (the
memory manager) reshuffled the heap when required. All that in C (or
in pascal).

Likewise early versions of Windows.

 

[Chris Uppal]

FYI, and as a side remark, early versions of MacOs did just that. The
corresponding construct was called "a handle", and the kernel (the
memory manager) reshuffled the heap when required.

Interesting, thanks.

And I could add that more modern OSs' virtual memory systems are "really" doing
something very similar, for all it's done in hardware rather than by the
compiler.

-- chris

 

[Tony Morris]

1. One class has multiple instances. The class holds the methods, the

instance the variables.

eh ?
Do you mean "The class defines methods, instance members, static members,
constructors, inner classes, and initialisers" ?

9. Java GC is more expensive than C/C++ in terms of runtime. However, it is
much more secure in terms of memory leaks.

This is somewhat subjective, rather than factual.
I encounter memory leaks in Java applications more often than you might
think.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Jimmy Zhang]

Sean, Yes, that is what I am looking for.
Thanks for the insight!
However, despite the difference between Java and C, the JVM will totally
honor the request by allocating a 1-meg block
even it means that JVM has to search and recombine smaller blocks to get to
this 1MB.
I was told that allocating this 1MB doesn't mean that JVM would guarantee
every part of this 1MB is allocated, which I disagree. What is your take on
this?
Jimmy

Don't know what you are trying to get across, in particular, I have

tried

to
allocate a block of 1MB, didn't have
any problem in Java1, or 2.
What is the context are you trying to have?
I am just asking if a single allocation of one object will in fact return
two object, one of them linked to java.lang.Object?
Your comment is nevertheless weird and interesting.

blocks.

Hi Jimmy,

Every object in Java is ... an Object. Allocation (instantiation) via new
creates and returns a reference to one object. Java's intrinsic polymorphism
means that the object may be referenced as an instance of any class it
extends (including Object) or of any interface it implements, as well as its
own static type. One object, potentially many types.

As for your question about memory allocation, Java doesn't allow such an
operation. You can allocate objects, whose size might approximate 1MB, but
that (the size) is not up to you as a programmer to determine. Of course,
you could I suppose guess that "new byte[1000000]" would allocate about 1MB,
but that's not the same as e.g. a "malloc(1000000)" since Java has no
equivalent of a void*. Is that what you're driving at? Once you have that
MB, you can't share it around if things get tight for your program. Also,
although polymorphic, Java is very strongly typed, so there's no way to cast
your byte[] into e.g. a Widget. This is part of the reason your original
question lacked context.

If you're thinking of simply having your program claim an arbitrary hunk of
heap memory "just in case," you might look at the -Xms flag for the JVM.

HTH, Regards,
Sean.

 

[Woebegone]

Sean, Yes, that is what I am looking for.
Thanks for the insight!
However, despite the difference between Java and C, the JVM will totally
honor the request by allocating a 1-meg block
even it means that JVM has to search and recombine smaller blocks to get to
this 1MB.
I was told that allocating this 1MB doesn't mean that JVM would guarantee
every part of this 1MB is allocated, which I disagree. What is your take on
this?
Jimmy

Don't know what you are trying to get across, in particular, I have

tried

to
allocate a block of 1MB, didn't have
any problem in Java1, or 2.
What is the context are you trying to have?
I am just asking if a single allocation of one object will in fact return
two object, one of them linked to java.lang.Object?
Your comment is nevertheless weird and interesting.

hi, I have a couple of questions that I would like someone to take a
look,
1. java.lang.Object is the super class for all, does that mean a simple
instantiation of any class
will automatically create a java.lang.Object instance, so any simple
object
allocation will create
at least two classes.


You have some reading to do.
The answer is no, but not because there is the possibility that the answer
could be yes.
The reason the answer is no is because the question has no context.
The term "object allocation will create at least two classes." makes
absolutely no sense.

Do you "typewriters eat cauliflower spaghetti car window divided under
forty
dinosaurs" ?
The answer is no, because the question makes no sense.

2. In Java, if I want to allocate a memory block of 1M, does the JVM
have
to
ensure the existence
of such memory block, even it has to join and recombine smaller blocks.
Is
it more expensive with
a GC enabled language than C/C++

Again, impossible to answer.
Have you tried to "allocate a memory block of 1M" ?
You can't have, since it makes no sense in the context of the Java 2
Programming Language.

http://java.sun.com/tutorial
Good luck !

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

Hi Jimmy,

Every object in Java is ... an Object. Allocation (instantiation) via new
creates and returns a reference to one object. Java's intrinsic polymorphism
means that the object may be referenced as an instance of any class it
extends (including Object) or of any interface it implements, as well as its
own static type. One object, potentially many types.

As for your question about memory allocation, Java doesn't allow such an
operation. You can allocate objects, whose size might approximate 1MB, but
that (the size) is not up to you as a programmer to determine. Of course,
you could I suppose guess that "new byte[1000000]" would allocate about 1MB,
but that's not the same as e.g. a "malloc(1000000)" since Java has no
equivalent of a void*. Is that what you're driving at? Once you have that
MB, you can't share it around if things get tight for your program. Also,
although polymorphic, Java is very strongly typed, so there's no way to cast
your byte[] into e.g. a Widget. This is part of the reason your original
question lacked context.

If you're thinking of simply having your program claim an arbitrary hunk of
heap memory "just in case," you might look at the -Xms flag for the JVM.

HTH, Regards,
Sean.

Hi Jimmy,

There are others in this thread much better qualified to answer this than I
am, but my take is that if you try to instantiate an object of a given size,
the JVM can only try to allocate (that's one of the hitches here -- as has
been pointed out /you/ can't explicitly allocate anything) all the space,
and it's not compelled to even try to allocate it in contiguous space, or
prior to your process actually using it.

I could see how, in the event of a huge allocation, a JVM implementation
might allocate lazily -- something like "create on write" behaviour.

So, and forgive me for guessing, you might have a potentially memory
intensive operation, that might want access to a very large block of
contiguous storage, so you would somewhere (statically?) create an object as
large as the block you anticipate needing. Then, if it turns out you do need
it, and it's not available, release the placeholder object and free up the
space it was using, presuming that it holds the entire contiguous block you
need, and will return it for your process right at that time?

I can't say for sure, but from what I'm reading here, and what I (think I)
understand about the GC, it's unlikely that you could count on that being
so.

If you haven't yet consulted it, the JVM spec is available for browsing at
http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html.
Whether it will definitively answer you question I'm not sure...

One thing I'll suggest, if you describe exactly what it is you want to
accomplish there are people here who are willing and able to help you find
the best solution.

HTH! Regards,
Sean.

 

[Woebegone]

If you haven't yet consulted it, the JVM spec is available for browsing at
http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html.
Whether it will definitively answer you question I'm not sure...

One thing I'll suggest, if you describe exactly what it is you want to
accomplish there are people here who are willing and able to help you find
the best solution.

HTH! Regards,
Sean.

This section in the JVM spec sort of covers what I think we're talking
about. As I read it the exact behaviour is left to implementor, as long as
an OutOfMemoryError is thrown when "...a computation requires more heap than
can be made available by the automatic storage management system."

<http://java.sun.com/docs/books/vmspec/2nd-edition/html/Overview.doc.html#15
730>

 

[Chris Uppal]

I was told that allocating this 1MB doesn't mean that JVM would guarantee
every part of this 1MB is allocated, which I disagree.

I disagree too. I can't see any way that a JVM could create a byte[1000000]
without allocating physical store to back it.

My main reason for supposing this (apart from a simple appeal to sanity -- not
always a reliable guide ;-) is that array accesses are not allowed to throw an
OutOfMemoryException. The semantics of the array access bytecodes are
relatively tightly defined, and I can't see any room for an implementation to
fail a read or write that is within the array's bounds.

-- chris