Sun Vs MS JVM Statistics

Does anybody know where to find uptodate percentagestatistics on current usage of Microsoft Vs Sun JVM or may be downloads.

I believe MS is no longer allowed to market its JVM, and the only users of it remaining are those who got it originally. I take it that eventually MS JVM will disappear from the market. I'd base on Sun's for any new development.

Similar Messages

  • Java.lang.NullPointerException at com.sun.tools.javac.jvm.ClassReader.fillI

    Hi,
    I got the following during build. Any ideas?
    Thanks in advance.
    javac An exception has occurred in the compiler (1.5.0_12). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you.
    javac java.lang.*NullPointerException*
    javac at com.sun.tools.javac.jvm.*ClassReader.fillIn(ClassReader.java:1583)*
    javac at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1535)
    javac at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355)

    There is a bug in the compiler.
    You would need to localize the problem to the source file, class and specific code. Once you do that you can file a bug but do not count on a fix without updating to 1.6. However locating it would allow you to modify the code to get around this problem.

  • Running WL 6.1 SP2 on Sun's new JVM 1.4

    Hi all,
    First a bit of background to my request.
    We have an WL application running on Solaris that simply must have a very large
    EJB cache since the time taken to load each EJB and its dependent objects is very
    large. We frequently do operations over large sets of the objects.
    Because of this, these objects end up being tenured to the old part of the JVMs
    heap, I'm talking up to a gigabyte+ of data. We have tried every option to the
    garbage collector on Sun's 1.3.1 JVM to improve performance, but cannot get rid
    of the fact that a major garbage collection will take place once every minute
    or so, and when it does, it takes about 2.5 secs for each 40 meg in the old heap,
    in short a horrible pause and all processors are locked out for that duration.
    It's a highly interactive application. We have tried using -Xincgc for incremental
    garbage collection but major collections still take place, although less often,
    still enough to pose a serious problem, increasingly so as the heap gets larger.
    This is a real blow for enterprise Java computing with large caches, the JVMs
    to date are just not designed for large multi-threaded server side apps
    JVM 1.4 is said to have addressed some of this with parallel garbage collection,
    which would mean our WL application threads could keep running while GC is taking
    place. So we tried booting up WL 6.1 on JDK 1.4. We did install the 64 bit version
    since we are running 64 bit Solaris.
    With the 32 bit option to the JVM, we get a static initialiser problem the second
    we start it, with the 64 bit option, we get cannot find execv() or some such function.
    So my question is, has anybody successfully run their WL 6.1 on the new JDK 1.4,
    or any version of WL for that matter. If so, did you have to do anything specific,
    patches, OS reconfigs etc to get it to run? If anybody from BEA is reading, is
    BEA likely to certify WL 6.1 on JVM 1.4?
    No doubt somebody will probably mention giving JRockit a go, a server side JVM
    designed from the ground up for the type of app I'm talking about. BEA used it
    recently to get their latest benchmark with WL 7.0 beta.
    We did download this and try it. Unfortunately, JRockit on Solaris is only at
    a 3.0 release compared to the later 3.1 release on NT and Linux. Firstly the 3.0
    starts up way slower than the 3.1 release. But that's ok, one can live with a
    slower startup. Once started up on Solaris (2.8), it does run quickly alright,
    but after a while it just simply hangs, with no errors or anything, the process
    stays alive with 0% CPU, and does nothing, you can't connect to WL or anything,
    you just have to kill it. Other groups with my organization experienced the same
    thing on Solaris. We wrote to JRockit who said yes they have similar problems
    with Solaris in their own labs but could not say when there will be another release.
    We simply have to deploy on Solaris, so JVM 1.4 right now seems my only hope.
    Any info greatly received.
    Regs,
    Paul

    It should be fairly easy for you to track down who's calling System.gc().
    I believe the Sun JDK has the java.lang.* sources bundled with the jvm (or perhaps it's
    a separate download.) Add a Thread.dumpStack() to System.java, re-compile, and prepend
    your new version to the bootclasspath. (type java -X for more info on setting the
    bootclasspath)
    -- Rob
    Paul Hammond wrote:
    Thanks a lot Danny, will check that.
    Actually I should mention that using the non standard
    -XX:+DisableExplicitGC option to the JVM got rid of practically all the full GCs,
    seems like probably WebLogic or possibly some other third party library periodically
    calls System.gc() and this really kills it if you have a large old heap.
    Regs,
    Paul
    Danny Foncke <[email protected]> wrote:
    There's something at :
    http://www.genuitec.com/products.htm#weblogic_jdk14
    Danny
    Paul Hammond wrote:
    Hi all,
    First a bit of background to my request.
    We have an WL application running on Solaris that simply must havea very large
    EJB cache since the time taken to load each EJB and its dependent objectsis very
    large. We frequently do operations over large sets of the objects.
    Because of this, these objects end up being tenured to the old partof the JVMs
    heap, I'm talking up to a gigabyte+ of data. We have tried every optionto the
    garbage collector on Sun's 1.3.1 JVM to improve performance, but cannotget rid
    of the fact that a major garbage collection will take place once everyminute
    or so, and when it does, it takes about 2.5 secs for each 40 meg inthe old heap,
    in short a horrible pause and all processors are locked out for thatduration.
    It's a highly interactive application. We have tried using -Xincgcfor incremental
    garbage collection but major collections still take place, althoughless often,
    still enough to pose a serious problem, increasingly so as the heapgets larger.
    This is a real blow for enterprise Java computing with large caches,the JVMs
    to date are just not designed for large multi-threaded server sideapps
    JVM 1.4 is said to have addressed some of this with parallel garbagecollection,
    which would mean our WL application threads could keep running whileGC is taking
    place. So we tried booting up WL 6.1 on JDK 1.4. We did install the64 bit version
    since we are running 64 bit Solaris.
    With the 32 bit option to the JVM, we get a static initialiser problemthe second
    we start it, with the 64 bit option, we get cannot find execv() orsome such function.
    So my question is, has anybody successfully run their WL 6.1 on thenew JDK 1.4,
    or any version of WL for that matter. If so, did you have to do anythingspecific,
    patches, OS reconfigs etc to get it to run? If anybody from BEA isreading, is
    BEA likely to certify WL 6.1 on JVM 1.4?
    No doubt somebody will probably mention giving JRockit a go, a serverside JVM
    designed from the ground up for the type of app I'm talking about.BEA used it
    recently to get their latest benchmark with WL 7.0 beta.
    We did download this and try it. Unfortunately, JRockit on Solarisis only at
    a 3.0 release compared to the later 3.1 release on NT and Linux. Firstlythe 3.0
    starts up way slower than the 3.1 release. But that's ok, one can livewith a
    slower startup. Once started up on Solaris (2.8), it does run quicklyalright,
    but after a while it just simply hangs, with no errors or anything,the process
    stays alive with 0% CPU, and does nothing, you can't connect to WLor anything,
    you just have to kill it. Other groups with my organization experiencedthe same
    thing on Solaris. We wrote to JRockit who said yes they have similarproblems
    with Solaris in their own labs but could not say when there will beanother release.
    We simply have to deploy on Solaris, so JVM 1.4 right now seems myonly hope.
    Any info greatly received.
    Regs,
    Paul

  • How can I create Object Tag which supports Sun and MS JVM both.

    Hi,
    I have created object tag as shown below
    <object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
    name = "TestApplet" height="0" width="0" >
    <param name="code" value="com.apps.TestApplet.class" />
    <param name="codebase" value="codes" />
    <param name="archive" value="TestApplet.jar" />
    </object>
    The above tag is working fine with the below JVM combinations in Windows XP.
    1) Only Sun JVM
    2) Only MS JVM
    3) Sun JVM & MS JVM
    But these conditions are not working with Windows 2000.
    How we can create object tag which will support for these two opertating systems?

    I am not able to understand the problem. From my understanding, you have an applet which you are trying to display in a browser using <object> tag. If that is the correct then all it matters is the browser and the JRE�
    For example the below code when put in a JSP or a HTML, will use JRE 1.6.0_01 that is available on the client machine. If that is not available on the client machine then it will try and download automatically in IE.
    This below code is for IE� if you are using Mozilla Firefox then you need to change the �classid� attribute to �java: com.foo.bar.ui.MyClass�
    <OBJECT ID="Gantt" classid = "clsid:CAFEEFAC-0016-0000-0001-ABCDEFFEDCBA"
                  codebase = "http://java.sun.com/update/1.6.0/jinstall-6u1-windows-i586.cab"
                  WIDTH = "980" HEIGHT = "495" ALIGN = "baseline">
                   <PARAM NAME="cache_option" VALUE="Plugin">
                  <PARAM NAME ="CODE" VALUE = "com.foo.bar.ui.MyClass" >
                  <PARAM NAME="MAYSCRIPT" VALUE="true">
                  <PARAM NAME ="cache_archive" VALUE = "Myjar.jar /" >
                  <PARAM NAME = "type" VALUE = "application/x-java-applet;jpi-version=1.6.0">
                  <PARAM NAME = "scriptable" VALUE = "false">
                  <strong>
                     This browser does not have a Java 1.6.0_01 Plug-in.
                     <br />
                     <a href="http://java.sun.com/update/1.6.0/jinstall-6u1-windows-i586.cab">
                       Get the latest Java Plug-in here.
                     </a>
              </strong>
            </OBJECT>

  • Can I run SUN and BEA JVM with WL9.1 on Solaris 9

    Is it possible to run a WL9.1 domain on SUN JVM and another one on BEA JRockit? The reason I asked is that for the WL9.1 Sparc download, there's one for Solaris 8,9 and 10 on Sparc and there's another one for Solaris 9 with JRockit Supported. Is this mean I have to install both on 2 separate BEA home?

    Right, I read the docs. What's confusing is that on the WLS download page, there's a download for the Solaris Sparc 8,9,10 (server910_solaris32.bin). There's another download for Solaris 9 with JRockit Supported (server910_generic.jar). For the server910_solaris32.bin, it comes with the SUN JDK. For the server910_generic.jar, it doesn't have the SUN JDK and it needs a separate JRockit download, jrockit-R26.3.0-jdk1.5.0_06-solaris-sparcv9.bin. Also, in the WLS9.1-JRockit install docs, it requires the LD_LIBRARY_PATH to point to sparc64 instead of sparc in the {WL_HOME}/common/bin/commEnv.sh.
    I guess my question is which file should I use for the base WLS install? server910_solaris32.bin or server910_generic.jar? If I use the server910_solaris32.bin, I will need to add JRockit as a separate install. If I use server910_generic.jar, i will need to install JRockit as well as the SUN JDK.

  • SUN Solaris Converting JVM to 64-Bit

    Is anyone familiar with the stpes needed to convert a J2EE instance using 32-bit Java to 64-bit on Sun Solaris? 
    The directory structure on Sun is a bit stange with "sparcv9" directories below /usr/java/bin and usr/java/jre/bin and /usr/java/jre/lib.  The "sparcv9" directories contain the 64-bit java code.
    Thanks,
    Dan

    Hello Dan,
    Unfortunately it is not easy to switch from 32bit to 64bit. The procedure that you need to use is called heterogeneous system copy. Please refer to the following documentation:
    http://help.sap.com/saphelp_nw70/helpdata/en/a2/2f0c173a5e43d19585724239ff4de7/frameset.htm
    System Copy and Migration [original link is broken]
    Regards, Ventsi

  • Sun & Microsoft JVM's

    Is it possible to have both Sun and Microsoft JVM's on the same machine and direct individual applications to the JVM that they are designed to work with best?

    If you're dealing with applications:
    use Java Web Start (http://java.sun.com/products/javawebstart/index.jsp) or a script to specify what precise JRE version to use at run time.
    For applets: use the <applet> tag to use the MS VM and the <OBJECT> or <EMBED> tags to use the JavaPlugin (i.e. the Sun JRE). See http://java.sun.com/products/plugin/index.jsp
    -Alexis

  • Why does JRockit updates lag behind Sun's?

    If I understand correctly, JRockit's class libraries are exactly the same as Sun's.
    Sun has already released update 8 for their 1.5.0 JRE, and JRockit is still at update 6, which means that the class library bugs fixed in update 7 and 8 are still present in JRockit.
    Why does JRockit updates lag behind Sun's? Judging by [url http://forums.bea.com/bea/message.jspa?messageID=600038245&tstart=0]this post, this lag is measured in months!
    Doesn't the VM development happen separate from the class libraries? It should be possible to release a new JRE with the "stable", QA'd JRockit VM and the newest class library (with all its bug fixes) within a week or so, instead of months.

    The class libraries are almost identical, correct. But a JDK update from Sun almost always contains changes in other components than just the class libraries. Some of these affect JRockit, in particular the native libraries (AWT, I/O, etc). Changes in the class libraries may cause performance or stability regressions.
    With every release of JRockit we certify our JDK (Sun classes + JRockit JVM + other components) on a large number of platforms. We did a count earlier this year and came up with around 80 different combinations of JDK level, OS and hardware that we have to test in every release by the end of this year.
    On these platforms we run a huge set of tests, including performance and stress tests. Even though a large part of our QA is automated, it is simply not possible to run everything in parallel so there is a certain minimum amount of time this certification takes. On top of that we have a set of time-consuming tests that have to be run manually.
    To summarize it is simply not possible to do this without some lag. And JRockit has a much quicker uptake than almost all other 3rd party JDK providers (many of them with JVMs based on Sun HotSpot). One example is that it took IBM almost 18 months to get their first J2SE 5.0 implementation out of the door.

  • JVM crash upon webapp deployment to WebLogic 9.1

    I have been tasked with taking a web application that has been working under WebLogic 6.1 and getting it to compile and run under WebLogic 9.1 (using Sun JDK/JRE 1.5). I resolved a few compile problems in Java sources (and commented out a few lines of JSP), made a few build script changes, and was able to compile the app. But as soon as I try to deploy it to WL 9.1 (via autodeploy), the WL process crashes with a HotSpot JVM error:
    Loading services...
    # An unexpected error has been detected by HotSpot Virtual Machine:
    #  Internal Error (53484152454432554E54494D450E43505001A3), pid=6060, tid=5444
    # Java VM: Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode)
    # An error report file with more information is saved as hs_err_pid6060.log
    # If you would like to submit a bug report, please visit:
    #   http://java.sun.com/webapps/bugreport/crash.jsp
    #The hs_err_pid file doesn't contain any clues that I can see; the report just shows that the error occurred somewhere in the VM code. The last line of my AdminServer.log contains:
    <Module poll of application appsdiriCommonsPoll_ear successfully transitioned from STATE_PREPARED to STATE_ADMIN on server AdminServer.> (that ear is the application I'm dealing with.)
    In the past, working with standalone Java programs, I have found many times that a VM crash is ultimately due to native code which caused a memory violation of some kind, but there is no native code in this app. I just started trying to figure out what could be causing this -- does anyone have any insights??
    Thanks for any hints you might have. I'm running this on Win XP Pro, SP 2.
    - Chris

    I just found that the BEA JRockit "R26" build (1.5.0_04) included with WL 9.1 does NOT crash when I start with this web app deployed, whereas the latest Sun 1.5 JVM (1.5.0_12) for Windows still crashes with the same error. Weird!
    Looks like this could be a Sun JVM bug after all, much to my surprise. I'm not taking this as a foregone conclusion though, so if anyone has any other hints, I'm all ears. Thanks.
    - Chris

  • Help on JVM Crash with core dump on solaris - 1.5_17

    Some times in my load test scenarios on sun os boxes JVM crashing with core dump. Here is some dump from the file
    # An unexpected error has been detected by HotSpot Virtual Machine:
    # SIGSEGV (0xb) at pc=0xfea07f40, pid=1564, tid=10
    # Java VM: Java HotSpot(TM) Server VM (1.5.0_17-b04 mixed mode)
    # Problematic frame:
    # V [libjvm.so+0x207f40]
    --------------- T H R E A D ---------------
    Current thread (0x0014e220): JavaThread "CompilerThread1" daemon [_thread_in_native, id=10]
    siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000000
    Registers:
    O0=0x00000010 O1=0x019c1960 O2=0x01e00ec0 O3=0x002bdc48
    O4=0x01042c68 O5=0xc467eb4c O6=0xc467e330 O7=0x01042c68
    G1=0x01e00ea0 G2=0xff014c94 G3=0x000000e6 G4=0x01c5a4e4
    G5=0x01736e20 G6=0x00000000 G7=0xfb9e4200 Y=0x00000000
    PC=0xfea07f40 nPC=0xfea07f44
    --------------- S Y S T E M ---------------
    OS: Solaris 10 5/08 s10s_u5wos_10 SPARC
    Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
    Use is subject to license terms.
    Assembled 24 March 2008
    uname:SunOS 5.10 Generic_127127-11 sun4v (T2 libthread)
    rlimit: STACK 8192k, CORE infinity, NOFILE 65536, AS infinity
    load average:2.73 2.67 2.21
    CPU:total 32 has_v8, has_v9, has_vis1, has_vis2, is_ultra3, is_sun4v, is_niagara1
    Memory: 8k page, physical 8257536k(366576k free)
    vm_info: Java HotSpot(TM) Server VM (1.5.0_17-b04) for solaris-sparc, built on Nov 10 2008 01:58:40 by unknown with unknown Workshop:0x550
    Here is the stack dump of the kill quit thread
    ----------------- lwp# 10 / thread# 10 --------------------
    ff2c5bf0 lwpkill (6, 0, ff2f2e10, ff2a8bd0, ffffffff, 6) + 8
    ff2410f8 abort (7400, 1, 7c00, ad314, ff2f12d8, 0) + 110
    fee7e58c __1cCosFabort6Fi_v_ (1, 0, ff013084, fefde000, 7d94, 7c00) + 58
    fef0de48 __1cHVMErrorOreport_and_die6M_v_ (0, ff03a640, ff033ff4, 1, fee82c88, ff033ff4) + c84
    fea74138 JVM_handle_solaris_signal (b, c467e2b0, c467dff8, 8000, ff032fa0, 14e220) + ab4
    ff2c4b28 __sighndlr (b, c467e2b0, c467dff8, fea7364c, 0, 1) + c
    ff2b9b00 call_user_handler (b, ffbffeff, c, 0, fb9e4200, c467dff8) + 3b8
    fea07f40 __1cMPhaseChaitinFSplit6MI_I_ (c467ec2c, 0, 0, 3677ac, 398, c) + 3410
    fea13c68 __1cMPhaseChaitinRRegister_Allocate6M_v_ (c467eb4c, e88, dc0, ff0137d8, c467fb14, 48d) + 720
    fea17c64 __1cHCompileICode_Gen6M_v_ (c467f218, 9e0c, 9c00, fef56b15, 0, c467ec2c) + 2b0
    fea7ff14 __1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_ (c467f218, 0, 346c8, 0, fef569b8, 0) + c08
    fea75fb8 __1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_ (c467fb14, fef42a90, 1e40f58, 244, 346c8, d1800000) + b0
    fea76b68 __1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_ (908928, 14e7fc, 13c900, 14e220, fef57367, c467fb14) + 4cc
    feb3357c __1cNCompileBrokerUcompiler_thread_loop6F_v_ (ff0330b8, 13c8a0, 14e220, c5e67700, 14e7f8, 0) + 44c
    feadbd20 __1cKJavaThreadDrun6M_v_ (14e220, ff037040, 7820, 0, 7800, 9400) + 2b0
    fee7e0a8 __1cG_start6Fpv_0_ (14e220, 61c, fefde000, 0, 5874, 5800) + 208
    ff2c49fc lwpstart (0, 0, 0, 0, 0, 0)
    Any idea on this dump, helps me a lot.
    Thanks.

    [http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/crashes.html]

  • JVM Setting of Max Heap Equal To Max Perm Size

    Hello,
    I was wondering based on anyones experience or knowledge if there would be any bad effects in setting the Maximum heap size (-Xmxs) equal to the Maximum Permanent Size (-XX:MaxPermSize)?
    I have a person that has the following settings of:
    -native -Xnoclassgc -ms256m -mx256m -XX:MaxPermSize=256M
    running under WLS 6.1 sp1 on a Sun Solaris box.
    Just curious how this would affect applications running under this environment and if it could attribute to a java.lang.outofmemory error be generated.
    Thanks,
    Bob Krause
    PHS

    "Bob Krause" <[email protected]> wrote in message news:19491214.1100812698044.JavaMail.root@jserv5...
    I was wondering based on anyones experience or knowledge if there would be any bad effects in setting the Maximum heap size(-Xmxs) equal to the Maximum Permanent Size (-XX:MaxPermSize)?
    >
    I have a person that has the following settings of:
    -native -Xnoclassgc -ms256m -mx256m -XX:MaxPermSize=256M
    running under WLS 6.1 sp1 on a Sun Solaris box.
    Just curious how this would affect applications running under this environment and if it could attribute to ajava.lang.outofmemory error be generated.
    The settings above don't make much sense. Check java.sun.com for JVM tuning for details.
    Regards,
    Slava Imeshev

  • FYI: Java Enterprise warning: "How to break a Sun box & repair it again"

    Hi there,
    Because of the news that the Java enterprise will be opened up I decided to replace the version I got on my 03/05 media kit with the one being made available right now. Nothing wrong there but the upgrade can be a little tricky since you're adviced to do this manually. Nothing wrong there but I decided to uninstall the current version (Q1) and then re-install the current one (Q4). Only problem; only after I tried installing the Directory server from the current release and uninstalled it.
    This resulted in a little chaos, which was entirely my fault. After entirely uninstalling the Q4 release I tried to remove the Q1 parts. But because the uninstall program (/var/sadm/prod/SUNWentsys4) was already removed I didn't have much alternatives (or so I thought).
    So last night I drank a little too much beer and then went on the "cleaning up" rampage. In my drunken mind I figured "remove all Java enterprise components = uninstalling the whole product". While this idea might make sense, it starts to become an horror story when you realize, like I now do, that the Java enterprise system replaces certain packages on your Solaris 10 system. Packages like, for example, SUNWtls, SUNWjss and (don't laugh) SUNWcsl. So what happens if you simply manually pkgrm the lot ? Well, you'll do the math but I'll give you a little hint by saying that SUNWcsl has something to do with PAM :-)
    So here I was; behind my nice Blade 100 with CDRom & 512Mb memory (soon to be doubled) but with a PC USB keyboard and optical mouse. Its a little hard to press stop-a using a PC keyboard and I got stuck since I removed some very important packages. Reinstall? I don't think so, we're using Unix here and there is always a way around your misery.
    In my case I merely attached a nullmodem cable to the Blade, hooked it onto my Linux workstation, removed keyboard & mouse and started minicom (9600N81). After putting the first install CD (thanks Sun :)) in the drive I booted the system, send a break, booted the CD and exited the installer. Now I was basicly home free since I could mount my system's slices in /tmp/rescue, access the LAN and use pkgadd (pkgadd -d ./ -R /tmp/rescue) to manually re-install the missing packages which disallowed me from logging in. (tip: if you just need a rescue environment quickly just "boot cdrom -s" for single user mode).
    And here I am again, back from the wrecked, typing and studying (Java) on my trusted Blade box again. The moral of this story: Don't drink & "quickly" admin a Sun server, its not worth the risk.
    I've picked up these hints from several websites but didn't encounter anything like this in these forums. I have to admit not having searched very hard (I only googled and used SunSolve) but I figured that this isn't highly classified info so decided to dump it here too for everyone to see. Just remember that doing something horribly stupid like I did doesn't always mean you have to re-install. You'll learn and gain much more experience by fixing things.

    You don't have a problem.
    The MS jvm is not present in the computer. If it was, it would show in IE Tools...Advanced list along with the Sun jvm (There would also be an entry for the MS console in the IE View menu - as opposed to the entry that the Sun console places in the IE Tools menu.)
    The Sun Control Panel is ignorant of the MS jvm (if it's installed).
    I don't use Firefox, but understand that the Control Panel is also ignorant of it; its install/activation is currently done outside of the Control Panel. You can probably find more info at the Firefox site.
    The vulnerability existed in both the MS and Sun (and other) jvm's but you are using a fixed version, as this reference lists:
    http://www3.ca.com/securityadvisor/vulninfo/Vuln.aspx?ID=6885

  • NWDS NW 7.0 EHP2 with SAP JVM 4.1 == server0 crash exit code 666

    I recently installed developer workplace on windows 2003 server SP2, database MS SQL 2005.
    NWDS NW 7.0 EHP2. The installation has been done with SUN JAVA kit. The installed SAP AS JAVA was running OK.
    Several SAP notes indicate that from NW 7.0 customers should switch to SAP JVM. I have switches from SUN to SAP JVM using the switch tool. From that moment on, me server0 keeps on restarting (19 restart) before it finally stops with exit code 666. The log shows out-of-memory. I have checked note 1522200 and 1603093 (and some others)
    Who can help? Has someone this version running in win 2003? I would like to compare the JVM parameters in that case.

    We found a solution. We installed SP02 of NW 7.0 EHP2 from DVD. After upgrading to SP08 with JSPM the problems were gone. Parameter settings in the switch tool (according to the mentioned sap notes) are correct.
    Wilbert Karremans

  • How does JVM (Java Virtual Machine) relate to XI?

    Can somebody describe to me exactly what JVM (Java Virtual Machine) is and how it is related/associated to XI?  Responses are appreciated, thanks in advance!

    HI,
    A Java Virtual Machine (JVM), is a virtual machine that interprets and executes Java bytecode. This code is most often generated by Java language compilers, although the JVM can also be targeted by compilers of other languages. JVMs may be developed by other companies as long as they adhere to the JVM standard published by Sun.
    The JVM is a crucial component of the Java Platform. Because JVMs are available for many hardware and software platforms, Java can be both middleware and a platform in its own right - hence the expression "Write once, run anywhere." The use of the same bytecode for all platforms allows Java to be described as "Compile once, run anywhere", as opposed to "Write once, compile anywhere", which describes cross-platform compiled languages.
    Starting with J2SE 5.0, changes to the JVM specification have been developed under the Java Community Process as JSR 924[1]. As of 2006, changes to specification to support changes proposed to the class file format (JSR 202[2]) are being done as a maintenance release of JSR 924. The specification for the JVM is published in book form[3], known as "blue book". The preface states:
    We intend that this specification should sufficiently document the Java Virtual Machine to make possible compatible clean-room implementations. Sun provides tests which verify the proper operation of implementations of the Java Virtual Machine.
    Sun's JVM is called HotSpot. Clean-room Java implementations include Kaffe and IBM's. Sun retains control over the Java trademark, which it uses to certify implementation suites as fully compatible with Sun's specification
    we have two caches JAVA,ABAP.
    i mean all objects which will execute in JAVA Cache those need the JVM.
    Regards
    Chilla

  • Reliable JVM crash on our internal benchmark

    Hi,
    I just downloaded and tried out BEA JRockit R27.3.0 JDK
    1.5.0_11 under both ia64 and x64 architectures and our internal benchmark
    reliably causes the JVM to crash. I also tried out R27.1 under ia64 and that crashed as well.
    I tried out about a dozen different command line arguments
    to try to see if I could avoid this crash, but nothing
    seemed to help. Any help with resolving this would be greatly appreaciated. This benchmark
    has been working
    successfully on Sun and IBM JVM's for over a year. The
    codebase for the benchmark is quite large >64K methods
    and it is very memory intesive (it requires about 8GB
    of RAM).
    --Tony Brusseau
    Cycorp, Inc.
    The stack trace always looks similar to this:
    Thread Stack Trace:
    at get_ifdoffset+35()@0x2aaaab1e6b37
    at dtGetVirtualMethodIndex+21()@0x2aaaab1e7771
    at dtGetVirtualMethodOffset+9()@0x2aaaab1e778c
    at cgGetVirtualMethodOffset+9()@0x2aaaab1ca5e8
    at expand_call_dispatch_java_virtual+289()@0x2aaaab2b8bd6
    at expand_call_dispatch+158()@0x2aaaab2ac344
    at expand_call+190()@0x2aaaab2ac437
    at cgTranslateMIROpToLIROp+281()@0x2aaaab2abb96
    at cgExpandIR+190()@0x2aaaab1ca231
    at cgTranslateMIR2LIR+96()@0x2aaaab2aba59
    at generateMethodWithStage+25()@0x2aaaab1cc723
    at cmgrGenerateMethodFromPhase+216()@0x2aaaab1cd5c4
    at cmgrGenerateNormalMethod+69()@0x2aaaab1cc6e6
    at cmgrGenerateCode+243()@0x2aaaab1cc5e1
    at generate_code2+205()@0x2aaaab2a8099
    at codegenThread+963()@0x2aaaab2a8711
    at tsiCallStartFunction+67()@0x2aaaab2826af
    at tsiThreadStub+308()@0x2aaaab2838a3
    at ptiThreadStub+14()@0x2aaaab2e9753
    at start_thread+147()@0x2aaaaabce193
    -- Java stack --
    ===== BEGIN DUMP =============================================================
    JRockit dump produced after 0 days, 00:05:43 on Mon Jul 9 19:29:12 2007
    Additional information is available in:
    /scratch/xxx/cyc-sys1.12439-kb0936/jrockit.13609.dump
    No snapshot file (core dump) will be created because core dumps have been
    disabled. To enable core dumping, try "ulimit -c unlimited"
    before starting JRockit again.
    If you see this dump, please open a support case with BEA and
    supply as much information as you can on your system setup and
    the program you were running. You can also search for solutions
    to your problem at http://forums.bea.com in
    the forum jrockit.developer.interest.general.
    Error Message: Illegal memory access. [54]
    Signal info : si_signo=11, si_code=1 si_addr=0x72b3240
    Version : BEA JRockit(R) R27.3.0-106-83792-1.5.0_11-20070607-1612-linux-x86_64
    GC Strategy : Mode: static, with strategy: genconcon
    GC Status : OC is not running. Last finished OC was OC#0.
    : YC is not running. Last finished YC was YC#8.
    YC History : Ran 8 YCs since last OC.
    Heap : 0x2aaaab771000 - 0x2aacab771000
    Compaction : (no compaction area)
    NurseryList : 0x2aaaab771000 - 0x2aab2b771000
    KeepArea : 0x2aaaeb770fe8 - 0x2aab0b770fd8
    NurseryMarker: [ 0x2aaaeb770fe8,  0x2aab0b770fd8 ]
    CompRefs : References are uncompressed 64-bit.
    CPU : Intel Pentium 4 (HT) SSE SSE2 SSE3 NetBurst EM64T
    Number CPUs : 4
    Tot Phys Mem : 16831234048 (16051 MB)
    OS version : SUSE LINUX 10.1 (X86-64)
    VERSION = 10.1
    Linux version 2.6.16.13-4-smp (geeko@buildhost) (gcc version 4.1.0 (SUSE Linux)) #1 SMP Wed May 3 04:53:23 UTC 2006 (x86_64)
    Thread System: NPTL
    State : JVM is running (Main thread has finished)
    Command Line : -Xgc:gencon -XXgcThreads:4 -Xns2048m -Xms8192m -Xmx8192m -Dsun.java.launcher=SUN_STANDARD -Xmx11000m com.cyc.tool.subl.jrtl.nativeCode.subLisp.SubLMain -i init/jrtl-release-init.lisp
    java.home : /cyc/tools-noarch/java/jrockit-jdk1.5.0_11/jre
    j.class.path : /cyc/java/lib/UtilConcurrent.jar:/cyc/tools-noarch/java/netbeans-5.5.1/ide7/modules/ext/junit-3.8.1.jar:/scratch/cyc/java/netbeans/project/SubL/build/classes
    j.lib.path : /cyc/tools-noarch/java/jrockit-jdk1.5.0_11/jre/lib/amd64/jrockit:/cyc/tools-noarch/java/jrockit-jdk1.5.0_11/jre/lib/amd64:/cyc/tools-noarch/java/jrockit-jdk1.5.0_11/jre/../lib/amd64:/cyc/tools-noarch/java/jdk1.6.0_64bit/jre/lib/amd64/server:/cyc/tools-noarch/java/jdk1.6.0_64bit/jre/lib/amd64:/cyc/tools-noarch/java/jdk1.6.0_64bit/jre/../lib/amd64:/opt/local/lib:/usr/local/lib:/lib:/usr/lib
    JAVA_HOME : /cyc/tools-noarch/java/jdk1.6.0_64bit
    JAVAOPTIONS: -Xmx11000m
    LD_LIBRARY_PATH: /cyc/tools-noarch/java/jrockit-jdk1.5.0_11/jre/lib/amd64/jrockit:/cyc/tools-noarch/java/jrockit-jdk1.5.0_11/jre/lib/amd64:/cyc/tools-noarch/java/jrockit-jdk1.5.0_11/jre/../lib/amd64:/cyc/tools-noarch/java/jdk1.6.0_64bit/jre/lib/amd64/server:/cyc/tools-noarch/java/jdk1.6.0_64bit/jre/lib/amd64:/cyc/tools-noarch/java/jdk1.6.0_64bit/jre/../lib/amd64:/opt/local/lib:/usr/local/lib:/lib:/usr/lib
    LD_ASSUME_KERNEL: <not set>
    C Heap : Good; no memory allocations have failed
    Method : com/cyc/cycjava/cycl/clauses.clause_p(Lcom/cyc/tool/subl/jrtl/nativeCode/type/core/SubLObject;)Lcom/cyc/tool/subl/jrtl/nativeCode/type/core/SubLObject;
    StackOverFlow: 0 StackOverFlowErrors have occured
    OutOfMemory : 0 OutOfMemoryErrors have occured
    Registers (from ThreadContext: 0x40088770 / OS context: 0x40088830):
    rax = 0000000006acaaf0 rcx = 00000000007e8750
    rdx = 00000000006acaaf rbx = 00000000002d58b0
    rsp = 0000000040088c70 rbp = 0000000040088c80
    rsi = 00000000002d58b0 rdi = 00000000002d4b58
    r8 = 0000000040088c84 r9 = 0000000000000001
    r10 = 0000000040088cc8 r11 = 0000000000000002
    r12 = 00002aadb8ad0408 r13 = 00002aadb8ade9d8
    r14 = 0000000010000038 r15 = 0000000040089080
    cs = 0000000000000033 fs = 0000000400000000
    gs = 0004000000000000
    rip = 00002aaaab1e6b37 flags = 0000000000000206
    Stack:
    (* marks the word pointed to by the stack pointer)
    0000000040088c70: 1000003840088cb0* 00002aadb8ae27a0 0000000040088c90 00002aaaab1e7771
    0000000040088c90: 0000000040088ca0 00002aaaab1e778c 0000000040088cb0 00002aaaab1ca5e8
    0000000040088cb0: 0000000040088d20 00002aaaab2b8bd6 0000000030000001 0000000010000038
    0000000040088cd0: 0000000040088d50 00000000002d58b0 000000000056c878 0000000010000022
    0000000040088cf0: 00000000002d4b58 00002aadb8ade9d8 00002aadb8ad0408 000000000056c878
    0000000040088d10: 0000000040089080 00002aadb8ade9d8 0000000040088d50 00002aaaab2ac344
    Code:
    (* marks the word pointed to by the instruction pointer)
    00002aaaab1e6ad0: 02000001b8bf83d5 eb00000000b80775 894c00000d3ce825 53034804e2c148e2
    00002aaaab1e6af0: 04e2c148128b4858 c148ea894cd00148 8b4810048b4804e2 8b4cf0658b4ce85d
    00002aaaab1e6b10: e5894855c3c9f86d f3894808ec834853 c1894800000cfde8 1774caff48108b48
    00002aaaab1e6b30: 4804e0c148d08948* d089480575011c39 b8e975caff480aeb 08c4834800000000
    00002aaaab1e6b50: 48e5894855c3c95b fffffe7ae828768b 8b4ce5894855c3c9 0000be28568b4806
    00002aaaab1e6b70: 000001dc8f8b0000 048d482073ce3948 47034800000000f5 21e8077500394c68
    Loaded modules:
    (* denotes the module causing the exception)
    0000000000400000-000000000041192b /cyc/tools-noarch/java/jrockit-jdk1.5.0_11/bin/java
    00002aaaaabc8000-00002aaaaabd8570 /lib64/libpthread.so.0
    00002aaaaacde000-00002aaaaad3199b /lib64/libm.so.6
    00002aaaaae33000-00002aaaaae34edb /lib64/libdl.so.2
    00002aaaaaf38000-00002aaaab05dfdd /lib64/libc.so.6
    00002aaaaaaab000-00002aaaaaac5be7 /lib64/ld-linux-x86-64.so.2
    00002aaaab169000-00002aaaab3feccf */cyc/tools-noarch/java/jrockit-jdk1.5.0_11/jre/lib/amd64/jrockit/libjvm.so
    00002aaaab667000-00002aaaab66e058 /lib64/librt.so.1
    00002aad732c7000-00002aad732d3647 /cyc/tools-noarch/java/jrockit-jdk1.5.0_11/jre/lib/amd64/libverify.so
    00002aad733d6000-00002aad733fa493 /cyc/tools-noarch/java/jrockit-jdk1.5.0_11/jre/lib/amd64/libjava.so
    00002aad73529000-00002aad7353b14b /lib64/libnsl.so.1
    00002aadb368f000-00002aadb3697e3f /cyc/tools-noarch/java/jrockit-jdk1.5.0_11/jre/lib/amd64/native_threads/libhpi.so
    00002aadb37bc000-00002aadb37caef3 /cyc/tools-noarch/java/jrockit-jdk1.5.0_11/jre/lib/amd64/libzip.so
    00002aadb3b30000-00002aadb3b42067 /cyc/tools-noarch/java/jrockit-jdk1.5.0_11/jre/lib/amd64/libnet.so
    00002aadb8130000-00002aadb813677b /cyc/tools-noarch/java/jrockit-jdk1.5.0_11/jre/lib/amd64/libnio.so
    "(Code Optimization Thread 1)" id=4 idx=0x10 tid=13616 lastJavaFrame=0xfffffffffffffffc
    Stack 0: start=0x40068000, end=0x4008c000, guards=0x4006d000 (ok), forbidden=0x4006b000
    Thread Stack Trace:
    at get_ifdoffset+35()@0x2aaaab1e6b37
    at dtGetVirtualMethodIndex+21()@0x2aaaab1e7771
    at dtGetVirtualMethodOffset+9()@0x2aaaab1e778c
    at cgGetVirtualMethodOffset+9()@0x2aaaab1ca5e8
    at expand_call_dispatch_java_virtual+289()@0x2aaaab2b8bd6
    at expand_call_dispatch+158()@0x2aaaab2ac344
    at expand_call+190()@0x2aaaab2ac437
    at cgTranslateMIROpToLIROp+281()@0x2aaaab2abb96
    at cgExpandIR+190()@0x2aaaab1ca231
    at cgTranslateMIR2LIR+96()@0x2aaaab2aba59
    at generateMethodWithStage+25()@0x2aaaab1cc723
    at cmgrGenerateMethodFromPhase+216()@0x2aaaab1cd5c4
    at cmgrGenerateNormalMethod+69()@0x2aaaab1cc6e6
    at cmgrGenerateCode+243()@0x2aaaab1cc5e1
    at generate_code2+205()@0x2aaaab2a8099
    at codegenThread+963()@0x2aaaab2a8711
    at tsiCallStartFunction+67()@0x2aaaab2826af
    at tsiThreadStub+308()@0x2aaaab2838a3
    at ptiThreadStub+14()@0x2aaaab2e9753
    at start_thread+147()@0x2aaaaabce193
    -- Java stack --
    Additional information is available in:
    /scratch/tbrussea/cyc-sys1.12439-kb0936/jrockit.13609.dump
    No snapshot file (core dump) will be created because core dumps have been
    disabled. To enable core dumping, try "ulimit -c unlimited"
    before starting JRockit again.
    If you see this dump, please open a support case with BEA and
    supply as much information as you can on your system setup and
    the program you were running. You can also search for solutions
    to your problem at http://forums.bea.com in
    the forum jrockit.developer.interest.general.
    Extended, platform specific info:
    libc release: 2.4-development
    Elf headers:
    libc ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 000000000001d250 PHOFF: 0000000000000040 SHOFF: 0000000000134448 EF: 0x0 HS: 64 PS: 56 PHN; 11 SS: 64 SHN: 69 STIDX: 66
    libpthread ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0000000000005a20 PHOFF: 0000000000000040 SHOFF: 0000000000012770 EF: 0x0 HS: 64 PS: 56 PHN; 10 SS: 64 SHN: 36 STIDX: 33
    libjvm ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 000000000003ede0 PHOFF: 0000000000000040 SHOFF: 000000000036c3c8 EF: 0x0 HS: 64 PS: 56 PHN; 3 SS: 64 SHN: 22 STIDX: 19
    ===== END DUMP ===============================================================
    Edited by APB1 at 07/10/2007 9:54 AM

    Tony,
    I don't know if its related, but this can happen on SUN JVM if some class touches the final fields of CommonSymbols interface like CommonSymbols.TWO_INTEGER too early inciting a class loading that is incomplete. Maybe it is possible that JRocket is doing a pre-optimization process that makes this happen?
    one thing you might try is replacing TWO_INTEGER in
    com/cyc/cycjava/cycl/clauses.java
    with a class static version like:
    in the file "com/cyc/cycjava/cycl/clauses.java"
    public static final SubLFixnum TWO_INTEGER = (SubLFixnum) SubLObjectFactory.makeInteger(2);
    And see if the stack dump moves to an optimization elsewere in the tests.
    Douglas Miles
    [email protected]
    Edited by [email protected] at 07/24/2007 1:14 AM

Maybe you are looking for