Forums Register Login

Problems with thread exceeding cache size and garbage collection

+Pie Number of slices to send: Send
Say that I am taking a number of threads off of a queue. My cache is an arbitrary size of 2000. Now the first thread is 1300 and the 2nd is 1200. Since the 2nd one is too big to go into the cache I get an exception. How, can I recover from this exception? Should I be doing garbage collection manually here? Sorry, if my question is hard to understand I haven't done too much work with threading before.
+Pie Number of slices to send: Send
Hi,

Welcome to JavaRanch!

Cache of what? 2000 what? 1200 what? 1300 what?

Can you just catch the exception in your run() implementation, and deal with it?
+Pie Number of slices to send: Send
I'm not really sure; I was just saying like arbitrary units. Say for Example 2000MB, 1300MB, and 1200MB. One of my office mates asked me this question to post it... I'll see if I can get more info about the problem. Thanks.
+Pie Number of slices to send: Send
 

How, can I recover from this exception? Should I be doing garbage collection manually here?



The system will GC as it needs memory -- so if you get an out of memory error, all the garbage have been pretty much clean up.

Now... if the cache is just that -- a cache and not a critical datastore. You can rewrite the cache using weak references. This way, as the system needs memory, it can GC the cache as well.

Henry
+Pie Number of slices to send: Send
It is not a critical datastore but I don't have control over the cache because it is being run in WebLogic. WebLogic is in control of the queueing of threads. The exception being thrown is a java.lang.OutOfMemoryError. Also, the reference is pulling in a buffered image. The garbage collector can't take the entire chunk back since it is one reference.
+Pie Number of slices to send: Send
[Henry]: so if you get an out of memory error, all the garbage have been pretty much clean up.

That's true at the point the exception was thrown. However at the point you catch the exception, you've already at least abandoned the attempted action which requred extra memory, and you may well have exited several other blocks and/or methods, making additional variables go out of scope, and allowing additional memory available to GC. Depending on what you're doing and how your code is organized, it may be perfectly reasonable to catch the exception and attemtp to proceed anyway. The critical question being - how important was the method call that threw the exception? Is it possible to proceed if that failed? Often the answer is no, but sometimes it's yes. Can't say much more in general - it all depends on the details of what one is doing here, I think.
+Pie Number of slices to send: Send
You meant to say SoftReference Mr. Wong.
+Pie Number of slices to send: Send
 

Originally posted by Mr. C Lamont Gilbert:
You meant to say SoftReference Mr. Wong.



This is actually a good point. Yes, I do mean the SoftReference class, but how do I reference (no pun intended) the package with something that can be googled? "weak references" seems to be a more commonly used term.

I don't like "references package". Maybe "java.lang.ref package" is better. Opinions appreciated...

Henry
+Pie Number of slices to send: Send
This parrot is no more. It has ceased to be. Now it's a tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 711 times.
Similar Threads
GC
Daemon Threads
handle large list in memory
Passed SCJP 1.4
what is daemon threads
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 01:29:25.