Articles Forum - Sources of Java Errors

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Articles Forum
Sources of Java Errors

29 replies on 2 pages. Most recent reply: Jun 1, 2008 7:47 AM by dark mx

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 29 replies on 2 pages [ 1 2 | » ]

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Sources of Java Errors

Posted: May 16, 2008 9:00 AM

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?

Michael Hobbs

Posts: 51
Nickname: hobb0001
Registered: Dec, 2004

Re: Sources of Java Errors

Posted: May 16, 2008 11:23 AM

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.

Leo Lipelis

Posts: 111
Nickname: aeoo
Registered: Apr, 2006

Re: Sources of Java Errors

Posted: May 16, 2008 12:04 PM

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

Leo Lipelis

Posts: 111
Nickname: aeoo
Registered: Apr, 2006

Re: Sources of Java Errors

Posted: May 16, 2008 12:10 PM

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

Michael Hobbs

Posts: 51
Nickname: hobb0001
Registered: Dec, 2004

Re: Sources of Java Errors

Posted: May 16, 2008 1:01 PM

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

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: Sources of Java Errors

Posted: May 16, 2008 1:04 PM

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

Roland Pibinger

Posts: 93
Nickname: rp123
Registered: Jan, 2006

Re: Sources of Java Errors

Posted: May 17, 2008 2:24 AM

> 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();
}

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Sources of Java Errors

Posted: May 19, 2008 2:04 AM

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

Alex Fabijanic

Posts: 71
Nickname: aleksf
Registered: Aug, 2006

Re: Sources of Java Errors

Posted: May 19, 2008 3:48 AM

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

Michael Hobbs

Posts: 51
Nickname: hobb0001
Registered: Dec, 2004

Re: Sources of Java Errors

Posted: May 19, 2008 8:45 AM

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

Roland Pibinger

Posts: 93
Nickname: rp123
Registered: Jan, 2006

Re: Sources of Java Errors

Posted: May 19, 2008 10:05 AM

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

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: Sources of Java Errors

Posted: May 19, 2008 2:07 PM

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

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Sources of Java Errors

Posted: May 19, 2008 3:56 PM

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

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Sources of Java Errors

Posted: May 20, 2008 11:35 AM

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

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Sources of Java Errors

Posted: May 22, 2008 12:27 PM

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

Flat View: This topic has 29 replies on 2 pages [ 1 2 | » ]

Previous Topic

Next Topic