[jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[jira]

The following comment has been added to this issue:

 Author: Noel J. Bergman
Created: Fri, 21 May 2004 10:44 PM
   Body:
> mc = null;

Won't help, since the object is in the userInbox collection.

> mc.setMessage(null);

If we were to do that, subsequent calls to mc.getMessageSize(), mc.getMessage(), and 
mc.writeMessageTo() would all fail.

The problem you are trying to solve is not the Mail instance or the 
MimeMessageWrapper, but the Message content.  That is something we are looking to 
address, but should not be an issue for either file or dbfile stores.
-
View this comment:
  http://issues.apache.org/jira/browse/JAMES-248?page=comments#action_35679

-
View the issue:
  http://issues.apache.org/jira/browse/JAMES-248

Here is an overview of the issue:
-
Key: JAMES-248
Summary: memory management - finalize/nullify after successful delivery of 
retrieved MailImpl
   Type: Improvement

 Status: Closed
   Priority: Major
 Resolution: CANNOT REPRODUCE

Project: James
   Versions:
 2.1.3

   Assignee: 
   Reporter: Ralf Hauser

Created: Mon, 5 Apr 2004 11:54 AM
Updated: Fri, 21 May 2004 10:44 PM
Environment: Redhat 9

Description:
My application required an adaptation of the MailRepository.retrieve() method.
It creates a temporary object on disk and I provided it with a finalize() method for 
cleaning up.

The interesting thing is that this finalize is not executed until I shut-down james.
This leads me to the conclusion that even if there was no ties to a disk operation the 
  mipl.setMessage(mimeMessage);
remains in memory long after the MUA has disconnected.

Isn't this kind of a memory leak? After all, attachments to such a MIMEMessage can be 
13MB large.
Shouldn't those objects be null-ed latest after the POP3Handler.doQUIT of a session?


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[jira]

The following comment has been added to this issue:

 Author: Serge Knystautas
Created: Fri, 21 May 2004 10:18 PM
   Body:
Explicit nulling objects can do exact opposite you intend, i.e., it can make the JVM 
less efficient at garbage collection.

http://www-106.ibm.com/developerworks/java/library/j-jtp01274.html
-
View this comment:
  http://issues.apache.org/jira/browse/JAMES-248?page=comments#action_35678

-
View the issue:
  http://issues.apache.org/jira/browse/JAMES-248

Here is an overview of the issue:
-
Key: JAMES-248
Summary: memory management - finalize/nullify after successful delivery of 
retrieved MailImpl
   Type: Improvement

 Status: Closed
   Priority: Major
 Resolution: CANNOT REPRODUCE

Project: James
   Versions:
 2.1.3

   Assignee: 
   Reporter: Ralf Hauser

Created: Mon, 5 Apr 2004 11:54 AM
Updated: Fri, 21 May 2004 10:18 PM
Environment: Redhat 9

Description:
My application required an adaptation of the MailRepository.retrieve() method.
It creates a temporary object on disk and I provided it with a finalize() method for 
cleaning up.

The interesting thing is that this finalize is not executed until I shut-down james.
This leads me to the conclusion that even if there was no ties to a disk operation the 
  mipl.setMessage(mimeMessage);
remains in memory long after the MUA has disconnected.

Isn't this kind of a memory leak? After all, attachments to such a MIMEMessage can be 
13MB large.
Shouldn't those objects be null-ed latest after the POP3Handler.doQUIT of a session?


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[jira]

The following comment has been added to this issue:

 Author: Ralf Hauser
Created: Fri, 21 May 2004 9:25 PM
   Body:
Noel, I never said that the current implementation is a defect. I only think it is not 
very memory efficient. One more degree of sophistication what I am proposing comes 
next:

As per http://nagoya.apache.org/jira/browse/JAMES-288 , doLIST could occur multiple 
times, thus, it is better to do 
mc.setMessage(null); //instead of mc = null;
this way, only one full message body remains in RAM at a time.
This is only a disadvantage if the doRETR is executed multiple times on the same 
message.

When a doTOP arrives, the message might remain in memory since it is highly likely 
that a doRETR will follow.

-
View this comment:
  http://issues.apache.org/jira/browse/JAMES-248?page=comments#action_35677

-
View the issue:
  http://issues.apache.org/jira/browse/JAMES-248

Here is an overview of the issue:
-
Key: JAMES-248
Summary: memory management - finalize/nullify after successful delivery of 
retrieved MailImpl
   Type: Improvement

 Status: Closed
   Priority: Major
 Resolution: CANNOT REPRODUCE

Project: James
   Versions:
 2.1.3

   Assignee: 
   Reporter: Ralf Hauser

Created: Mon, 5 Apr 2004 11:54 AM
Updated: Fri, 21 May 2004 9:25 PM
Environment: Redhat 9

Description:
My application required an adaptation of the MailRepository.retrieve() method.
It creates a temporary object on disk and I provided it with a finalize() method for 
cleaning up.

The interesting thing is that this finalize is not executed until I shut-down james.
This leads me to the conclusion that even if there was no ties to a disk operation the 
  mipl.setMessage(mimeMessage);
remains in memory long after the MUA has disconnected.

Isn't this kind of a memory leak? After all, attachments to such a MIMEMessage can be 
13MB large.
Shouldn't those objects be null-ed latest after the POP3Handler.doQUIT of a session?


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[jira]

The following comment has been added to this issue:

 Author: Noel J. Bergman
Created: Wed, 14 Apr 2004 6:46 AM
   Body:
The Mail object is held in the userInbox for the duration of the session.  When 
streaming is possible (there is an issue to be fixed with db protocol, but not file or 
dbfile), the message is streamed directly from store to wire.  When resetHandler is 
called in the finally {} clause of handleConnection, the objects are released.
-
View this comment:
  http://issues.apache.org/jira/browse/JAMES-248?page=comments#action_35018

-
View the issue:
  http://issues.apache.org/jira/browse/JAMES-248

Here is an overview of the issue:
-
Key: JAMES-248
Summary: memory management - finalize/nullify after successful delivery of 
retrieved MailImpl
   Type: Improvement

 Status: Unassigned
   Priority: Major

Project: James
   Versions:
 2.1.3

   Assignee: 
   Reporter: Ralf Hauser

Created: Mon, 5 Apr 2004 11:54 AM
Updated: Wed, 14 Apr 2004 6:46 AM
Environment: Redhat 9

Description:
My application required an adaptation of the MailRepository.retrieve() method.
It creates a temporary object on disk and I provided it with a finalize() method for 
cleaning up.

The interesting thing is that this finalize is not executed until I shut-down james.
This leads me to the conclusion that even if there was no ties to a disk operation the 
  mipl.setMessage(mimeMessage);
remains in memory long after the MUA has disconnected.

Isn't this kind of a memory leak? After all, attachments to such a MIMEMessage can be 
13MB large.
Shouldn't those objects be null-ed latest after the POP3Handler.doQUIT of a session?


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[jira]

The following comment has been added to this issue:

 Author: Ralf Hauser
Created: Wed, 14 Apr 2004 3:07 AM
   Body:
Noel, thx for the insight.
But wouldn't the finalizer immediately be called if the MailImpl object the 
MailRepository.java's retrieve() mehtod returns would be actively set to null once it 
has been transported to the MUA?

Perhaps addint the line 
mc = null; 
at the end of the POP3Handler.java's doRETR() method's try-catch block would aready do 
it?
perhaps do it again in a finally part to this try-catch block?
-
View this comment:
  http://issues.apache.org/jira/browse/JAMES-248?page=comments#action_35016

-
View the issue:
  http://issues.apache.org/jira/browse/JAMES-248

Here is an overview of the issue:
-
Key: JAMES-248
Summary: memory management - finalize/nullify after successful delivery of 
retrieved MailImpl
   Type: Improvement

 Status: Unassigned
   Priority: Major

Project: James
   Versions:
 2.1.3

   Assignee: 
   Reporter: Ralf Hauser

Created: Mon, 5 Apr 2004 11:54 AM
Updated: Wed, 14 Apr 2004 3:07 AM
Environment: Redhat 9

Description:
My application required an adaptation of the MailRepository.retrieve() method.
It creates a temporary object on disk and I provided it with a finalize() method for 
cleaning up.

The interesting thing is that this finalize is not executed until I shut-down james.
This leads me to the conclusion that even if there was no ties to a disk operation the 
  mipl.setMessage(mimeMessage);
remains in memory long after the MUA has disconnected.

Isn't this kind of a memory leak? After all, attachments to such a MIMEMessage can be 
13MB large.
Shouldn't those objects be null-ed latest after the POP3Handler.doQUIT of a session?


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Serge Knystautas]

