Re: Java Memory question
On 14/03/11 17:57, Eric wrote:
On Mar 14, 1:23 pm, Nigel Wade <nmw-n...@ion.le.ac.uk> wrote:
On 14/03/11 15:04, Eric wrote:
On Mar 14, 10:34 am, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
On 03/14/2011 10:10 AM, Eric wrote:
If I create a native object like
byte[] myData = new byte[byteSize];
then I fill it with data,
how do I release the memory?
Do I just null it?
myData = null;
All objects [1] in Java are garbage collected, so the memory will be
freed when the last reference to an object is lost. You can of course
have references to an object as variables within the scope, elements of
an Object array, or as objects in a class [2]. If it's a local variable,
the reference will be lost when leaving the scope within which it is
defined (i.e., pair of curly braces); you can lose the reference earlier
by explicitly nullifying it.
To move it to a new object using as little memory as possible do I
just null each?
byte[] myNewData = new byte[byteSize];
for (int byteLoop = 0; byteLoop< byteSize; byteLoop ++) {
myNewData[byteLoop] = myData[byteLoop];
myData[byteLoop] = null;
}
Or is there a better way to move it without eating double memory?
Judging by the code you're trying to write, byte[] myNewData = myData;
would probably be more than sufficient, since that gives the new data a
reference to the same memory to begin with, and it doesn't involve
copying the array again. If you need a subarray of only a portion of the
data, java.util.Arrays.copyOf might work better for you.
[1] Well, primitives aren't, but they aren't exactly objects to begin with.
[2] Or they can be rooted by the JVM while being used by native APIs,
but I digress.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
The point of copying the array is that I can't create the new object
as a reference to the same memory, because the copy is a cloned object
on a different machine through a webstart.
I don't know what you mean by this. But your client cannot have direct
access to memory on the server. If the client has received an object
from the server then it is actually an object in the client, regardless
that it's been copied from the server.
Correct me if I'm wrong.
If I actually knew what you meant I might, but I may have misunderstood
what you meant.
1. It appears a client object and a server object in a webstart
session affect the same memory limit in a webstart.
What do you mean by a webstart session? A client can only ever access
memory in the client. Any data objects which are sent from the server to
the client are copies of whatever exists on the server, and take up
memory allocation within the client.
By webstart session I mean webstart session. eh?
http://download.oracle.com/javase/6/docs/technotes/guides/javaws/index.html
2. It should use a lot less memory if I create an empty (large) array
object on the client then copy and destroy the array elements of the
server object one at a time.
If it's an array of primitives you cannot destroy part of it, it is one
object, a single entity in the heap. If it's an array of references then
null'ing the source array would have no effect unless you are actually
creating a new object which is a copy/clone of the old object. If you
merely copy the reference from the source array to the destination array
then null'ing the reference in the source array will achieve nothing
whatsoever. The new array would contain a reference to the original
object, so it won't get GC'd.
1. I don't believe cloning can copy a reference.
Well, many people believe things which are untrue.
It should be
creating a new object to assign values from one object to an object
which exists on another machine.
It will be doing whatever the class clone() method defines it to do. If
that method is not defined it will most likely throw a
CloneNotSupportedException.
Many implementations of clone() only perform a shallow copy. That is,
they create a new instance of the class in question, then simply copy
the contents of each member variable. If the member variable is a
reference all that gets copied is the reference, no new object is
created. So both instances of the cloned object refer to the same
subordinate object.
2. It seems 'native' arrays work differently.
'native'? Do you mean array of primitives? Terminology is vital to
correct communication and understanding. 'Native' has a very specific
meaning in Java, and this is not it.
I tried to test if an
element of an array was null and got a compile error comparing one
element of a byte[] or an int[],
Of course you will. You really don't understand the difference between a
primitive and an reference. You absolutely have to understand this.
though it did show object array
values as null whether the array was an ImageIcon[] or an Integer[].
Yes, because they are arrays of references, not primitives.
I've run into this issue before trying to clone bytes with a generic
method from server to client where the client didn't know what they
were. I tried to pass in byte[] as Object[] and it seems it expects
just one Object. I was thinking of a 'native' array as any array with
[] versus the Java ArrayList.
byte[] is one object. Object[] is an array of Objects. There is a very
fundamental difference.
It seems you are trying to run before you can walk. You should really,
really, take the time to understand the concepts of OO before you go any
further. Get a good book on Java and read up on the fundamental concepts
of OO, how Java handles OO and how it uses primitive types. Go through
this tutorial and make sure you understand it:
http://download.oracle.com/javase/tutorial/java/index.html
3. It is more efficient to declare variables global (to the class
object) rather than local (to the method) if the method may be called
more than once.
Beware your terminology. You are straying into very mistaken wording.
There is no such thing as a "global" variable within an object, or
within Java. There are 3 types of variables in Java.
Class variables.
These belong to the class. There is one copy of any such variable and
it's shared between all objects of that class.
Instance variables.
These belong to an object, and each object has its own copy.
Local variables.
These are local to a method.
Instance variables exist from the time they are created (when the object
is created) until the object of which they are a part is destroyed. An
instance variable may refer many different objects over its lifetime.
I see. I'm sure I'm not using any class variables. If they work they
could actually be useful in some cases.
Of course they work.
What I'm calling class
variables are the ones defined after the class verb before any methods
which it seems are instances variables.
Yes, and terminology is vital.
I think of classes like
programs, where running 2 instances of the same program concurrently
each one traditionally initializes it's own variables not knowing or
caring what the other is doing unless there's a conflict.
Well, I think you need to alter your perception. Classes are merely
definitions. Objects are instances of classes which exhibit the
behaviour defined in the class. Two instances of the same class can most
definitely conflict with each other (if not programmed correctly), in
many ways which two separate programs cannot.
Local variables are allocated on the stack and automatically go out of
scope when the method returns. An object which is only referenced by a
local variable (within the method) will be free to be GC'd when the
method returns. But any such object is not GC'd by the action of the
method returning, it only become available for GC at some later time.
4. Variables must be global if their value must persist between
methods.
Again, they are not "global". They are just not local to a method. They
will most likely be instance variables and accessible by any instance
methods. Their value will be part of the object, not just a method. They
are not global because they won't be accessible to any other object
(unless declared public, and the other object has a reference to the
object, or the object provides an accessor method).
5. Variables are implicitly set to release memory at the method end
(return/throw) if they're declared within the method. Explicitly
setting them to null would get no benefit.
Variables, yes. Objects, maybe. Just because a local variable goes out
of scope when a method returns does not imply that an object to which it
referred is free to be GC'd. But, yes, setting them to null is pointless.
6. Variables must be explicitly cleared (object = null) to release
memory at a method end if they're declared as global.
Not global. If you mean they are instance variables, then why would you
do that anyway? If the variable, and the object to which it refers,
should only exist within the method then make it a local variable. Then
allocate a new instance of the object within the method. Java will take
care of the GC for you. I can't see any point in declaring an instance
variable, allocating a new object to that instance variable in a method,
then null'ing the instance variable before the method returns. Also,
null'ing an instance variable won't release an object for GC if there is
still a reference to that object elsewhere.
The reasoning behind declaring the variable as an instance variable
was to have all the declarations in one place,
That's just plain silly. Program logic outweighs "neatness". Always.
to avoid mentioning the
type on the create if it needs to be recreated, or to use the same
variable name for the same purpose in more than one method where the
value doesn't need to carry over.
and misusing instance variables to save typing is even worse.
If the variable is not actually a part of the object, merely a temporary
variable used within a method, then don't make it an instance variable.
That has implications for the design/functionality of the class, and
prolongs the existence of variables beyond where they should, leading to
the serious possibility of unintentional cross-talk between methods.
One of the underlying principles/goals of OO is encapsulation (to
protect data). By exposing method variables to the class, and other
methods, you are defeating encapsulation and making yourself vulnerable
to errors which should never be possible with correct design.
It seems the best practice for that is to put the declarations at the
top of each method where they're used,
Where they are actually used is better still.
and declaring variables as
instance variables when they only need to be method variables would be
a problem if it can't release their memory until the instance object
is destroyed.
It is a problem per se. It makes the reference variable live for longer
than it should, it may also make any object to which the variable refers
exist for longer than it should.
The only possible excuse I can think of for doing something like this is
where memory is at an absolute premium and/or GC is seriously affecting
performance (actual measured performance, not imagined) to the point
where the program is unable to meet specifications. Then, and only then,
might you consider making the reference variable an instance variable,
and have the object to which it refers hang around between method
invocations. I don't consider that getting OOM errors as a valid reason
in itself, if you can just increase the heap to fix it.
--
Nigel Wade