*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.

*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.

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)

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

32 Bit JRockit JVM

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

Issues

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.

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

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)

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.