This discussion is archived
4 Replies Latest reply: Jan 30, 2013 3:18 PM by EJP RSS

Compile in 1.5 level using jdk6n and run in jrockitR27

987175 Newbie
Currently Being Moderated
Hi all,
Can someone tell me if there is problem to compile in 1.5 using jdk6?
I am asking this because I have problem in my environment. This is the case.
We have virtual machine in jrockitR27 for jboss 4.04 and 2 virtual machines for tomcat 5.5.17 clustering. The deployment in jboss was compile in java 1.5 using jdk1.5.0_18 and tomcat compile in java 1.5 using jdk1.6. This version is working fine.
After some changes in the code and many test in UAT environment(which is the same with production) and also after stress test, we went live but we got OutOfMemoryError. The only different in the new version is that we had some changes in the code and we compile in java 1.5 using jre6 for jboss and for tomcat compile in java 1.5 using jdk1.6. The outOfMemoryError is throwing in communication of jboss and tomcat. When jboss send hasmap object to tomcat, then tomcat throws outOfMemoryError allocLargeObjectOrArray.
The only different is that new version compile in java 1.5 using jre6. Is there is a problem for that? So tomcat throws outOfMemoryError allocLargeObjectOrArray. I cannot replicate the error in UAT. But I cannot go live just to test again that it is going to work if I make the build in java 1.5 using jdk 1.5. Can someone has any experience in jrockitR27 and outOfMemoryError and compatibility issues?
  • 1. Re: Compile in 1.5 level using jdk6n and run in jrockitR27
    988075 Newbie
    Currently Being Moderated
    Hi,

    This has a lot to do with the Garbage handling mechanism in every JVM that you are using.

    Oracle has provided slightly different ways to collect the garbage and free up memory with versions of JVM the following link would help you on that.

    JVM 5
    http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

    JVM 6
    http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

    JDK 1.6 Adoption
    http://www.oracle.com/technetwork/java/javase/adoptionguide-137484.html

    So with a close look to the above urls you can reconfigure your runtime environments to handle this error.

    Revert for more clarifications.
  • 2. Re: Compile in 1.5 level using jdk6n and run in jrockitR27
    Tolls Journeyer
    Currently Being Moderated
    user2488625 wrote:
    Hi,

    This has a lot to do with the Garbage handling mechanism in every JVM that you are using.
    How can you tell that without any profiling or heap analysis?
    Modifying the garbage collection strategy without actually knowing why the OOM is happening seems a bit arse about face.
  • 3. Re: Compile in 1.5 level using jdk6n and run in jrockitR27
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    984172 wrote:
    After some changes in the code and many test in UAT environment(which is the same with production)
    So your production environment runs on exactly the same hardware as the UAT? And with the same patching?
    I cannot replicate the error in UAT.
    Set the maximum heap size. Run your test. If it does not fail reduce the maximum until it does. It WILL fail at some point. At that point you can determine if the failure is reasonable (the result of a bug) or unreasonable (just too small). If the later then you should look at your stress test to verify that what it tests actually looks like realistic production traffic.
  • 4. Re: Compile in 1.5 level using jdk6n and run in jrockitR27
    EJP Guru
    Currently Being Moderated
    The only different in the new version is that we had some changes in the code and we compile in java 1.5 using jre6 for jboss and for tomcat compile in java 1.5 using jdk1.6.
    You can't compile with a JRE, so there is already something wrong with this statement, and I don't understand where jrockit comes into it, but obviously the first place to look for this problem is the new code. I don't know why you think using a different compiler would affect garbage collection and/or memory usage. It seems a pretty remote possibility to me.

    @PranavS You are going to have to explain to us how different GC strategies can cause OutOfMemoryErrors. That only happens when everything possible has been garbage collected and the amount of new heap memory requested still isn't available. Strategy has nothing to do with it.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points