Quote:
Originally Posted by ghd
So is the GC running on daemon or non-daemon threads?
There is a large amount of slack given to the behaviour of garbage collection. You can see various algorithms and their tunings being used, for example. I don't think garbage collection is discussed in detail in the Java Language Specification:
JLS pdf
These are the general references I found in the text:
The Java programming language is a relatively high-level language, in that details of the machine representation are not available through the language. It includes automatic storage management, typically using a garbage collector, to avoid the safety problems of explicit deallocation (as in C’s free or C++’s delete). High-performance garbage-collected implementations can have bounded pauses to support systems programming and real-time applications. The language does not include any unsafe constructs, such as array accesses without index checking, since such unsafe constructs would cause a program to behave in an unspecified way.
Classes support concurrent programming with synchronized methods.Methods declare the checked exceptions that can arise from their execution, which allows compile-time checking to ensure that exceptional conditions are handled. Objects can declare a finalize method that will be invoked before the objects are discarded by the garbage collector, allowing the objects to clean up their state.
When an object is no longer referenced, it may be reclaimed by the garbage collector. If an object declares a finalizer, the finalizer is executed before the object is reclaimed to give the object a last chance to clean up resources that would not otherwise be released. When a class is no longer needed, it may be
unloaded.
The class Object has a protected method called finalize; this method can be overridden by other classes. The particular definition of finalize that can be invoked for an object is called the finalizer of that object. Before the storage for an object is reclaimed by the garbage collector, the Java virtual machine will invoke the finalizer of that object.
The package java.lang.ref describes weak references, which interact with garbage collection and finalization. As with any API that has special interactions with the language, implementors must be cognizant of any requirements imposed by the java.lang.ref API. This specification does not discuss weak references in any way. Readers are referred to the API documentation for details.
An implementation of the Java programming language may unload classes. A class or interface may be unloaded if and only if its defining class loader may be reclaimed by the garbage collector as discussed in §12.6. Classes and interfaces loaded by the bootstrap loader may not be unloaded.
Quote:
Originally Posted by ghd
So is the GC running on daemon or non-daemon threads? If the GC is doing the garbage reclaiming work on daemon threads then the JVM will kill it and then who will reclaim remaining garbage memory?
Now that I think about it more, I'm going to decline to comment on where the GC is even running on a separate thread and whether or not such a thread is a daemon thread. That is an implementation detail of a specific implementation of a garbage collector, and not a general part of the JVM or language specification.
As I mentioned before, your concern about "who will reclaim remaining garbage memory" is misplaced. This is not a garbage collection issue, or a JVM issue or a Java issue. It's built into the way operating systems manage processes.
Is there a reason for this line of inquiry? I let the GC do it work and 99% of the time I know I can safely pretend that memory is inexhaustible..