Re: Java Memory question
On Mar 15, 12:11 pm, Nigel Wade <nmw-n...@ion.le.ac.uk> wrote:
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?
The client gets objects from the server to client clone method, which
would be connecting the 2 JVMs with ObjectOutputStream-
ObjectInputStream.
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.
We've already established that. I was explaining my intent, to
describe Java code which is already there, which is in the Java
installation which doesn't require custom classes/jars. I'd
appreciate if you want to be helpful and provide a better word for
it. I don't need you repeating what someone else just said.
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.
Did I say it's a constant value? I said it gets the same value every
time. This means variables which need to be initialized, which may
take multiple statements and/or depend on other values but always come
out the same.
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.
Why would anyone keep a variable hanging around "for no good reason"?
The main reasons I had for making an instance variable instead of a
method variable were 1. To reduce lines of code and 2. To reduce
processing time if the create may take a while. If that's not clear
enough, review this specific example clip.
class CustomWindow extends JFrame {
private JMenuBar menuBar;
private JMenu menu;
public void run() {
menuBar = new JMenuBar();
addMenuOne(menuBar);
addMenuTwo(menuBar);
}
private void addMenuOne(JMenuBar menuBar) {
menu = new JMenu("File");
menu.setMnemonic(KeyEvent.VK_F);
menuBar.add(menu);
}
private void addMenuTwo(JMenuBar menuBar) {
menu = new JMenu("Edit");
menu.setMnemonic(KeyEvent.VK_E);
menuBar.add(menu);
}
}
So it uses the same object variable many times within the class for
the same purpose with different values.
It may be fewer lines of code to put the "JMenu " on each line in
front of "menu = new" though it is more characters after a few uses.
Is performance any different to create an object in one statement
(JMenu menu = new JMenu("Title");) or two (Jmenu menu; menu = new
JMenu("Title"))?
If performance is the same I prefer to use 2 statements and put all
the declares (JMenu menu;) at the beginning of the method (which can
look like a lot of duplication), or to define them as instance
variables if it makes sense to do so.
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.
I apologize if the technical words are not correct. I work with
several languages at once and it's my job to write working efficient
maintainable code, not to study program theory and technical terms. I
did that in college over a decade ago. Terminology changes with each
language. I try to explain what I write when I think there may be
some confusion. If you still don't understand what I write you are
free to ask for clarification or simply not respond.
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?
Are you following the thread? I did say just that. I wrote this
message you responded to in order to clarify. If you don't understand
that just ask. Don't tell me what I didn't say. I'm not sure what
your intent is in writing this but please try to be inquisitive or
helpful like most here have been.
"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."
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.
Serializing is cloning. If you want to pick at terminology, you're
wrong too. Cloning is creating a copy of an object. You may think of
it as creating a new object which must exist in the same JVM, perhaps
as simple as "Object a = b.clone();". I'm essentially doing the same
thing but the copy needs to be created on the other machine. The
custom API I'm calling to do that uses cloneAsClientObject() for the
method name. If you want to get technical, when you serialize an
object to a stream it doesn't go anywhere. If that stream is on the
server and a stream on the client is connected to it, you might be
sending it 'to' the client but not 'between' the server and client.
You forgot to mention the client must deserialize the object. This
creates a COPY (or clone) of the object. Call it what you want but
you missed the point. The point was I got an OOME on the previously
mentioned cloning process, which as we've established was likely
caused by the JNLP memory setting.
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 reference to what? It appears you're just declaring what type that
variable refers to.
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.
That's an object which is a reference to another object. That's what
I just said. You said no.
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.
That is what I initially suggested and the response was 1. b still
keeps the memory from GC if defined as an instance variable. 2. That
is done implicitly on exiting a method if the object was declared in
the method (and GC won't clear it's memory before the method
completes).
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's what I said. I'm copying an object from a server to a client.
That copy must be a clone, not a reference. The clone is created
through the ObjectOutputStream.
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
The purpose is to render a document on a server and display it on a
client machine.