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.

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.

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).