Re: Java Memory question
On 15/03/11 14:49, Eric wrote:
I got an
OOME on a clone copying to the client so my issue was likely
insufficient client memory. I'll try at least doubling the JNLP
values.
First of all, you don't "clone" copying to a client. What exactly are
you doing? Your terminology is not correct, and what you are saying in
general doesn't make sense. Web Start does not send Java objects to a
client, it sends jar files and the JNLP. Where is your client getting
the "objects" from?
2. What I call 'native' Java is quite different than the Java
technical term. I considered a byte to be a 'native' variable type,
and a byte[] to be a native array because the definition is built in.
I don't need any include or classpath references to use them. Maybe
the term is just "built-in" or is there a technical term for "that
which is just supposed to work on any machine which has Java installed
without providing any custom classes/jars"? The natives are the ones
who are already there. I'm not telling the client machines what a
byte is, they already know.
We've already told you on several occasions. They are primitive types.
'Native' has explicit meaning in Java, it relates to non-Java code
executed by the JVM. Don't call primitive types 'native', people will
not understand you.
3. Limit scope. Initializing variables within a method seems like a
waste of processing if the variables get the same value every time,
If it's always the same value why not make it a constant? You need to be
clearer about your objectives.
but it is better memory management and object code should be concerned
with memory over performance. At least for the small stuff, let the
interpreter worry about performance. Where I need another object of
the same type in more than one method I should declare them at the top
of each method or create more methods rather than reusing shared
instance variables.
You should only declare them as instance variables if they are actually
a meaningful part of the object. Keeping an instance variable hanging
around for no good reason will not improve performance, in general. A
local reference variable takes up pretty much no memory, and allocating
it on the stack takes almost no time. Any object which an instance
variable refers to will probably not be reusable anyway, so keeping it
around when the method exits may actually be wasteful of heap memory.
To the one who misinterpreted my statement "I don't believe cloning
can copy a reference."
The reason anyone misinterprets what you are saying is because you keep
inventing your own terminology which is in conflict with the terminology
used in Java.
that is to say the cloning processes must
create a new object, referring specifically to cloning an object on
the server in order to create an object on the client.
But you never mentioned anything in regard to copying variables between
the server and the client when you talked about cloning, and copying
references. How was anyone supposed to infer your intent?
When variables are sent between a server and a client they will be
serialized to the stream, not cloned. An entirely different operation,
carried out by different methods.
While it may
be possible for an object to simply be a reference to another object,
It isn't. You still appear to be exhibiting a misunderstanding of the
difference between a reference variable and the object to which a
reference variable refers. A reference variable holds a reference to an
object. Any number of reference variables can refer to the same object.
An object may contain reference variables which refer to other objects.
An object cannot reference another object, other than it contains a
reference variable which refers to that other object.
SomeObject a;
defines a reference variable.
a = new SomeObject();
creates a new SomeObject and sets the reference variable "a" to point to
the created object.
SomeObject b = a;
creates a new reference variable b, which also points to the same
instance of SomeObject.
a = null;
does nothing. b still points to the object so it's not available for GC.
b = null;
does nothing per se, but in this example does remove the last reference
to the object so that at some time later GC may release the object. At
this point in time there is no way to reference the object, or access
any of its content.
I wouldn't think the other object could exist on a different machine.
It can't. You cannot refer to an object on another machine, or within
another JVM on the same machine. You can transfer a copy of an object by
serializing it at the sending end and de-serializing it at the receiving
end.
That would be useful if I could create a GUI object on the server and
display it on the client without creating a copy on the client as a
new object. In this case the objects I'm attempting to clone are
javax.swing.ImageIcon instances in a java.util.ArrayList.
Can you please be more explicit about what you are actually doing. What
is attempting to "clone" those objects, and to what purpose?
--
Nigel Wade