When does JVM Finalize

[ghd]

In Windows XP when does the JVM start (JRE version 1.4 and higher)?
And when does it halt?
Does the JVM start when we launch a java application (or by executing java classfile)?
And does the JVM halt when the all the java applications on the system end? According to the documentation, the JVM halts in two situations: 1. when you terminate the java application by Ctrl+C and 2. when the 'exit' method of the System class is called. But one of my friends is arguing that the JVM starts when the system is booted and doesn't halt till the system is shut down

Does the halting of JVM imply the stopping of GC also?

The reason that the answer to my above questions is intriguing me is to answer a serious question on when does the JVM finalize all the unreachable objects? As everyone knows the GC may or may not finalize all the unreachable objects. This depends on the particular algorithm that the GC is using for recycling garbage. So if the JVM halts then the GC will also not be present to collect all the garbage memory. I got this question because there is a deprecated method runFinalizersOn Exit in the 'System' class. So the presence of this method indicates that the 'finalize' methods may not run even after the JVM exits (halts).

[BigDaddyLH]

In Windows XP when does the JVM start (JRE version 1.4 and higher)?
And when does it halt?
Does the JVM start when we launch a java application (or by executing java classfile)?
And does the JVM halt when the all the java applications on the system end?

Yes.

But one of my friends is arguing that the JVM starts when the system is booted and doesn't halt till the system is shut down

Incorrect. Although you could code a service, and like all services it could have that behavior, but that would follow from it being registered as a service, and nothing intrinsic with the JVM.

Does the halting of JVM imply the stopping of GC also?

Or course.

The reason that the answer to my above questions is intriguing me is to answer a serious question on when does the JVM finalize all the unreachable objects? As everyone knows the GC may or may not finalize all the unreachable objects. This depends on the particular algorithm that the GC is using for recycling garbage. So if the JVM halts then the GC will also not be present to collect all the garbage memory. I got this question because there is a deprecated method runFinalizersOn Exit in the 'System' class. So the presence of this method indicates that the 'finalize' methods may not run even after the JVM exits (halts).

Read about finalization in the JLS:

JLS: finalization

[ghd]

I'm sorry BigDaddyLH, but this thread got posted prematurely. I still wanted to edit it. My actual question was on when does the GC finish recycling all the garbage memory. I did read the sections you suggested in JLS and the JVMS but I didn't get complete answer for my question there.

The JLS states the following regarding the halt of JVM:
12.8 Program Exit
A program terminates all its activity and exits when one of two things happens:
• All the threads that are not daemon threads terminate.
• Some thread invokes the exit method of class Runtime or class System and
the exit operation is not forbidden by the security manager.

Now my question is the GC is still recycling the garbage memory on low priority threads. These threads cannot be daemon threads. Hence for the JVM to exit, the GC must finish its work first. Is my inference right?

The next question is who decides how much (heap) memory must be allocated to each java application running in the system? Is this the responsibility of the JVM in conjunction with the OS (which is Windows XP in this case)? Does the JVM also take the responsibility of returning back all the memory given to an application when the application exits?

[BigDaddyLH]

Now my question is the GC is still recycling the garbage memory on low priority threads. These threads cannot be daemon threads.

Why do you say they cannot be daemon threads?

The next question is who decides how much (heap) memory must be allocated to each java application running in the system? Is this the responsibility of the JVM in conjunction with the OS (which is Windows XP in this case)?

There are command line options you can provide to java.exe. See -Xms and -Xmx in this note:

http://java.sun.com/javase/6/docs/technotes/tools/windows/java.html

Does the JVM also take the responsibility of returning back all the memory given to an application when the application exits?

That's true for any process. It has nothing to do with the JVM or Java.

[ghd]

Why do you say they cannot be daemon threads?

Of course any thread can be made a daemon thread. But daemon threads usually execute a tight loop. This is what i read from 'The Java Tutorial' by Mary Campione et al. http://tns-www.lcs.mit.edu/manuals/java-tutorial/:

Daemon Threads
Any Java thread can be a daemon thread. Daemon threads are service providers for other threads running in the same process as the daemon thread. For example, the HotJava browser uses up to four daemon threads named "Image Fetcher" to fetch images from the file system or network for any thread that needs one. The run() method for a daemon thread is typically an infinite loop that waits for a service request

Some more information on the daemon threads is available in 'Exploring Java'
By Patrick Niemeyer, Josh Peck http://www.oreilly.com/catalog/expjava/excerpt/:

In many cases, what we really want is to create background threads that do simple, periodic tasks in an application. The setDaemon() method can be used to mark a Thread as a daemon thread that should be killed and discarded when no other application threads remain. Normally, the Java interpreter continues to run until all threads have completed. But when daemon threads are the only threads still alive, the interpreter will exit.

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?

[BigDaddyLH]

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.

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

[ghd]

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

True, BigDaddyLH these are the issues specific to the operating system and the JVM implementation. I was just concerned about huge chunks of unclaimed memory being left around by applications which finish their show. Then new applications wouldn't be able to get their quota of memory allocated for their use, not until the system would be reset. But I don't think any operating system or an implementation would be that dumb to allow chunks of memory lying around by applications that complete and exit from the scene.

Maybe the JVM gives back all the memory to the operating system that a particular java application had been using (not caring whether the piece of memory is used, in-use or unused) once the latter terminates. I have to still look up an authentic source of information to corroborate this idea.

But even if we come to know how this happens (that could be implementation specific), it is still outside our (developer's) control because the GC will do it's job in it's own way.

Wish you a happy new year (2008).

Thank you,
Hare Krishna.

[BigDaddyLH]

Try reading more about Operations Systems, for example Tanenbaum's textbook:

http://www.amazon.com/Structured-Computer-Organization-Andrew-Tanenbaum/dp/0130959901