Out of Memory error

[Redlaw]

ava.lang.RuntimeException: haven.BGL$BGLException: haven.GOut$GLOutOfMemoryException: GL Error: 1285 (out of memory)
at com.jogamp.common.util.awt.AWTEDTExecutor.invoke(AWTEDTExecutor.java:58)
at jogamp.opengl.awt.AWTThreadingPlugin.invokeOnOpenGLThread(AWTThreadingPlugin.java:103)
at jogamp.opengl.ThreadingImpl.invokeOnOpenGLThread(ThreadingImpl.java:206)
at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:172)
at javax.media.opengl.Threading.invoke(Threading.java:191)
at javax.media.opengl.awt.GLCanvas.display(GLCanvas.java:528)
at haven.HavenPanel$6.uglyjoglhack(HavenPanel.java:455)
at haven.HavenPanel$6.run(HavenPanel.java:490)
at java.lang.Thread.run(Unknown Source)
Caused by: haven.BGL$BGLException: haven.GOut$GLOutOfMemoryException: GL Error: 1285 (out of memory)
at haven.BufferBGL.run(BufferBGL.java:46)
at haven.HavenPanel.redraw(HavenPanel.java:401)
at haven.HavenPanel$1.display(HavenPanel.java:103)
at jogamp.opengl.GLDrawableHelper.displayImpl(GLDrawableHelper.java:649)
at jogamp.opengl.GLDrawableHelper.display(GLDrawableHelper.java:633)
at javax.media.opengl.awt.GLCanvas$9.run(GLCanvas.java:1271)
at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1103)
at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:978)
at javax.media.opengl.awt.GLCanvas$10.run(GLCanvas.java:1282)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$500(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: haven.GOut$GLOutOfMemoryException: GL Error: 1285 (out of memory)
at haven.GOut.glexcfor(GOut.java:129)
at haven.GOut.checkerr(GOut.java:137)
at haven.BGL$1.run(BGL.java:90)
at haven.BufferBGL.run(BufferBGL.java:44)
... 22 more


I crashed and just got this on the base client. Is H&h Using more memory then it was before or something?

[Ysh]

Try to download more RAM.

[MagicManICT]

Might try the following and see if it helps, though it's not necessarily a fix.

Open up the "autohaven.jnlp" file with WordPad or other text editor (not notepad... it doesn't preserve the line breaks properly). Find these two lines:

<j2se version="1.8+" max-heap-size="512M" />
<java version="1.8+" max-heap-size="512M" />

Try changing them to 1024M or higher.

Anything beyond this is out of my knowledge area.

[loftar]

<j2se version="1.8+" max-heap-size="512M" />
[...]
Try changing them to 1024M or higher.

You will notice this being an out-of-OpenGL-memory exception, not out-of-heap-memory. Increasing the Java heap therefore will not help that; if anything, it may very well make it worse by perhaps not GC:ing stale textures as often.

That being said, I've never really understood this error -- OpenGL is supposed to automatically swap memory back and forth to the GPU as required, so I don't understand why it would feel that it's out of memory, other than if it's really out of virtual memory in the host process, which seems quite hard to achieve on 64-bit systems. Are you perhaps running 32-bit Java? (Not that I really think it would run out of 32-bit virtual memory either, but that might at least be feasible, given enough fragmentation or something.)

The problem does seem to appear far more often on Intel GPUs; again not sure why, but could perhaps be another example of subpar OpenGL implementation from Intel. I've considered trying to auto-manage texture memory by expunging textures that haven't been used for a while, but since I don't really understand why the error happens to begin with, I'm not sure if the investment would be worth in case it doesn't help anyway.

[Redlaw]

I currently have both 32 bit and 64 bit java on my machine. 64 does take over, but given even google chrome wants the 32 bit one.... idk which one this is using, one thing I can do in uninstall another program I use its been building a cache for like 6 some months and as it goes can cause lag and its own issues. I do not know how much doing that will help H&H but it might reduce my memory load.

if need be I can also uninstall the 32 bit one off my machine so it does not load up with the wrong one... but idk how much of a part of this, this is.


But it could just chock down to as was said an Intel error in there programming/hardware.

[loftar]

if need be I can also uninstall the 32 bit one off my machine so it does not load up with the wrong one... but idk how much of a part of this, this is.

Well, 64-bit Java is better anyway, as the 32-bit variant still uses the inferior client-mode compiler on Windows and has less registers and what not.

[Redlaw]

It does seem that the base client was loading up in 32 bit java. Since I had to close the client in order to uninstall. Now to see how things run.