System.gc() is just a polite request to the JVM it's not going to perform
the function until it is good and ready.
> -----Original Message-----
> From: Tim Bray [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, September 24, 1999 7:24 AM
> To: [EMAIL PROTECTED]
> Subject: [JAVA3D] Yow... this sucker burns memory
>
> I'm modeling an (effectively) infinitely large surface by cleverly
> stitching things into the scene graph ahead of them and whipping them
> out behind as the user moves around. Works OK, except the memory
> usage seems to grow monotonically until after a couple minutes java
> barfs on out-of-memory. OK, I'm testing on an NT box with a (pathetically
> wimpy these days, I guess) 96M, but *this sucks*. In particular since
> I'm careful to handbuild my shapes for low polygon count and keep the
> number of textures way down and so on. Put simply, it means
> that the application cannot be used in the real world.
>
> OK... I take subgraphs out with removeChild. I do have a lot of shared
> Materials and suchlike nodeComponents, are the internal structures such
> that the removed subgraphs might not get GC'ed if these are still in
> play? Is there any body of experience on memory conservation in J3D?
> Is it ever a good idea to call System.gc()?
>
> Hmm... I do tend to place things by stacking up several transforms
> rather than combining them, are transforms brutally expensive in memory?
>
> -Tim
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff JAVA3D-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
