Thread: applet out of memory error (how to increase available heap space)

I was wondering where is the memory allocated for an applet; by the browser; by the JVM; some applet specific java option? I get an out of memory error when running my applet (loading pictures).

Now what you're describing sounds like a Swing app constructed and/or run improperly. Are there multiple threads - real Threads? Thread.sleep()s? There shouldn't be. But I won't go on with the list of things that you might have done wrong that could be causing the problems you've described.

In order for us to be helpful, you need to post some code, preferably code that demonstrates the problem. If that is too hard due to heavy graphics, then post the relevant parts that build and run the Applet (hopefully, JApplet) with any app control logic that controls the timing of execution and/or animation of the app.

Well I'm not using any swing API, and I believe I practice thread safety quite well; on top of that the program runs on my computer fine, and the memory is lower than even chrome with a couple youtube tabs. I think I will just shy away from applets; the lack of information available to me about how applets are ran is crippling. I would love to have the exact code that deals with my applet. From examining my code the only conclusion is IE is dropping threads for some reason.

So my question is does this sound crazy to you? Does it just sound like I have a poorly written applet? Or, is what I'm saying valid? Because to me, it seems that the browser is causing problems.



P.S: Also, I hate that I have to sign my applet through some group of racketeers. What gives that group the right to police applets?

AWT isn't thread safe either. Why you'd use AWT rather than Swing is a mystery.

All Java source code is available for you to examine.

The browser does not "drop threads," so I'm not sure what you suspect is happening. When you use threads within a framework that is declared to be "not thread safe," you're subject to experiencing the behaviors you describe. The reason(s) for these behaviors and how to avoid them are well documented in several very thorough papers available on the 'net.

I missed you saying that your design is largely custom. Because of that, you know more about your code and what could be happening (or not) than anyone here. Not sure what help you expect from Java SE rangers who've never seen your code.

There are ways to help the garbage collector do its job - mainly by releasing references to objects that have been created - but also limiting the objects created, reusing those that are created, setting those to null that are no longer needed, etc. These tips along with others I've surely forgotten are listed in the book "Effective Java."

I'd be interested to hear if you find a root cause and general solution that might be helpful to others.

Good luck!

Applets are not allowed to load certain classes I guess. So my thread watcher gained an exception and kept on trucking (as it should), but I was unable to access the proper variables to set them to null and free up space. Additionally, I had a loop without any way of exit (no sleep either) which bottle necked the memory.

Applets are not allowed to load certain classes I guess.

Can you give an example? What was the exception being thrown?

Additionally, I had a loop without any way of exit (no sleep either) which bottle necked the memory.

Was the loop akin to a while ( true ) loop? That would capture the attention of that thread, causing uncertain execution of the rest of the code in that thread, but how was the memory impacted. Was that loop creating objects?

Thanks for adding the details.

Can you give an example? What was the exception being thrown?

IllegalAccessException

Was the loop akin to a while ( true ) loop? That would capture the attention of that thread, causing uncertain execution of the rest of the code in that thread, but how was the memory impacted. Was that loop creating objects?

That loop was in charge of doling out instructions for image loading processes.