dcsimg
Garbage Collection
3 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   yaniv_ba
Posted On:   Tuesday, June 5, 2001 07:12 AM

I am writing a realTime application. I am trying not to create new objects while runnint (only on startup), but I sometimes need to create object dynamicly. Due to this creation the garbage collector is running once an hour and stop my application from running for one or two seconds. I have tried to use HotSpot and incremental garbage collection, but it does not help is there any way to avoid this garbage collection or doing it more soft (I tried to tune the -mx and -ms flags)?

Re: Garbage Collection

Posted By:   Finlay_McWalter  
Posted On:   Friday, June 15, 2001 05:43 PM

As others have pointed out, there is no way to disable garbage collection. As Mike said, the only way to avoid the GC fully is to use a RT-java JVM, which has memory that isn't from the GC heap and threads that aren't stopped by the GC cycle. There is no substitute.


You can, however, minimise the duration of GC cycles. It's not enough to support hard realtime, but maybe it'll help. Some strategies include:


  • Avoid hotspot. Hotspot is a busy beaver, allocating and freeing stuff as it goes. Disable it. A JIT will do less, but still does something. If you can afford to run interpreted, do so.

  • Keep the heapsize (and the number of allocated objects) as small as possible. The GC algorithm varies between platforms and JVMs, but (in general) there is a positive correlation between heapsize and GC time.

  • Use object pools instead of Java's new keyword. You say "I sometimes need to create object dynamicly" - if you have full control over the APIs you're calling (which pretty much means you aren't calling any of the standard java.* APIs) then you can preallocate pools (generally arrays) of any of the objects that your realtime code will need, and then (during the "realtime" phase of execution) your code calls your own pseudo-alloc and pseudo-free calls to claim and release these.



Fundamentally, however, in the absence of a realtime JVM (running on a realtime OS), Java is not a realtime program, and any realtime activity you try to do with it will, in all likelihood, fail.

Re: Garbage Collection

Posted By:   Arun_Bharathan  
Posted On:   Tuesday, June 5, 2001 07:57 AM

You should look into setting the memory heap stacks sizes. The -mx sets up the maximum size of heap stack and the -ms sets the initial or startup heap stack size. When the available memory for a JVM reaches specific ratios, the heap stack size is incremented. (If it has already reached the maximum, you get a out of memory error.)



I suggest that you monitor the GC process by using the command java -verbose:gc (Which would provide the timings, sizes etc) before starting the tuning process. To avoid the GC thread from running, set the -MX and -MS the same. (But then you should know how much memory you need and how much leak takes place over a long period?!)

There are some JVMs (Like IBM's JVM) which allows you to control the GC process using external parameters.

Re: Garbage Collection

Posted By:   Luigi_Viggiano  
Posted On:   Tuesday, June 5, 2001 07:43 AM

But if you successfully disable garbage collector and you dynamically create objects... what will happen when you fill up all the memory?

Personally I don't know any way to disable gc (and I don't think it's possible to disable it, sorry).
About | Sitemap | Contact