Noel J. Bergman wrote:
What 'good reasons' did you have in mind?
Serge posted an article today that discusses this issue in some detail.  See
"Explicit Nulling" in
http://www-106.ibm.com/developerworks/java/library/j-jtp01274.html.
Java performance has few absolutes.  For example, the author of that article
is not a fan of user-level object pooling.  Neither, for that matter, is the
J2SE tech lead.  However, when we added object pooling of certain objects in
James, we found that performance improved significantly under load.
The section on object pooling was refuting the pervasive notion that 
object pool used to avoid object creation/collection will improve 
performance.

It does in no way suggest pooling in general is bad, in fact, "When the 
object creation cost is high, such as with database connections or 
threads, or the pooled object represents a limited and costly resource, 
such as with database connections, this makes sense."

--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Richard O. Hammer]

Noel J. Bergman wrote:
Serge posted an article today that discusses this issue in some detail.  See
"Explicit Nulling" in
http://www-106.ibm.com/developerworks/java/library/j-jtp01274.html.


Great article!  Thank you, Noel.



Java performance has few absolutes.  For example, the author of that article
is not a fan of user-level object pooling.  Neither, for that matter, is the
J2SE tech lead.  However, when we added object pooling of certain objects in
James, we found that performance improved significantly under load.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Noel J. Bergman]

