While the Java VM shields most developers from having to think about the memory-management aspects their Java objects, the VM does not completely manage other types of resources automatically, says Gwyn Fisher, CTO of Klockwork in this interview with Artima:

http://www.artima.com/lejava/articles/javaone_2008_gwyn_fisher.html

To what extent do you agree with Gwyn Fisher that great Java developers need to think about the interaction between the JVM and their environment, and about how the JVM interacts with Java objects?

Meh. None of it is really news to me. I may be different, though, since I came up through the ranks via C and C++, so I know all too well that memory is only one of the resources that needs to be released. Also, contrary to what is claimed in the article, most implementations will close sockets and JDBC connections during finalize() when the object is garbage collected. The problem with relying on finalize(), though, is that it is only invoked when available memory runs low, not when the number of available sockets or JDBC connections run low.

> Also, contrary to
> what is claimed in the article, most implementations will
> close sockets and JDBC connections during finalize() when
> the object is garbage collected

I disagree. Most implementations in my experience isolate the code that opens and closes a resource into a framework or a reusable class, and resources are closed in the

finally

clause of the

try { ... } finally { ... }

block.

> To what extent do you agree with Gwyn Fisher that great
> Java developers need to think about the interaction between
> the JVM and their environment, and about how the JVM
> interacts with Java objects?

I don't agree 100%. I think a great developer should focus solely on the language definition and not worry about the JVM. Sometimes there will be a situation where knowing something about the JVM will be necessary, and then and only then should the developer study such interactions.

It should be the burden of the language designers to provide VMs that behave so well that all you have to know is the language definition to use the language. You shouldn't have to know anything about the implementation.

Of course because the world is not ideal, a good developer should be prepared to sometimes do what "shouldn't be done" if the need arises. But it shouldn't be a default stance of almost any Java developer to worry about the JVM, in my opinion. The only exception I can see here are the developers who are writing new languages to run on top of the JVM.

> > Also, contrary to
> > what is claimed in the article, most implementations
> will
> > close sockets and JDBC connections during finalize()
> when
> > the object is garbage collected
>
> I disagree. Most implementations in my experience isolate
> the code that opens and closes a resource into a framework
> or a reusable class, and resources are closed in the
> finally clause of the try/finally block.

Sorry, I should have clarified. I was referring to implementations of the java.net.Socket and the java.sql.Connection classes. Usually, it's Sun's implementation in the standard runtime, but some J2EE containers have been known to provide custom versions of those classes.

yeah, well, i could have more of an opinion if they actually had a Mac OS X version. lost a sale there...

> I disagree. Most implementations in my experience isolate
> the code that opens and closes a resource into a framework
> or a reusable class, and resources are closed in the
> finally clause of the

>try { ... } finally { ... }

> block.

Resources should be closed in finally clause. You see a lot of code, even from renowned authors, that insufficiently tries to handle exceptions in the catch clause. From the Hibernate documentation e.g.:

Session sess = factory.openSession();
Transaction tx = null;
try {
    tx = sess.beginTransaction();

    // do some work
    ...

    tx.commit();
}
catch (RuntimeException e) {
    if (tx != null) tx.rollback();
    throw e; // or display error message
}
finally {
    sess.close();
}

Interesting quote...should a VM have only a memory GC or a memory GC coupled with a socket GC, handle GC etc?

This is an idea that I haven't seen anywhere, but it seems to me as critical as memory.

A run-environment should have N garbage collectors, whereas N is the number of different type of resources needing to be managed by the run-time environment.

This means the language should have pluggable GC architecture...

> Interesting quote...should a VM have only a memory GC or a
> memory GC coupled with a socket GC, handle GC etc?
>
> This is an idea that I haven't seen anywhere, but it seems
> to me as critical as memory.

It's actually quite old and known idea: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

> A run-environment should have N garbage collectors,
> whereas N is the number of different type of resources
> needing to be managed by the run-time environment.
>
> This means the language should have pluggable GC
> architecture...

RAII should be built in as it is in e.g. C++. What should be pluggable (i.e. optional) is memory garbage collection (in Java GC sense).

> Interesting quote...should a VM have only a memory GC or a
> memory GC coupled with a socket GC, handle GC etc?

