The new tracking code allocates a large (several MB) array on
initialization, so this is probably what is causing problems. Hopefully
it can use something a bit less memory hungry in future.
Sun's version of java has some runtime switches which control the
maximum amount of memory that Java can allocate, so probably digital has
something similar.
For Suns JDK you say somthing like:
java -mx64m jas.swingstudio.JavaAnalysisStudio
The 64m means 64Megabytes (but the m has to be lowercase).
Tony
> -----Original Message-----
> From: David L. Wagner, University of Colorado
> [mailto:[log in to unmask]]
> Sent: Wednesday, June 16, 1999 3:39 PM
> To: [log in to unmask]
> Subject: OutOfMemoryError on OSF
>
>
> Hi,
>
> We have been trying to use TrackReco in hep.lcd 0.98, but we
> haven't got
> very far. Anytime we try to do anything with track
> reconstruction, we get
> an OutOfMemoryError. I was wondering if anyone else is able
> to reproduce
> this? It is crimping our ability to do analysis at the
> moment (we have
> gone back to 0.97 without track fitting for the moment).
>
> Here's a simple 3-line program that causes this error for us:
>
>
> public class TrackTest extends hep.lcd.util.driver.Driver {
> public TrackTest () { add (new
> hep.lcd.recon.tracking.TrackReco()); }
> }
>
>
>
> Perhaps this is a Digital Unix thing, although I don't see any obvious
> problems (the "java" process seems to be taking only about
> 40MB of memory,
> although my process limits are set to 120MB of real memory and 1GB of
> virtual memory).
>
> Has anyone seen this problem, or know how to get things working?
>
> Thanks!
>
> -David Wagner
>
|