> > > When I see variables set to null after their use,
> > > I think that this programmer does not know Java.
> >
> > There are good reasons for doing this, but not if
> > the variables are transient.

> What 'good reasons' did you have in mind?

Serge posted an article today that discusses this issue in some detail.  See
"Explicit Nulling" in
http://www-106.ibm.com/developerworks/java/library/j-jtp01274.html.

Java performance has few absolutes.  For example, the author of that article
is not a fan of user-level object pooling.  Neither, for that matter, is the
J2SE tech lead.  However, when we added object pooling of certain objects in
James, we found that performance improved significantly under load.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Steve Brewin]

Richard O. Hammer wrote:
> Generally, all you need to do with a variable name when you are done
> with it is to forget it.  Just let it fall out of scope, while making
> sure of course that your scope is not larger than needed.

Sage advice.

> When I see variables set to null after their use, I think that this
> programmer does not know Java.

One source of this practise is that it was necessary in some dialects of
other languages featuring GC, such as Smalltalk, where those implementations
only supported strong references. In more advanced Smalltalk dialects and
Java we have the ability to use various kinds of weak(er) references which
remove the need to explicitly release a strong reference.

Bottom line. Choose the appropriate kind of reference, manage scope and
leave the garbage collector to do its stuff. Use JVM options to tune the
heap size and GC algorithms as best fits the application. Trying to manage
memory use explicitly works against Java's ability to "write once, run
anywhere" as those explicit choices are static and will be optimised to a
single deployment scenario at best and at worst add unnecessary and
unproductive tasks to the garbage collectors work queue.

-- Steve


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Steve Brewin]

Noel J. Bergman wrote:
> 
> > When I see variables set to null after their use,
> > I think that this programmer does not know Java.
> 
> There are good reasons for doing this, but not if the variables are
> transient.

Noel,

What 'good reasons' did you have in mind? 

What do you mean by 'transient'? Maybe...
- 'Transient' = lifetime <= program scope
- 'Persistent' = lifetime > program scope
???

-- Steve


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Noel J. Bergman]

> When I see variables set to null after their use,
> I think that this programmer does not know Java.

There are good reasons for doing this, but not if the variables are
transient.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Kerr Rainey]

Noel J. Bergman wrote:

See: Runtime.runFinalizersOnExit().  There is no guarantee that finalizers
will be called, unless you use that deprecated and unreliable method.
Thanks for that, not noticed that before, or have since forgotten ;) It 
certainly seems like there is a bit of a gap in the spec around this area.

Cheers
Kerr
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Kerr Rainey]

One correction... you are not guaranteed that a finalizer will get called.

http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html 
Thanks for that, interesting stuff. If I read it correctly though they 
seem to be saying that objects aren't guaranteed to be garbage 
collected.  I'm still assuming that if an object is GC'd it would have 
it's finalize method called. The performance issues are interesting also.

Cheers
Kerr
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Richard O. Hammer]

The original issue  says:

"Isn't this kind of a memory leak? After all, attachments to such a 
MIMEMessage can be 13MB large.
Shouldn't those objects be null-ed latest after the POP3Handler.doQUIT 
of a session?"

Commenting upon this, Noel wisely asks "Do you have any reason to 
believe that there is currently a problem in James?"

I guess that this IS NOT a kind of memory leak.  The people who 
specified the JVM seem to believe that they have the JVM's memory 
managment under control, and they seem to want us Java developers to 
leave that problem to them.  Generally, I trust the JVM to do garbage 
collection using parameters which are known to the JVM.

Generally, all you need to do with a variable name when you are done 
with it is to forget it.  Just let it fall out of scope, while making 
sure of course that your scope is not larger than needed.