You would only need one GC if it was done right. Instead of kicking off a global collection only when memory runs low, the GC could call finalize() on an object the moment it is no longer reachable. For example, when a function returns, all of the local variables would be collected right then and there (as long as they aren't contained in the return value).

The problem is that bulk-mode GC is usually more efficient than per-object GC.

> RAII should be built in as it is in e.g. C++.

In C++ RAII only works for objects on the stack. IMO, deterministic resource management is the desideratum - for stack- and heap-objects. But we will see this feature only in the successor of both, Java and C++.

> You would only need one GC if it was done right. Instead
> of kicking off a global collection only when memory runs
> low, the GC could call finalize() on an object the moment
> it is no longer reachable. For example, when a function
> returns, all of the local variables would be collected
> right then and there (as long as they aren't contained in
> the return value).
>
> The problem is that bulk-mode GC is usually more efficient
> than per-object GC.
Ja!

A while back I kept trying to explain that idea to one of the Alice ML folks who seemed to have a different take on it all, that the program author can use higher order hoodly-doodly to make their own RAII type stuff.

I appreciate all the talk of how letting things happen in libraries is great and all, but it can't be a truism for all features, otherwise there would be no core language ;-) and I sorta feel this RAII-GC thing such that should be in the language.

What I think roughly I don't really know what I'm talking about want is something like:

(a) a type to be of (multiply inherit / interface) which tells the GC that you have an RAII-finalize method.

(b) the GC keeps a stack of allocation references in parallel / inside the regular call stack (or whatever else is appropriate, e.g. if you are talking about closures on the heap). that stack is only for types from (a), not every possible type.

(c) the GC then runs the finalization, and configurably optionally the actual memory GC to boot, to close the resource when its scope exits.

?!?!?

(d) profit.

I guess, alternatively, if your language let people register plug ins for when the VM hits certain points e.g. all stack popping, it actually could be a library.

> > RAII should be built in as it is in e.g. C++.
>
> In C++ RAII only works for objects on the stack. IMO,
> deterministic resource management is the desideratum - for
> stack- and heap-objects. But we will see this feature only
> in the successor of both, Java and C++.

RAII works by creating handles to objects and placing those handles on the stack. The objects being managed are often on the heap, in shared memory (in which case the handle must use an inter-process reference counting mechanism) or may have nothing at all to do with memory (e.g., semaphores and file locks). The end result is deterministic resource management.

Now that I've worked with C# some, I think there's a lot to be said for C#'s "using" blocks. However, I think that for the most part a garbage collector that knows about more than just memory would be perfectly fine. For instance, a garbage collector that allowed the user to (1) register file descriptors, (2) state that there is a maximum of XX file descriptors available, and (3) request garbage collection whenever open file descriptors reach 80% or more of the limit. This would be the same collector that would run if available memory fell too low or if some other resource became constrained.

In the event that the garbage collector runs and is not able to free up file descriptors, then the garbage collector would essentially be saying that all open file descriptors are being used by live objects. If there are no more descriptors (or memory, or ...) available, there isn't much to do except wait for some of those objects to die or determine if you're in a deadlock. But there wouldn't be much to do in an alternate world with an alternate system.

The first thing that came to mind after reading the article was:
"All non-trivial abstractions, to some degree, are leaky." ( http://www.joelonsoftware.com/articles/LeakyAbstractions.html )

Some people think that programming with modern languages and libraries makes suddenly everything easy. Less laborious and cumbersome? Yes. Less complex overall? Not really.

By the way, the modern Python idiom for this:
http://docs.python.org/whatsnew/pep-343.html

> > > RAII should be built in as it is in e.g. C++.

> > In C++ RAII only works for objects on the stack.

> RAII works by creating handles to objects and placing
> those handles on the stack. The objects being managed are
> often on the heap, in shared memory (in which case the
> handle must use an inter-process reference counting
> mechanism) or may have nothing at all to do with memory
> (e.g., semaphores and file locks). The end result is
> deterministic resource management.

.. for any application so simple that reference counting is sufficient.

(We do use RAII with our C++ implementation. It is not sufficient.)

Peace,

Cameron Purdy | Oracle
http://www.oracle.com/technology/products/coherence/index.html