OutOfMemoryError - OS X Version 10.5.6

[roundedge]

The game has been crashing a lot, and only now have I looked at the error output. In addition, I often have huge lag, which goes away when I restart the game. The game eats up my cpu when I look at it on the activity monitor. This leads me to believe that maybe something in the game is gobbling up my ram and not giving it back when it's done. I increased the heap size from 256 mb, to a gig, but it only prolongs the lag/crash of the game. Here's the full error output:

Code: Select all

javax.media.opengl.GLException: java.lang.OutOfMemoryError
	at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:271)
	at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:410)
	at javax.media.opengl.GLCanvas.display(GLCanvas.java:244)
	at haven.HavenPanel.uglyjoglhack(HavenPanel.java:351)
	at haven.HavenPanel.run(HavenPanel.java:380)
	at java.lang.Thread.run(Thread.java:613)
Caused by: java.lang.OutOfMemoryError
	at sun.misc.Unsafe.allocateMemory(Native Method)
	at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:99)
	at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:288)
	at apple.awt.OSXSurfaceData.getBufferOfSize(OSXSurfaceData.java:2232)
	at apple.awt.OSXSurfaceData$DrawingQueue.<init>(OSXSurfaceData.java:1659)
	at apple.awt.OSXSurfaceData.<init>(OSXSurfaceData.java:68)
	at apple.awt.OSXSurfaceData.<init>(OSXSurfaceData.java:48)
	at sun.awt.image.BufImgSurfaceData.<init>(BufImgSurfaceData.java:349)
	at apple.awt.OSXOffScreenSurfaceData.<init>(OSXOffScreenSurfaceData.java:608)
	at apple.awt.OSXOffScreenSurfaceData.createNewSurface(OSXOffScreenSurfaceData.java:471)
	at apple.awt.OSXOffScreenSurfaceData.createData(OSXOffScreenSurfaceData.java:110)
	at sun.awt.image.BufImgSurfaceData.createData(BufImgSurfaceData.java:66)
	at apple.awt.CGraphicsEnvironment.createGraphics(CGraphicsEnvironment.java:281)
	at java.awt.image.BufferedImage.createGraphics(BufferedImage.java:1159)
	at haven.Text$Foundry.render(Text.java:144)
	at haven.Text.render(Text.java:177)
	at haven.Text.render(Text.java:185)
	at haven.GOut.atext(GOut.java:165)
	at haven.SlenHud.draw(SlenHud.java:314)
	at haven.Widget.draw(Widget.java:284)
	at haven.RootWidget.draw(RootWidget.java:74)
	at haven.UI.draw(UI.java:94)
	at haven.HavenPanel.redraw(HavenPanel.java:255)
	at haven.HavenPanel$1.display(HavenPanel.java:77)
	at com.sun.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:78)
	at javax.media.opengl.GLCanvas$DisplayAction.run(GLCanvas.java:435)
	at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:194)
	at javax.media.opengl.GLCanvas$DisplayOnEventDispatchThreadAction.run(GLCanvas.java:452)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
	at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

[Blaze]

Java suffers from memory leaks, so it keeps eating up RAM until it stabilizes. It is strange that it takes a gig then crashes, my Java version 5 stops at ~330,000 MB of RAM.

Oh and the game itself is notoriously CPU hungry, so expect that.

[loftar]

It does seem weird that it should die of OOM errors. I haven't been able to detect any memory leak on any of the computers I regularly have the client tested on in a long time now. If possible, could you arrange a heap dump if OSX supports the jmap tool? Since you are knowledgeable enough to be changing the heap size, can I assume that you know whereof I speak?

Java suffers from memory leaks, so it keeps eating up RAM until it stabilizes.

If I were to guess at what you're seeing, it is probably not so much a "memory leak" as such, but rather the generational survivor space propagating up the heap for every collection of the eden space before triggering a complete Mark-Sweep collection/compression, allocating swap space for previously zero-backed pages along the way. If anything, it can actually be argued that Haven does use a bit too much eden space for its own good (because of the Coord class I'm using all over the place to do coordinate manipulation), but it shouldn't actually matter, since eden collections are fast. (Also, unless I'm outright wrong, the new-fangled escape analysis hopefully soon making its way into mainline HotSpot might fix that problem largely, if it actually is a problem)

And yes, I know I should optimize the client further. Right now, it's working really well for me, though, so I haven't bothered. :)

[sabinati]

i have a lot of "haven errors" that crash my client on OS X 10.4.something. luckily i don't use that machine to play very much, but it usually crashes.

[roundedge]

I actually just went into the auto-haven java web start file and changed max-heap-size from 256 to 1024, I'm not a pro or nothing
But I googled jmap, and jumped into terminal, and got a heap summary for you:

using thread-local object allocation.
Mark Sweep Compact GC

Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 1073741824 (1024.0MB)
NewSize = 655360 (0.625MB)
MaxNewSize = 4294901760 (4095.9375MB)
OldSize = 1441792 (1.375MB)
NewRatio = 12
SurvivorRatio = 8
PermSize = 8388608 (8.0MB)
MaxPermSize = 67108864 (64.0MB)

