I told you finalizers are bad for you!
Hi all,
Read this interesting thread on forums.sun.com. The quick description is the following. The poster's application kept hitting an OutOfMemory situtation after a few hours of running. A little investigation showed that most of the memory in the heap (850+MB out of a 1.2GB heap) was being held by, you guessed it!, the finalization queue. The reason? A finalizer was getting stuck on I/O (while closing a DB connection) and preventing the rest from running, while more and more objects were added to the queue. Ouch.
The poster advises: Never do I/O in a finalizer! I actually advise: Never use finalizers in the first place!
But, if you really really have to, you should be really really really careful.
Posted at 10:25AM Aug 12, 2008 by tony in Personal | Comments[1]
The Saddest News (cont'd)
Just a quick follow-up on Steve Goldman's passing. His obituary was published here, if you're interested in reading it.
BTW, I just realized: I've been using Xinha to write my blog entries... and guess who had introduced me to it? Yep, Steve.
Posted at 05:01PM Jul 08, 2008 by tony in Sun | Comments[0]
Sun Rays
I've always been mystified why Sun Rays (Sun's thin clients) have not been more popular. They might not be a generic desktop replacement, but they are definitely the right solution in many situations, e.g., call centers. Nice to see that someone else thinks so too.
Posted at 12:35PM Jul 07, 2008 by tony in Sun | Comments[4]
The Saddest News
Not all blogs entries are pleasant or easy to write.
Today we got the saddest news. One of our own, Steve Goldman, passed away while on vacation. He was 56. He is survived by his wife, Gretchen Niver, and their two nieces.
Steve has been working on Java and HotSpot since 1999. He was initially part of the runtime team and then moved to the compiler team. His contributions to HotSpot are too many to enumerate. HotSpot would just not be what it is if Steve had not worked on it. You can read his blog here.
Steve and I shared a hobby: aviation. He was an avid pilot and for the past two years he has been building his own Velocity. Here he is, in his partially-constructed Velocity, after he installed the control stick.
As another colleague today said, Steve's passing is a huge loss to Sun and the world. I could not agree more.
Steve, we will miss you. In fact, we miss you already. Wherever you are, may the winds be calm and the skies clear.
Godspeed.
Posted at 01:01PM Jun 30, 2008 by tony in Sun | Comments[3]
Join the OpenJDK HotSpot GC lists!
Hi all,
(alright, yes, I really needed to get back to blogging!)
We recently wanted to get feedback on a couple of changes that we are planning to the GC-related command line parameters of HotSpot. And we opened the discussion on the OpenJDK HotSpot GC mailing lists. So, I'd like to take this opportunity to encourage you to join those lists, if you're interested in participating in such discussions. We maintain two lists:
hotspot-gc-use (for discussion on the use of our GCs):
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
hotspot-gc-dev (for discussions on the code of our GCs):
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-dev
(Note that the latter is a member of the former. So, you don't have to become a member of both.)
And, for what it is worth, the questions we have been asking are the following:
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2008-April/000237.html
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2008-May/000309.html
Posted at 11:53AM May 30, 2008 by tony in Sun | Comments[2]
"Did I mention it was free?"
Very interesting article on Scott McNealy's presentation at the NICSA Technology Summit 2007 in Las Vegas on the advantages of open source software. Worth a read if you're not yet convinced.
Posted at 01:05PM Oct 29, 2007 by tony in Sun | Comments[1]
The T2 is finally out!
The first systems, the Sun SPARC Enterprise T5120 and T5220 servers and the Sun Blade T6320, which are based on our new UltraSPARC T2 (aka Niagara 2) chip have finally been announced. Congratulations to all the teams involved!
Compared to the T1, T2 has several nice improvements. I'll only concentrate on two: 8, instead of 4, hardware threads per core (for an incredible total of 64 hardware threads per chip) and 1 FPU per core, instead of 1 FPU per chip (for a total of 8 FPUs per chip). This will give you even more parallelism, as well as much better FPU performance, compared to the T1.
Please check this blog entry for an overview of all the benefits of the UltraSPARC T2.
We, the HotSpot JVM development team, have been doing a lot of work to make sure that HotSpot runs as well as possible on the T2. And it shows. Check out the SPECjbb2005 results that we have published on Dave Dagastine's blog. We were particularly happy with the single JVM result that we got on T2, which is just over 10% worse than our best multiple JVM result.
Posted at 05:02PM Oct 09, 2007 by tony in Sun | Comments[0]
Solaris: "Signs of Life"
Check out this article on Solaris getting traction. Pretty cool.
Posted at 11:55AM Oct 08, 2007 by tony in Sun | Comments[0]
Finalization article, version 2.0
The finalization article that I had written sometime ago, has been revamped and republished on java.sun.com:
http://java.sun.com/developer/technicalArticles/javase/finalization/
Posted at 06:30AM Sep 17, 2007 by tony in Sun | Comments[0]
Write Dumb Code
"Often, the way to write fast code in Java applications is to write dumb code --- code that is straightforward, clean, and follows the most obvious object-oriented principles."
Who said it? Well, you need to go here to find out.
Posted at 09:44AM Mar 05, 2007 by tony in Sun | Comments[1]
Nice article on the Java Real-Time System
First, Happy New Year! I hope you all had a great and relaxing break!
For the past several months I've actually been doing some work on Java RTS (Java Real-Time System). Eric Bruno just published a nice introductory article on it. So, if you want to know more about Java RTS, I'd encourage you to go and have a look. Can you find the article here here.
Posted at 08:54AM Jan 08, 2007 by tony in Sun | Comments[1]
Nice performance improvement with Java SE 6!
Hey, check out this post:
http://forum.java.sun.com/thread.jspa?forumID=37&threadID=5114368
30% performance improvement by just switching from 5.0 to 6.0. Pretty Cool! As I said in my previous post: What are you waiting for? Go and get it. Now!
Posted at 09:43PM Dec 11, 2006 by tony in Sun | Comments[0]
Java SE 6 is out!
After an enormous amount of work from the entire Java SE team, Java SE 6 is out. What are you waiting for? Go and get it. Now!
Posted at 11:35AM Dec 11, 2006 by tony in Sun | Comments[0]
The Garbage Collector is too aggressive!!!
(back to blogging after a short hiatus...)
A customer recently complained to me that the GC is too aggressive, it can reclaim objects too early (Wow!), and the JIT compiler is broken for allowing the GC to do so (double Wow!)!
Here's the (simplified) example that the customer gave me:
class Foo {
// cPtr is really a pointer to a C object in the C heap
long cPtr;
long getCPtr() { return cPtr; }
void finalize() {
freeCObject(cPtr);
}
native void freeCObject(long cPtr);
}
class Bar {
native void processCObject(long cPtr);
void doSomething() {
Foo foo;
...
// foo now points to object F
...
long cPtr = foo.getCPtr();
processCObject(cPtr);
}
}
(If you're really into bug hunting please refrain from reading further
and try to find the race in the code...)
OK, here's what happens: the JIT can prove that variable foo is not accessed after the assignment to variable cPtr and, therefore, the GC will not consider foo as part of the stack frame's live root set for safepoints that take place after the assignment (basically, foo is considered "dead" after the assignment). Imagine now that a GC happens while the native method processCObject() is running (note: JNI will do a safepoint check upon entering a method and will suspend the thread if a safepoint has been requested). Also imagine that foo is the last reference to object F. Given that foo will not be considered as part of the stack frame's live root set (remember, it is considered "dead"), the GC can decide that F is actually unreachable and queue it up for finalization. At the end of the GC, the application threads, as well as the finalization thread, will be restarted and will race for accessing the C object; the application thread will try to process it, while the finalization thread will try to free it.
Ouch.
First, how can this happen? Well, as far as the JIT is concerned, cPtr is just another long and is treated as such. So, the JIT has no way of knowing that cPtr is actually a C pointer and the object it points to is associated with foo. Hence, it will not consider foo to be live as long as cPtr is live (the JIT just does not do that for longs!).
So, what can we do to fix this bug? Well, we just have to ensure that the GC considers foo live during the duration of the processCObject() method. There are a couple of ways of doing this:
- passing foo as an additional parameter to processCObject(), or
- making processCObject() a non-static method on the Foo class
Another recommendation that makes it easier to avoid such problems, courtesy of Ross Knippel from our compiler group, is to avoid manipulating C-pointer-containing long fields from Java, but only manipulate them from within native methods. This way, there will always be a JNI handle pointing to the Java object that contains the C pointer which will ensure that the object will not be collected while the corresponding C object is accessed. In the above example, you will only pass foo to the processCObject() native method, which will first retrieve cPtr and then go ahead and process the corresponding C object.
This was a fun little problem (maybe, not this much fun for the customer who hit it!). What I'd like you to at least get out of this is that using native methods in Java is really not very straightforward and little problems like this one can cause major headaches. So, please, be careful!
Posted at 01:04PM Nov 28, 2006 by tony in Sun | Comments[1]
Predictable GC does not mean Fast GC
I recently heard some claims from one of our competitors that drove me nuts! Said competitor claimed that they have a very fast VM, which is now even faster given that they have a predictable GC!
Exqueeze me? Baking powder?*
Whoever made these claims clearly has no understanding of how garbage collection works and what the trade-offs involved are.
To achieve predictability, you have to make sacrifices. Even by going from a fully stop-the-world to a more incremental collector, you usually double your garbage collection overhead (that's my rule of thumb at least) and increase your memory footprint.
Going from a simple incremental to a really predictable collector will cost you even more. I have read papers in which a 30%-35% garbage collection overhead is considered a good result in the context of a predictable garbage collector.
In a lot of applications that our customers care about, the garbage collection overhead is maybe 10%, even as low as 5%. Predictability will not decrease that.
Incidentally, I had seen some SPECjbb (2000 I think) results from said competitor and, by looking at the configuration they ran with, I highly doubt that they had any garbage collection activity during the timing window. So, how are they going to improve that with a predictable collector? Eh?
Let me put it another way: they will not be publishing SPECjbb2005 numbers with their predictable collector any time soon...
*If you didn't get the joke, I invite you to watch Wayne's World. Even if you got the joke, watch it anyway!
Posted at 11:01AM Feb 06, 2006 by tony in Sun | Comments[1]