2 Replies Latest reply: Mar 23, 2012 9:53 AM by 925960 RSS

    Issue with JRockit on Sparc with large heap

    Gerald Nunn
      I am running JRockit with WLP10 MP1 on Solaris and am having a weird issue with JAXB serialization. On out production servers which have a large heap (6GB) I get the following stack trace:

      java.lang.ArrayIndexOutOfBoundsException
      at com.sun.xml.bind.v2.util.CollisionCheckStack.findDuplicate(CollisionCheckStack.java:112)
      at com.sun.xml.bind.v2.util.CollisionCheckStack.push(CollisionCheckStack.java:53)
      at com.sun.xml.bind.v2.runtime.XMLSerializer.pushObject(XMLSerializer.java:471)
      at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:574)
      at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:241)
      at com.sun.xml.bind.v2.runtime.BridgeImpl.marshal(BridgeImpl.java:55)
      at com.sun.xml.bind.api.Bridge.marshal(Bridge.java:72)
      at com.sun.xml.ws.message.jaxb.JAXBMessage.writePayloadTo(JAXBMessage.java:281)
      at com.sun.xml.ws.message.AbstractMessageImpl.writeTo(AbstractMessageImpl.java:126)
      at com.sun.xml.ws.encoding.StreamSOAPCodec.encode(StreamSOAPCodec.java:91)
      at com.sun.xml.ws.encoding.SOAPBindingCodec.encode(SOAPBindingCodec.java:170)
      at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:186)
      at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:235)
      at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:98)
      at weblogic.wsee.jaxws.HttpServletAdapter.post(HttpServletAdapter.java:36)
      at weblogic.wsee.jaxws.JAXWSServlet.doPost(JAXWSServlet.java:219)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:821)
      at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
      at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
      at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
      at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:176)
      at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3395)
      at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
      at weblogic.security.service.SecurityManager.runAs(Unknown Source)
      at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2140)
      at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2046)
      at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1366)
      at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
      at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)

      On all our other servers, which are also Jrockit on SPARC, that have a 2GB heap everything works fine. The above issue happens on 100% of the time with a large heap and does not appear related to multi-threading since we are testing with no users. We were able to determine the issue was related to heap by increasing the heap size on one of our test machines which caused the issue to immediately appear. We are running BEA JRockit(R) Version R27.5.0-110-94909-1.5.0_14-20080204-1536-solaris-sparcv9.

      We can patch the issue with a code fix described in a few posts into this forum post http://forums.java.net/jive/message.jspa?messageID=190811, the fix apparently handles negative hash codes. My question though is why this happens only with large heaps, is JRockit overriding the default hash code generation and does this work differently when large heaps are in play? I have a suspicion, based solely on terminology, that it might have to do with signed/unsigned numbers and references in a large heap situation.