Hi David, For OutOfProcessEclipse, the ECLiPSe is run in a different process from the Java, so you should not need to use a "compatible" version (i.e. same word length) of Java as the ECLiPSe. I don't expect changing the settings of the Java VM arguments to make any difference (as I assume it only affects the Java process). The maximum amount of memory that can be allocated for an ECLiPSe process is determined by your OS, as you don't need to share the (virtual) memory space with another process as in EmbeddEclipse. If you are running a 32 bit Windows application, the limit can be relatively low (less than 2G), and I think this even applies if you are running on 64 bit Windows. I can well believe that Windows 7 has a larger allocation limit than XP. However, in order for an OutOfProcessEclipse to allocate more memory, you need to use EclipseEngineOptions to configure the stack sizes before spawning the ECLiPSe. You will most likely want to change the global stack size (eclipse.global-size). I am not that familiar with the Java interface, so I am not sure what will happen when the OutOfProcessEclipse runs out of memory. I expect the process to abort, and so you will not be able to communicate with it via the socket connections. This may be what you are seeing. As Thorsten said, ECLiPSe 6.1 has a 64 bit Windows version. We are not providing it for 6.0 because it involved quite extensive low-level changes to ECLiPSe, due to some quite significant differences in the way Mircosoft C represents integer types. ECLiPSe 6.1 is still not officially released yet because some new components are still in development, but if you stick to the parts that are available in ECLiPSe 6.0, you should be fine. You can allocate much larger stack sizes for the 64 bit version of ECLiPSe, but note that it will need more memory to run the same program when compared to 32 bit ECLiPSe. Most data will consume twice as much memory, except for floating point numbers (which actually uses slightly less memory). Cheers, Kish On 15/09/2011 08:44, -dp- wrote: > We're using ECLiPSe 6.0 (i.e. 32-bit) on Windows7 64-bit. We embed CLP in a > Java 1.6 app run in the EclipseIDE via OutOfProcessEclipse. We use 32 bit > Java and EclipseIDE to be compatible with ECLiPSe 6.0, because there is no > 64 bit version of CLP for Windows that we could find. > > On other Windows machines, using XP, we were getting memory exceeded errors, > so we switched to Win7 64bit and have been experimenting with settings like > the following to try to escape those limitations: > > In the Java IDE's Run Config, "VM Arguments" is set to: > > -Declipse.directory="C:\Program Files (x86)\ECLiPSe 6.0" -Xms128M -Xmx256M > -XX:MaxPermSize=350m > > > Our runs now get about twice as far into the search space, but now we're > running into the following socket error. It seems to suggest that the > spawned CLP process has gone unresponsive: > > java.net.SocketException: Connection reset > at java.net.SocketInputStream.read(SocketInputStream.java:168) > at java.net.SocketInputStream.read(SocketInputStream.java:182) > at java.io.DataInputStream.readByte(DataInputStream.java:248) > at > com.parctechnologies.eclipse.EXDRInputStream.readTerm(EXDRInputStream.java:97) > at > com.parctechnologies.eclipse.RemoteEclipse.readControl(RemoteEclipse.java:1114) > at > com.parctechnologies.eclipse.RemoteEclipse.getNextControlTerm(RemoteEclipse.java:1182) > at > com.parctechnologies.eclipse.RemoteEclipse.getNextControlSignal(RemoteEclipse.java:796) > at > com.parctechnologies.eclipse.EclipseConnectionImpl.waitForEclipse(EclipseConnectionImpl.java:647) > at > com.parctechnologies.eclipse.EclipseConnectionImpl.executeRpc(EclipseConnectionImpl.java:381) > at > com.parctechnologies.eclipse.EclipseConnectionImpl.rpc(EclipseConnectionImpl.java:312) > at > com.parctechnologies.eclipse.OutOfProcessEclipse.rpc(OutOfProcessEclipse.java:362) > at sg.ihpc.wayang.WorldToObserver.go(WorldToObserver.java:89) > at sg.ihpc.wayangTest.Main$1.run(Main.java:62) > at java.lang.Thread.run(Thread.java:662) > > > Of course, there might be some bug in our CLP code that's causing the CLP > process to crash, and we'll keep looking into that. But in case this is > another manifestation of the memory limit issue, we wanted your advice about > how to increase RAM allocated to the OutOfProcessEclipse. Is the use > of MaxPermSize above appropriate and sufficient? > > On June 22 2011, Kish Shen wrote: >> For ECLiPSe 6.0 (the current version of ECLiPSe), 64 bit binary versions >> are available for Linux (running on x86_64), Mac OS X (running on >> x86_64). In ECLiPSe 6.1 (the development version of ECLiPSe), there is >> additionally the 64 bit Windows version (running on x86_64). > > Where could we get this 64bit ECLiPSe 6.1 for Windows? > > David > > > > > ------------------------------------------------------------------------------ > Doing More with Less: The Next Generation Virtual Desktop > What are the key obstacles that have prevented many mid-market businesses > from deploying virtual desktops? How do next-generation virtual desktops > provide companies an easier-to-deploy, easier-to-manage and more affordable > virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ > > > > _______________________________________________ > ECLiPSe-CLP-Users mailing list > ECLiPSe-CLP-Users_at_lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/eclipse-clp-users -- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. Cisco Systems Limited (Company Number: 02558939), is registered in England and Wales with its registered office at 1 Callaghan Square, Cardiff, South Glamorgan CF10 5BT.Received on Thu Sep 15 2011 - 15:27:14 CEST
This archive was generated by hypermail 2.2.0 : Thu Feb 02 2012 - 02:31:58 CET