Re: [idvusers] Maximum Heap Size

Hi Kevin,
Don't know if you've been able to answer your own question yet or not, but while researching another issue I came across this little nugget that might be helpful.
http://java.sun.com/performance/reference/whitepapers/ tuning.html#section4.1.2 

-bruce

On Oct 10, 2007, at 8:52 AM, Tom Whittaker wrote:


Hi Kevin...

No 64 bit experience (or machines) here....however....

I did not need cygwin to run ant on windows, but the 64-bit-ed-ness
might make a difference.
I always just use the instructions at
<http://ant.apache.org/manual>...but then again I'm using a
32 bit machine.

I do not believe you need to run this under cygwin (unless, again,
there is a 64 bit issue), since cygwin is an "environment" (like an
operating system).  From the ant manual:
"We get lots of support calls from Cygwin users. Either it is incredibly 
popular, or it is trouble. If you do use it, remember that Java is a
Windows application, so Ant is running in a Windows process, not a
Cygwin one. This will save us having to mark your bug reports as invalid." 

Hope that helps and not hinders...

tom

On 10/10/07, Kevin Manross <kevin.manross@xxxxxxxx> wrote:


Greetings!

I've decided to try to build IDV from the source code on a 64-bit
computer to try and answer my own question.  However, the only 64-bit
computer that I have access to is a Windoze machine (running a 64-bit
version of XP).

I know that Ant is required to build the IDV from the source, and it
looks like you can run Ant on windoze using Cygwin.  I have some
familiarity with Cygwin, but often seem to have problems with setting my 
paths, particularly when it comes to invoking java through Cygwin.
Could anyone help me with either A) "how to build IDV on a windoze box", 
or B) setting up my cygwin path?

Many thanks!!

-kevin.


Kevin Manross wrote:

Good thread!
It sounds as if the caching will at least allow me to load al my data in 
and it should be sufficient for data analysis.  If we want to create
long loops, we'll do that through ISL.

Getting back to what I understand about the Java heap, and what
Valentijn has described, the limitation is dependent on:

Physical RAM
Architecture (32 bit vs. 64 bit)
OS
Java Version(?)
However, even if I have a 64-bit machine with 4-8 Gb RAM running 64-bit 
version of WindozeXP (Or linux), the IDV comes with its own JVM.

Will this limit my potential heap size?
Would I be better off to install the 64-bit version of Java (Java3D?) and then download/build the IDV so it uses the computer's native JVM? 

Thanks!!

-kevin.


HansPeter Roesli wrote:


Hi all
This caching is what I was looking for since some time. Good to know 
it is there now. I am currently testing it with a long and heavy
satellite image loop (keep fingers crossed).
I am running IDV on 2 notebooks, both with 2GB of RAM. One runs under 
XP and I cannot safely go beyond 1000m. On the other one under SuSE
Linux 10.1 RAM is set to 1512m.

Cheers, HP

Valentijn Venus wrote:


Kevin. Jeff,

that new caching facility does sound promising!

As far as i know JAVA Heap spaces can grow unlimited on (OPen)
Solaris systems, and probably also on Linux 64-bit with JAVA 64- bit 
but maybe someone else would be able to tell you...

Here are some of our experiences assigning space heap sizes all
running IDV from a Java webstart jnlp:

-Linux 64-bit takes you up to 3.5 Gb
-Windows 32-bit varies (depending on what dll's are loaded at which 
memory address) roughly 1.5 Gb
see some of the jnlp's at http://adde.itc.nl at the "Download" section.
We'll have to wait for Dolphin JAVA virtual machine for large memory 
addressing to make it into JAVA webstart which by then will also
support all the 64-bit goodies.
Jeff, would you be able to tell if a 64-bit version of java3d is in the making or will these two (32-bit java3d & 64-bit jvm) co- exist 
happily together?
Kind regards, Valentijn V. Venus, M.Sc. Researcher/Lecturer in RS/GIS 
for Food Security ITC
P.O.Box 6
7500 AA Enschede
The Netherlands
Tel: +31-53-4874549
Fax:+31-53-4874388

=============================================================== De
informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en de 
afzender direct te informeren.
=============================================================== The 
information contained in this message may be confidential and is
intended to be exclusively for the addressee. Should you receive this 
message unrightfully, please do not use the contents herein and
notify the sender immediately by return e-mail.
===============================================================


-----Original Message-----
From: idvusers-bounces@xxxxxxxxxxxxxxxx on behalf of Jeff McWhirter 
Sent: Wed 10/3/2007 23:18
To: Kevin L. Manross
Cc: IDV Users
Subject: Re: [idvusers] Maximum Heap Size


Hi Kevin,
I'm sure some folks will chime in with their experience with max
memory size.
Specifically, I'm wanting to display relatively long animations of 
data displaying isosurfaces.
We have recently added a facility to cache the data to a local disk store. If you are running a recent build - for grids if you go to the 
properties dialog of the data source there is a "Always cache to
disk" checkbox. Turning that on will result in the IDV reading in the data timestep by timestep right when each timestep is accessed, e.g., when the display is rendered. Once we read it we write it to disk and 
get rid of it from memory. Then, when the data is accessed again
(say, when the display is re-rendered or the data is probed) we read 
it back from the local disk.
The "Delay" field is how long the IDV waits until it gets rid of the data from memory. For example, if you are probing the data you might 
want to increase the delay so the IDV doesn't keep going to disk
every time the probe moves.
This is a user option because you do take a performance hit in the IO 
to local disk. But, it will dramatically reduce memory usage.
A caveat - this is fairly new the past 6 weeks or so but it seems to 
be working pretty well.

-Jeff

_______________________________________________
idvusers mailing list
idvusers@xxxxxxxxxxxxxxxx
For list information, to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
_______________________________________________
idvusers mailing list
idvusers@xxxxxxxxxxxxxxxx
For list information, to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/








--
+-----------------------------------------------------+
Kevin L. Manross           |  ** New Address **
CIMMS Research Associate   |     120 David L. Boren Bvd
NSSL : WRDD : SWAT         |     Rm 3923
<kevin.manross@xxxxxxxx>   |     405.325.6385
www.cimms.ou.edu/~kmanross |
"My opinions are my own and not representative of
CIMMS, NSSL, NOAA or any affiliates"
+-----------------------------------------------------+

_______________________________________________
idvusers mailing list
idvusers@xxxxxxxxxxxxxxxx
For list information, to unsubscribe, visit: http:// www.unidata.ucar.edu/mailing_lists/ 




--
Tom Whittaker
University of Wisconsin-Madison
Space Science & Engineering Center (SSEC)
Cooperative Institute for Meteorological Satellite Studies (CIMSS)
1225 W. Dayton Street
Madison, WI  53706  USA
ph: +1 608 262 2759
_______________________________________________
idvusers mailing list
idvusers@xxxxxxxxxxxxxxxx
For list information, to unsubscribe, visit: http:// www.unidata.ucar.edu/mailing_lists/
  • 2007 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the idvusers archives: