Jump to: navigation, search

Difference between revisions of "EclipseLink/Building/64bit"

(32 bit Eclipse on 64 bit OS)
m (References)
 
(3 intermediate revisions by 3 users not shown)
Line 18: Line 18:
 
4096M
 
4096M
 
-showsplash
 
-showsplash
 +
-showlocation
 +
-clean
 
org.eclipse.platform
 
org.eclipse.platform
 
--launcher.XXMaxPermSize
 
--launcher.XXMaxPermSize
Line 27: Line 29:
 
-Xms2048m
 
-Xms2048m
 
-Xmx8192m
 
-Xmx8192m
 +
-XX:+UseParallelGC
 +
 
</pre>
 
</pre>
  
Line 230: Line 234:
 
* http://forums.oracle.com/forums/thread.jspa?threadID=991219&tstart=0
 
* http://forums.oracle.com/forums/thread.jspa?threadID=991219&tstart=0
 
* http://forums.oracle.com/forums/thread.jspa?threadID=983044&tstart=0
 
* http://forums.oracle.com/forums/thread.jspa?threadID=983044&tstart=0
 +
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=366999

Latest revision as of 17:41, 1 October 2012

Contents

EclipseLink 64 Bit Development

  • This page details issues surrounding running EclipseLink, or any Java application using JPA or native ORM in an Eclipse IDE environment on 64 bit OS platforms like Windows 7 64, Vista 64, Windows 64 or Linux 64. We will concentrate on Microsoft Windows 7 64 bit edition.
  • Rembember: java bytecodes are only tokens - they are the machine language for the Java Virtual Machine. Therefore bytecodes that are compiled on a 64 bit JVM, a 32 bit JVM or actually any type of hardware that has a JVM - are the same. They need to be the same because the JVM is the implementation of a specification.
  • The following enhancement # 286004 tracks 64 bit issues and fixes to enable EclipseLink development on 64 bit Windows 7.
    • Note: Eclipse 3.6 64-bit edition requires the use of a 64-bit JVM (it will not function with a 32-bit JVM)

64 bit Eclipse on 64 bit OS

Memory is limited by the machine - here 12G (acts like 6G)

-startup
plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.100.v20110502
-product
org.eclipse.epp.package.jee.product
--launcher.defaultAction
openFile
--launcher.XXMaxPermSize
4096M
-showsplash
-showlocation
-clean
org.eclipse.platform
--launcher.XXMaxPermSize
4096m
--launcher.defaultAction
openFile
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms2048m
-Xmx8192m
-XX:+UseParallelGC

32 bit Eclipse on 64 bit OS

-vm
c:/opt/wls10350_oepe111172/jrockit_160_24_D1.1.2-4/jre/bin/javaw.exe
-startup
plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.2.R36x_v20101222
-showlocation
-showsplash
org.eclipse.platform
--launcher.defaultAction
openFile
--launcher.XXMaxPermSize
2048M
-clean
-vmargs
-Xms1024m
-Xmx2048m
-XX:MaxPermSize=2048m
-Dsun.lang.ClassLoader.allowArraySyntax=true

Benefits of the 64-bit Java Virtual Machine

Increased Integeger performance

  • See the next section for details - but the fact that we are now running with 8-byte words and that the Java Long type which uses the 64-bit C type long long or likely the

JVM In-Memory 4x to 5x speedup running 64 bit SUN JVM from 32 bit version

  • 20100330: I have seen a very surprising result that results in a 4.0 to 4.7 times speedup for pure java in-memory POJO manipulation single threaded applications (without object recreation triggering the GC) when they are run on the 64 bit version of the SUN JVM as opposed to the 32 bit version of the SUN JVM on a 64 bit version of Windows 7.
  • Note: The speedup is less pronounced once you enable disk and net access and allow the GC to run.
  • Also note that since only the server JIT is available as a 64 bit JVM from SUN/Oracle that the startup time is slower - this will not affect EE persistence applications that run on application server containers'

64 Bit SUN JVM Speedup Results

  • Test application consists of a 3 entity tree that contains 1:1 and 1:M relationships - however only the int primitive fields of a single entity were cycled continuously for 200 Million iterations - This may explain the speedup because of the decrease of memory/cache hits due to the double increase in size of IA64 on-chip registers..
  • The fastest time was 40 sec on the 64-bit SUN JVM on a single core of an i7-920 at 2.7GHz - as opposed to the slowest time of 336 sec on the 32-bit SUN JVM on a single HT core of a P4-630 at 3.0GHz - an 8.4 times increase.
  • The results may be any of the following optimizations in the 64 bit SUN JVM
    • 64 bit word length alignment (no 32 bit emulation of 64 bit)
    • 2nd level cache optimization in an IA64 compiled JVM
    • Lack of backwards compatibility for IA32
    • Default JVM configuration is optimized in the IA64 compiled JVM

