Does garbage collector run concurrently with another threads?

I want to know if applications threads stop executing while the garbage collector is running.
Thank you in advance.

The nature of threads is that they let you have multiple processes running at once without a command in one having to wait on a command in another to finish. garbage collection runs this way as a daemon thread(as I have just learned from another post). So it will not stop other threads from processing while it is active.
[ June 07, 2002: Message edited by: Chris Shepherd ]

Well, currently the implementation of the gc on Windows and Unix do in fact pause your application threads while the gc thread runs. Recent advances in the gc make this time delay shorter and shorter.
Sun is continually working on ways to improve gc performance, and one of the things they are looking at is concurrent gc, ie, running while your program threads run. At some point, this will be implemented in the JVM.

I did not know that. This is why I try to answer questions here. So that when I'm wrong, someone will correct me and I will learn something. Thanks Ross...

[ June 10, 2002: Message edited by: Chris Shepherd ]

More generally... it depends. (Always a good general answer :-)
Most computers/OS support only a single line of execution. When the systems multi-task, they are really just jumping back and forth between applications very quicky (kind of like the illusion of "moving pictures"). Given that the chip/OS supports only a single activity at any time,t his means that at some point, while Java is running, the active theads will be swapped out, and the GC thread will run.
However, there are JVMs which are designed for multiple processor systems. There it is quite conceivable to run the GC thread concurrently to other threads.
Real time systems may also have additional constrsints.
--Mark

Yes, but the current memory model doesn't allow for heap blocks to be used by your application while the heap is being gc'd - that's why for now, the gc runs as a single thread that effectively locks the heap while it's running. It's definately a sore point for Java memory management, but again, it's something Sun is actively working on fixing.

Rob, can you point me to the source of this info?
Thanks.

--Mark

Mark, there's a ton of stuff on what sun is doing on their website here:
http://research.sun.com/jtech/pubs/
Here's a quote from "Parallel Garbage Collection for Shared Memory Multiprocessors" ( http://research.sun.com/jtech/pubs/01-pargc.pdf )

Most Java virtual machines (JVM TM 's)
employ "stop-the-world" garbage collection (GC) algorithms that first halt the running threads and then perform the GC. "

It goes on to discuss some of the alternative GC systems that are being developed.

Here's another interesting description of the gc process:
http://research.sun.com/research/techrep/1998/smli_tr-98-70.pdf

We can now describe the sequence of steps that take place when a garbage collection is per-formed.
These steps, except for the differences explained in Section 2.3 and 2.4, are the same
whether polling or code patching is used.
1. A new thread, the GC thread, is created to perform the GC (use of a separate thread ensures
that a predictable amount of stack space is available, regardless of the depth of the stack of
the mutator thread that triggers GC).
2. The GC thread suspends all the mutator threads and sets the global boolean
gc_stop_threads to true.
3. The GC thread iterates over all mutator threads. For each mutator T,ifT is consistent, it is
already able to tolerate a GC, so it is simply left suspended. If T is inconsistent, the GC
thread restarts T. There are now two possibilities: T is executing in an inconsistent region, in
which case it will suspend itself at the end of the region, or T is executing in compiled code
or in the bytecode interpreter loop, in which case T will suspend itself when it reaches the
next GC point (where it offers to become consistent).
4. The GC thread waits for all the restarted inconsistent mutators to reach GC points and sus-pend
themselves (monitoring progress with a counter that the mutators increment just before
they suspend themselves).
5. Now all mutators in the system have been stopped either in a consistent state or at a GC
point, so the garbage collection can be done.
6. Finally, the GC thread resumes all the mutators and, having completed its job, terminates.