When I see variables set to null after their use, I think that this 
programmer does not know Java.

Rich Hammer

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Noel J. Bergman]

> does java not guarantee that everything will be garbage collected
> eventually? Even if that is not until program exit?

See: Runtime.runFinalizersOnExit().  There is no guarantee that finalizers
will be called, unless you use that deprecated and unreliable method.

I don't know if there is a guarantee that PhantomReference handling will
occur at JVM shutdown, either.  See Runtime.exit(int) for a description of
the exit sequence.  But there is also
Runtime.getRuntime().addShutdownHook(), and that could be used.

Martin Cooper raised the same concern, related to code that we are using in
Jakarta Commons.  I am looking at the code that I gave to Martin that uses
PhantomReferences, and see where a shutdown hook (JDK 1.3+) could apply.  It
should be able to process any remaining PhantomReference instances.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Serge Knystautas]

Serge Knystautas wrote:
Everything would /eventually/ get GC'd... but eventually is a long and 
non-guaranteed time.  If you're dealing with something expensive, such 
as file-handles on a server, you'd want to handle this explicitly.
One correction... you are not guaranteed that a finalizer will get called.

http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html

--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Serge Knystautas]

Kerr Rainey wrote:
OK, yes I understand that you cannot guarantee when an object will be 
garbage collected, but does java not guarantee that everything will be 
garbage collected eventually? Even if that is not until program exit? To 
be honest, I'm not sure about this. I'd certainly hope any reasonable 
implementation would do this. Too expectant?

Obviously if you have expensive resources tied up you probably want to 
guarantee that they get released in a much more timely fashion ;)
Honestly I've lost context of what the resource is you were trying to 
release, so I'm just making general comments at this point.

Everything would /eventually/ get GC'd... but eventually is a long and 
non-guaranteed time.  If you're dealing with something expensive, such 
as file-handles on a server, you'd want to handle this explicitly.

I think finalize() is perceived as a "less than ideal" design pattern at 
this point.  It might be ok if you're dealing with a client app, where 
an extra file handle or socket connection could get cleaned up 
"eventually."  But in a mailet, it's probably something to avoid.

Also, I just find this part very, very interesting... finalize() can 
really hurt performance with respect to your garbage collector.  Objects 
that have a finalize call survive through multiple generations where 
they otherwise would get immediately destroyed.

http://www-106.ibm.com/developerworks/java/library/j-jtp01274.html

--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Kerr Rainey]

You mis-understood.  Rephrasing, you cannot count on Java to call the
finalize method if it has not has not yet decided to garbage collect the
object.


I would explain it that you cannot guarantee when Java will decide to 
garbage collect /this/ object.  Even an explicit call to System.gc() does:
OK, yes I understand that you cannot guarantee when an object will be 
garbage collected, but does java not guarantee that everything will be 
garbage collected eventually? Even if that is not until program exit? To 
be honest, I'm not sure about this. I'd certainly hope any reasonable 
implementation would do this. Too expectant?

Obviously if you have expensive resources tied up you probably want to 
guarantee that they get released in a much more timely fashion ;)

Cheers
Kerr
--
Kerr Rainey - [EMAIL PROTECTED] - http://www.rokera.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Noel J. Bergman]

> You could try to call System.runFinalization().  However I would
> suggest switching to an active way of cleaning up resources rather 
> than relying on finalize().

Yes.  Explicit closure or PhantomReference use.

--- Noel

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Noel J. Bergman]

> > Java does not guarantee that finalizers run, and it certainly
> > does not guarantee that they will run before Java decides to
> > garbage collect that object.

> Are you sure?

Yes, but you misunderstood, and my phrasing wasn't clear.

  "The Java programming language does not specify how soon a finalizer
  will be invoked, except to say that it will happen before the storage
  for the object is reused."

In other words, you cannot count on Java to call the finalize method if it
has not yet decided to garbage collect the object.  One of the aspects of
garbage collection is determining that an object is no longer reachable, and
the earliest that a finalizer would be called is when that determination has
been made.

The use of a PhantomReference is considered a more reliable approach.  That
mechanism is keyed by the determination that an object is no longer
reachable except via a PhantomReference.

See
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/PhantomReference.html
for more details.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Serge Knystautas]

Noel J. Bergman wrote:
and [Java] certainly does not guarantee that they will run
before Java decides to garbage collect that object.

I believe there is a guarantee that the finalize() method will be
called on an object before it is garbage collected
You mis-understood.  Rephrasing, you cannot count on Java to call the
finalize method if it has not has not yet decided to garbage collect the
object.
I would explain it that you cannot guarantee when Java will decide to 
garbage collect /this/ object.  Even an explicit call to System.gc() does:

