[GLASSFISH-2693] Memory Leak in ORB Created: 23/Mar/07  Updated: 01/Oct/10

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 9.1pe
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: Scott Oaks Assignee: huntch
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2,693

 Description   

I'm running the new CORBA code on a really big (64-CPU) system, and
eventually I'm getting memory errors from the client:

Exception in thread "Thread-29613" 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 sun.nio.ch.Util.getTemporaryDirectBuffer(Util.java:57)
at sun.nio.ch.IOUtil.write(IOUtil.java:69)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.write(SocketOrChannelConnectionImpl.java:755)
at
com.sun.corba.ee.impl.encoding.CDROutputObject.writeTo(CDROutputObject.java:170)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.sendWithoutLock(SocketOrChannelConnectionImpl.java:1125)
at
com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.sendFragment(BufferManagerWriteStream.java:120)
at
com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.sendFragment(BufferManagerWriteStream.java:120)
at
com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.sendMessage(BufferManagerWriteStream.java:134)
at
com.sun.corba.ee.impl.encoding.CDROutputObject.finishSendingMessage(CDROutputObject.java:129)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.finishSendingRequest(CorbaMessageMediatorImpl.java:260)
at
com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete1(CorbaClientRequestDispatcherImpl.java:346)
at
com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete(CorbaClientRequestDispatcherImpl.java:324)
at
com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:192)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:163)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:123)
at
com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:196)

You'll notice that the thread in question is indeed number 29613. That's
part of how the test works: the client creates a new thread for
every request it makes (it may make 3 or 4 IIOP calls to the server,
which is a logical operation in terms of the workload, but then it
exits). It might be that there is a direct buffer per thread that isn't getting
cleaned up.

The corba client (and server) are being run with these arguments:
-Dcom.sun.corba.ee.transport.ORBOptimizedReadAlwaysEnterBlockingRead=true
-Dcom.sun.corba.ee.transport.ORBBlockingReadCheckMessageParser=false



 Comments   
Comment by gfbugbridge [ 05/Apr/07 ]

<BT6543285>

Comment by Ken Cavanaugh [ 06/Apr/07 ]

Re-assigning to Charlie.

Comment by huntch [ 10/Apr/07 ]

Under the test configuration there is no use of DirectByteBuffers at the
application level. However, their may be a problem with the timeliness of
DirectByteBuffers being cleaned up in sun.nio.ch.Util.getTemporaryDirectBuffer
which maintains a pool of DirectByteBuffers. Also note that DirectByteBuffer
constructors allocate memory based on the operating system's page size plus the
requested capacity. So, if the JVM is configured to use large page sizes (i.e.
256m), each DirectByteBuffer allocation will allocate 256m + the requested size.
If garbage collection does not occur in a timely manner, since
DirectByteBuffers rely on a finalizer to free the allocated memory, a 32-bit
address space could be used up pretty quickly when using large pages.

Comment by Ken Cavanaugh [ 26/Apr/07 ]

This bug mainly affects a test driver that creates a large number of
threads very quickly. Fix requires implementing new direct buffer pool
management, which cannot be accomplished for beta 3.

Comment by Ken Cavanaugh [ 06/Feb/08 ]

Moved target to V3.

Comment by Ken Cavanaugh [ 23/Mar/10 ]

Moving to v3.1 for later investigation.





Generated at Mon Mar 27 13:53:42 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.