Machine: Intel IA64 i7-920 under Windows 7 64

  • The 64 bit SUN JVM is 4.1 x faster than the 32 bit SUN JVM.
32 Bit SUN JVM
  • Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  • Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing)
  • Total time: 165.11 sec @ 1211313 iter/sec
64 Bit SUN JVM
  • Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
  • Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
  • Total time: 39.96 sec @ 5005005 iter/sec
32 Bit JRockit JVM
  • BEA JRockit(R) (build R27.6.5-32_o-121899-1.6.0_14-20091001-2107-windows-ia32, compiled mode)
  • Total time: 114.17 sec @ 1751773 iter/sec

Machine: Intel IA64 E8400 under Windows 7 64

  • The 64 bit SUN JVM is 4.0 x faster than the 32 bit SUN JVM.
32 Bit SUN JVM
  • Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
  • Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode, sharing)
  • Total time: 181.696 sec @ 1100739 iter/sec
64 Bit SUN JVM
  • Java(TM) SE Runtime Environment (build 1.6.0_19-b04)
  • Java HotSpot(TM) 64-Bit Server VM (build 16.2-b04, mixed mode)
  • Total time: 45.54 sec @ 4391743 iter/sec

Machine: Intel IA64 Q6600 under Windows 7 64

  • The 64 bit SUN JVM is 3.9 x faster than the 32 bit SUN JVM.
32 Bit SUN JVM
  • Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
  • Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode, sharing)
  • Total time: 215.546 sec @ 927876 iter/sec
64 Bit SUN JVM
  • Java(TM) SE Runtime Environment (build 1.6.0_19-b04)
  • Java HotSpot(TM) 64-Bit Server VM (build 16.2-b04, mixed mode)
  • Total time: 55.146 sec @ 3626736 iter/sec

Machine: Intel IA64 T4400 under Windows 7 64

  • The 64 bit SUN JVM is 4.7 x faster than the 32 bit SUN JVM.
32 Bit SUN JVM
  • Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
  • Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing)
  • Total time: 258.258 sec @ 774419 iter/sec
64 Bit SUN JVM
  • Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
  • Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
  • Total time: 54.71 sec @ 3655638 iter/sec

Machine: Intel IA32 P4-640 under Windows XP 32

  • The 32 bit JRockit JVM is 1.7 x faster than the 32 bit SUN JVM.
32 Bit SUN JVM
  • Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
  • Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing)
  • Total time: 318.062 sec @ 628808 iter/sec
32 Bit JRockit JVM
  • BEA JRockit(R) (build R27.6.0-50_o-100423-1.6.0_05-20080626-2105-windows-ia32, compiled mode)
  • Total time: 190.562 sec @ 1049527iter/sec

Machine: Intel IA32 P4-630 under Windows XP 32

  • The 32 bit JRockit JVM is 1.7 x faster than the 32 bit SUN JVM.
32 Bit SUN JVM
  • Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
  • Java HotSpot(TM) Client VM (build 11.0-b16, mixed mode)
  • Total time: 335.75 sec @ 595681 iter/sec
32 Bit JRockit JVM
  • BEA JRockit(R) (build R27.6.5-32_o-121899-1.6.0_14-20091001-2107-windows-ia32, compiled mode)
  • Total time: 199.766 sec @ 1001171 iter/sec

Running EclipseLink on an XP Virtual Machine in Windows 7

  • Running EclipseLink on an XP virtual machine will alllow you to bypass any issues surrounding Windows 7 and allow you to test configurations without disrupting your current OS setup.
    • You will require the Professional or Ultimate versions.

Running 32 Bit Eclipse in 64 bit Windows

  • To run 32 bit Eclipse 3.5 on 64 bit Windows Vista or 7 you need to install the 32 bit version of the JRE and reference it using the -vm flag in a shortcut to eclipse.exe as follows.
C:\eclipse35d32b\eclipse.exe -vm c:/jdk1.6.0_32bit/bin/java.exe
  • I have run into 3 issues running the 64 bit version of Eclipse 3.5 in conjuction with the 64 bit version of the SUN 1.6 JRE and Ant.
    • The context sensitive popup functionality is not working in Eclipse 3.5 SE edition - I cannot get the list of functions for a class or get autocompletion working. (The 32 bit version is ok)
    • The 64 bit version of Eclipse 3.5 comes without EE enhancements - they must be added via smart update
    • (Solved by 295381) I am starting to see issues with locking of the classes directory - If I do a full clean it is usually fixed but appears in several JPA projects intermittently. I am testing reverting back to the 32 bit version for now.