"Calling the gc method suggests that the Java Virtual Machine expend 
effort toward recycling unused objects in order to make the memory they 
currently occupy available for quick reuse. When control returns from 
the method call, the Java Virtual Machine has made a best effort to 
reclaim space from all discarded objects."

So just because you no longer reference it in your code will System.gc() 
get called.  You could try to call System.runFinalization().  However I 
would suggest switching to an active way of cleaning up resources rather 
than relying on finalize().

--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Noel J. Bergman]

> > and [Java] certainly does not guarantee that they will run
> > before Java decides to garbage collect that object.

> I believe there is a guarantee that the finalize() method will be
> called on an object before it is garbage collected

You mis-understood.  Rephrasing, you cannot count on Java to call the
finalize method if it has not has not yet decided to garbage collect the
object.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Kerr Rainey]

 Author: Noel J. Bergman
Java does not guarantee that finalizers run, and it certainly does not guarantee that 
they will run before Java decides to garbage collect that object.
Are you sure?

Java Language Specification, 12.6 Finalization of Class Instances

"Before the storage for an object is reclaimed by the garbage collector, 
the Java virtual machine will invoke the finalizer of that object."

"Before the storage for an object is reclaimed by the garbage collector, 
the Java virtual machine will invoke the finalizer of that object."

"The Java programming language does not specify how soon a finalizer 
will be invoked, except to say that it will happen before the storage 
for the object is reused."

http://java.sun.com/docs/books/jls/second_edition/html/execution.doc.html#44748 

Interestingly the first quote says the finalizer method is invoked 
before the storage of the object is reclaimed and the second says that 
it is sometime before the storage is reused. I'd guess that this is 
getting into the nitty gritty of what the garbage collector is actually 
doing.

Certainly I'd always assumed that the finalizer of an object would run 
eventually, even if it was sometime long after the object was eligible 
for garbage collection.

Any comments/docs to the contrary are welcome. I've not used finalizers 
heavily so I've not had any problem with them and your comment was at 
odds with what I thought to be the case. If I'm simplifying something 
and there is something I'm missing, please let me know.

Cheers
Kerr
--
Kerr Rainey - [EMAIL PROTECTED] - http://www.rokera.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[Richard O. Hammer]

[EMAIL PROTECTED] wrote:
Java does not guarantee that finalizers run,
I believe this is correct.  There is no guarantee that garbage 
collection will run, or will run on a given object.  But I believe the 
following is mistaken

and it certainly does not guarantee that they will run before Java decides to garbage collect that object.
I believe there is a guarantee that the finalize() method will be 
called on an object before it is garbage collected (IF it is garbage 
collected).

Rich Hammer



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

[jira]

The following comment has been added to this issue:

 Author: Noel J. Bergman
Created: Thu, 8 Apr 2004 8:53 AM
   Body:
Java does not guarantee that finalizers run, and it certainly does not guarantee that 
they will run before Java decides to garbage collect that object.

Another approach to cleanup is the use of PhantomReference objects.  We may adopt that 
approach into James, but temporary files in James, created by MimeMessageInputSource, 
are cleaned up during normal operation as you could see by watching the temp/ 
directory.  I cannot speak for whatever is done in your code.

Do you have any reason to believe that there is currently a problem in James?
-
View this comment:
  http://issues.apache.org/jira/browse/JAMES-248?page=comments#action_28040

-
View the issue:
  http://issues.apache.org/jira/browse/JAMES-248

Here is an overview of the issue:
-
Key: JAMES-248
Summary: memory management - finalize/nullify after successful delivery of 
retrieved MailImpl
   Type: Improvement

 Status: Unassigned
   Priority: Major

Project: James
   Versions:
 2.1.3

   Assignee: 
   Reporter: Ralf Hauser

Created: Mon, 5 Apr 2004 11:54 AM
Updated: Thu, 8 Apr 2004 8:53 AM
Environment: Redhat 9

Description:
My application required an adaptation of the MailRepository.retrieve() method.
It creates a temporary object on disk and I provided it with a finalize() method for 
cleaning up.

The interesting thing is that this finalize is not executed until I shut-down james.
This leads me to the conclusion that even if there was no ties to a disk operation the 
  mipl.setMessage(mimeMessage);
remains in memory long after the MUA has disconnected.

Isn't this kind of a memory leak? After all, attachments to such a MIMEMessage can be 
13MB large.
Shouldn't those objects be null-ed latest after the POP3Handler.doQUIT of a session?


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]