Re: [eclipse-clp-users] java.net.SocketException when using OutOfProcessEclipse, seemingly due to insufficient RAM

From: Kish Shen <kisshen_at_cisco.com>
Date: Thu, 15 Sep 2011 16:27:08 +0100
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