Heap Usage:
New Generation (Eden + 1 Survivor Space):
capacity = 14417920 (13.75MB)
used = 1397880 (1.3331222534179688MB)
free = 13020040 (12.416877746582031MB)
9.6954345703125% used
Eden Space:
capacity = 12845056 (12.25MB)
used = 257568 (0.245635986328125MB)
free = 12587488 (12.004364013671875MB)
2.005191725127551% used
From Space:
capacity = 1572864 (1.5MB)
used = 1140312 (1.0874862670898438MB)
free = 432552 (0.41251373291015625MB)
72.49908447265625% used
To Space:
capacity = 1572864 (1.5MB)
used = 0 (0.0MB)
free = 1572864 (1.5MB)
0.0% used
tenured generation:
capacity = 191197184 (182.33984375MB)
used = 136271496 (129.95862579345703MB)
free = 54925688 (52.38121795654297MB)
71.27275263635681% used
Perm Generation:
capacity = 16252928 (15.5MB)
used = 16035864 (15.292991638183594MB)
free = 217064 (0.20700836181640625MB)
98.66446218182963% used

This is about a 2 minutes into running the game.

When I do a process inspection of the game, I can see that the memory size is swiftly growing, and , oop speak of the devil, about 6 minutes into the game the error has come up:

Code: Select all

javax.media.opengl.GLException: java.lang.OutOfMemoryError
	at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:271)
	at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:410)
	at javax.media.opengl.GLCanvas.display(GLCanvas.java:244)
	at haven.HavenPanel.uglyjoglhack(HavenPanel.java:351)
	at haven.HavenPanel.run(HavenPanel.java:380)
	at java.lang.Thread.run(Thread.java:613)
Caused by: java.lang.OutOfMemoryError
	at sun.misc.Unsafe.allocateMemory(Native Method)
	at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:99)
	at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:288)
	at apple.awt.OSXSurfaceData.getBufferOfSize(OSXSurfaceData.java:2232)
	at apple.awt.OSXSurfaceData.<init>(OSXSurfaceData.java:60)
	at apple.awt.OSXSurfaceData.<init>(OSXSurfaceData.java:48)
	at sun.awt.image.BufImgSurfaceData.<init>(BufImgSurfaceData.java:349)
	at apple.awt.OSXOffScreenSurfaceData.<init>(OSXOffScreenSurfaceData.java:608)
	at apple.awt.OSXOffScreenSurfaceData.createNewSurface(OSXOffScreenSurfaceData.java:471)
	at apple.awt.OSXOffScreenSurfaceData.createData(OSXOffScreenSurfaceData.java:110)
	at sun.awt.image.BufImgSurfaceData.createData(BufImgSurfaceData.java:66)
	at apple.awt.CGraphicsEnvironment.createGraphics(CGraphicsEnvironment.java:281)
	at java.awt.image.BufferedImage.createGraphics(BufferedImage.java:1159)
	at haven.TexI.convert(TexI.java:91)
	at haven.TexI.<init>(TexI.java:49)
	at haven.Text.tex(Text.java:190)
	at haven.GOut.atext(GOut.java:166)
	at haven.SlenHud.draw(SlenHud.java:314)
	at haven.Widget.draw(Widget.java:284)
	at haven.RootWidget.draw(RootWidget.java:74)
	at haven.UI.draw(UI.java:94)
	at haven.HavenPanel.redraw(HavenPanel.java:255)
	at haven.HavenPanel$1.display(HavenPanel.java:77)
	at com.sun.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:78)
	at javax.media.opengl.GLCanvas$DisplayAction.run(GLCanvas.java:435)
	at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:194)
	at javax.media.opengl.GLCanvas$DisplayOnEventDispatchThreadAction.run(GLCanvas.java:452)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
	at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

At the time of termination, my process inspector says the following:

Haven and Hearth:
%CPU:107.18
Real Memory Size:1.48 GB
Virtual Memory Size:3.30 GB
Shared Memory Size: 23.29 MB
Private Memory Size:1.47 GB
Virtual Private Memory: 2.89 GB

I'm kind of afraid to run a complete heap dump, how long would it take for something like 1.48 GB?

[roundedge]

happened to me again four times so far today. It's making the game a unplayable.

[Blaze]

A quick look found:

Code: Select all

at haven.HavenPanel.[b]>>>uglyjoglhack<<<[/b](HavenPanel.java:351)

Oh Loftar, you silly head.

[loftar]

I'm kind of afraid to run a complete heap dump, how long would it take for something like 1.48 GB?

Well, it is unfortunate, but it is that file that I'd need to be able to do anything. Of course, if you reset the heap size, it would "only" be 256 MBs, but, yeah... I know it is less than optimal.

A quick look found:

Code: Select all

at haven.HavenPanel.[b]>>>uglyjoglhack<<<[/b](HavenPanel.java:351)

Oh Loftar, you silly head.

Oh, so I take it you haven't seen "ResCache.StupidJavaCodeContainer", "SslHelper.j2seIsStupid", "MainFrame.javabughack" or "Utils.drawgay"? :)

To be honest though, it is not an "ugly hack for JOGL", but rather "a hack around the uglyness of JOGL". See, JOGL thinks it's a good idea to catch InterruptedExceptions and wrap them as cause inside a GLException, making the normal thread interruption mechanism look like an error instead. So the "uglyjoglhack" function is simply a wrapper around the real call to the main JOGL redisplay function that checks any GLExceptions coming back, unwrapping the InterruptedException back to me.

[roundedge]

Okay, I can do it next week 4 months from now, I'm going to be without interwebs this weekend, going to a cabin in the woods for canadian thanksgiving I'm a lazy son of a bitch.