BUILD FAILED
F:\view_w35b\build.xml:234: The following error occurred while executing this line:
F:\view_w35b\jpa\org.eclipse.persistence.jpa\build.xml:124: Directory F:\view_w35b\jpa\org.eclipse.persistence.jpa\classes creation was not successful for an unknown reason
Total time: 43 seconds
F:\view_w35b>

Windows Vista and Windows 7 64 Bit Development

  • This page in progress as of 11 Aug 2009
  • Windows 7 64 bit was installed on 23 Oct 2009
  • Get a 64 bit capable CPU (A Pentium IV 630 will do but we will be testing on an Intel Corei7 920)
  • Get a lot of memory - like 12GB - (remember in a 64 bit OS - emulated 32 bit memory will be used twice as fast - so 8GB behaves like 4GB - I therefore recommend getting 64 bit versions of all software and
    • 3GB if you are running a database on another machine
    • 6GB if you run a database like Oracle 11 on the same development machine
    • 8GB if you run both the Application Server and database on the same development machine
  • Get SUN 1.6.0 64 Bit JVM
  • Get Eclipse 3.5 64 Bit edition
  • Get TortoiseSVN 64 Bit edition

Issues

282012: Core LRG requires increase to 2048MB heap during final XML processing

  • The following screen capture of the core LRG testing illustrates how the heap dramatically increases during the final step of the ant tests where we create an XML report of the results - this is not related to heap recovery during GC processing.

Core lrg 1024 on i7 12gb reaches 512 but xml proc spike req 1536 .jpg

295381: Ant requires a Command Prompt with run as Administrator security on Windows 7

  • Problem: Running the EclipseLink build on a Windows 7 machine fails periodically with a classes dir creation build error.
BUILD FAILED
F:\view_w35c\build.xml:275: The following error occurred while executing this line:
F:\view_w35c\jpa\eclipselink.jpa.test\build.xml:256: Directory F:\view_w35c\jpa\eclipselink.jpa.test\classes creation was not successful for an unknown reason
Total time: 2 minutes 6 seconds
F:\view_w35c>

BUILD FAILED
F:\view_w35b\build.xml:234: The following error occurred while executing this line:
F:\view_w35b\jpa\org.eclipse.persistence.jpa\build.xml:124: Directory F:\view_w35b\jpa\org.eclipse.persistence.jpa\classes creation was not successful for an unknown reason
Total time: 43 seconds
F:\view_w35b>
  • Reproduction
    • Run the trunk>ant build on any of Windows 7 Home Premium 64-bit or Windows 7 Professional 64-bit
    • The choice of running Eclipse 3.5 32 or 64 bit does not help this issue.
  • Fix: This is a security issue
    • We are able to temporarily fix this by navigating to the parent directory, creating the same directory and deleting it.
    • However, a permanent solution is the following (accept the UAC security check box if not running under UAC=0 level)
    • Run all CMD prompts as "administrator" by checking the following box
      • create a CMD shortcut to cmd.exe
      • right click "Command Prompt" shortcut to get "properties
      • goto "advanced" bottom right check box
      • select "Run as Administrator"

Run 64bit cmd prompt for ant as administrator in win6 win7.jpg

309018: Out Of Memory Error : Java Heap running ant junitreport task on 64 bit JVM

  • solution: temporarily use the 32-bit version

310662: StackOverflowError for 64 linked entities in 6 dimensional hypercube network

  • You will decrease the chance of getting a StackOverflowError for highly connected Entity models like rings or bidirectional trees or arrays by increasing the native stack size.
    • I have found that increasing the stack to the value below pushed the StackOverflowError experienced in a bidirectionally linked
      • 6 dimensional Hypercube model (64 entities and 384 @OneToOne bidirectional links)
      • to a
      • 13 dimensional Hypercube (8192 entities and 106496 @OneToOne bidirectional links) in bug# 310662.
-Xss42m //(Native code cache size)
-Xoss42m //(Java code cache size)
  • I am using the following VM arguments for SE JPA applications
-Xmx1024m
-Xms1024m
-Xss42m
-XX:+UseParallelGC
-XX:PermSize=256M
-XX:MaxPermSize=512M
  • Some further research on this stack overflow issue led me to page 116 of Java Concurrency in Practice by Brian Goetz' - where it is explained that the default 0.5 MB stack size - when increased can still only handle a couple thousand per-thread blocks anyway in a 32-bit memory environment.
    • Therefore even though we are running in a 64 bit environment - the fact that we are still hovering around the 4GB limit - even with 12GB causes 32 bit behaviour. This will persist until we have systems that use 100's of GB ram installations.

References