An Optimization For Garbage Collectors...

For the last few days I have been thinking a lot about GC as Terracotta moves towards our first major rewrite of that subsystem. Lots of relatively large changes have been bouncing around in my head as I read papers, blogs and talk to people. Maybe I'll blog about those later but one pretty simple one occurred to me. I have a theory that most Shared Objects are actually only directly referenced by one parent object (I haven't run stats on this yet so I might be full of it). I started from wondering whether we could take advantage of this to improve the efficiency of GC. Here is what I came up with:

• We can keep a Set of Object ID's for objects that only have one direct reference to it. We have an implementation of a compressed Set of ID's so this can be quite space efficient.

• If an Object gets a second reference to it then it is removed from that Set
• If that one reference is removed and in the Terracotta world that object is not reachable from a client or in a non-terracotta world it is not reachable from the stack then the object is garbage.
• If an Object has no references but is reachable from the stack or is still on a client then add it to the no-refs Set so that when those two things are no longer true they can be marked as garbage or if the object is re-referenced it can be accounted for properly.
  
• You can also recurse through the objects that the new garbage object referenced doing the same check.
  

One might be wondering, "Does steve think he just invented reference counting?" Nope, I don't and I haven't decided if this idea is any better than just having a first phase of garbage collection based solely on reference counting. I'm just theorizing that it might be. I don't even know that I invented this shortcut. Most real world GC's are hybrids of multiple approaches that best fit the set of restrictions and limitations faced in the environment. This one seems like it could improve things significantly in real world apps and potentially drastically reduce the required frequency of full GC's in our world without adding too much overhead.

Anyway, blast away :-)

More Advice To A Young Developer...

I read Alex Miller's blog post on "Advice To A Young Developer" and it got me thinking. What general advice would I give to young developers. I came up with a few things. Hopefully they will help somebody.

1) Become your best by NOT being the best - This may seem obvious but the best way to be your best is to put your self in positions where your surrounded by people who are better than you on at least one dimension. This leads to point number 2.

2) Listen more than you talk - Use a bit of insecurity and a bit of wanting to be the best to drive you to suck the knowledge and experience from the people around you. Even the people you may view as less than you on some dimension or another will still teach you things if you listen. While your talking you are NOT listening.

3) Be Stupid, Stupid! - Sometimes being smart is a smart person's worst enemy. Don't ever use your intelligence as a crutch. Do research, talk to people, listen to people, read code, read books. In short allow yourself to evolve or risk not knowing how bad you are at things that you could have been great at. Watch out if you find yourself doing things from first principles all the time.

4) Slow Down - Of course a developer should work ones ass off. Almost all of the good ones do. But allow yourself time to think. Step back and look at what you are doing. In software it is very easy to rat hole on the wrong thing so take brakes, think, and get back to it. No more than 50 percent of your time should be spent typing (I actually think for an experienced dev it should be more like 25 percent).

5) Be A Tester - This is really for all Software Engineers, but... Be a tester, learn to write great automated tests that exercise at the unit, component, and system level. NOTE: This doesn't mean write tons and tons of tests. It means learn to write good ones.

6) Read your code - Software is complicated. Go back and read your code. You'll find all kinds of interesting things

7) Refactor - Refactor your code for readability, testability and maintainability. A myth exists that doing something in a messy poorly organized way is somehow quicker than doing it in a clean way. This is flat out untrue. I've actually timed myself. It takes longer to do things poorly. You are not saving any time by leaving bad code around. If it's a state machine write it as a clean well factored state machine. If you see a ton of nested if's extract methods, use null objects, what ever is needed.

8) Don't Guess - I first started with don't pre-optimize but I figured I would go one step further. Don't Guess! Write tests to show a perf problem before fixing them, don't guess about what features will be needed in the future, don't guess about whether your change fixes a bug. PROVE IT!

9) Trust Me - If you find yourself trying to win an argument by saying "trust me, I've done this or that before", or "I just know" then STOP. If you can't explain your point then you probably don't really have one so either figure out what the point really is or just admit your wrong.

10) Wishful thinking - Any decent list always has 10 items in it right? Anyway program by wishful thinking. Keeps you focused.

Reading back on this list it is completely all over the place. I have like 50 more ideas but this blog is already kind of preachy and pedantic so I'll stop :-). Hope someone can find some benefit from it.

Anyone else have ideas?

The New "My Yahoo" Homepage

I have used my.yahoo.com as my home page for a long time. Here are my comments on the new version they are pushing lately.

- I'm not thrilled with the giant square advertisement in the upper left and most important space on the page. You can move it to the right side with the layout control but it still isn't my favorite. It's giant, square and flashy and for me a bit annoying as compared to the old layout.

- The left side blocks are too wide. I like to glance at that stuff but it doesn't have a lot of text and tends to not need the extra width. It is about 50 percent wider than it was in the old version.

- I like the idea of the personal assistant thing. It has mail, stocks and some less useful stuff in a very useful spot. My problem with it is that it grows on hover. Things that take major actions on hover kind of bug me. Mostly they just make me do the action by accident and add no real value.

- I'm not sure if it's a bigger font or more white space but it feels like I have to do a lot more scrolling to see my rss feeds.

Fear not, it's not all bad, the personalization stuff while lacking enough control is visually pleasing and trivial to use.

DZone Suggestion, More Comments

I like DZone a lot. I read it regularly and post to it when practical. I like the rising links, I like the popular links, I even like the voting system. However, one thing that would make DZone just a touch better is to encourage people to comment on blogs when they vote. I personally learn from both the positive and negative feedback and anything that can be done to encourage that feedback is welcome. So, my suggestion is to pop up an optional "Add comment" field with proceed and cancel options after any vote on DZone. Anyone is free to not comment at that point but if someone has something on the tip of their tongue they might be more likely to say it. Our experience at Terracotta in building our .org website tells us that even subtle changes can have a broad impact on what people do. I would be interested to see this A/B tested and see if it increases comment volume.

Why I love and hate statics in Java

I was chatting with some fellow geeks earlier this evening and it occurred to me that I've said to people that they should almost ALWAYS use static and also told people they should almost NEVER use static. Am I schizophrenic, a hypocrite, or just dumb. Maybe all three but it has nothing to do with this blog. I'm talking about two different language usages of the static reserved word.

USAGE 1, where the love is:
Inner classes. I hate non-static inner classes. IMHO non-static inner-class is unnecessary syntactic sugar that leads to hard to read code and subtle bugs. For those who don't know, non-static inner classes maintain a hidden instance variable holding a parent instance. It then uses specially generated methods to give access to the parent's private fields and auto-magically calls methods on the parent if no local method of the used name exists. I've seen this lead to memory leaks (people passing around instances of inner classes and not realizing that they are keeping around parents), all kinds of confusing issues with methods of the same name in inner and outer classes and variable problems of the like. On the occasions I use inner classes I almost always go with the static kind.

USAGE 2, no love here:
Static variables. With the exception of constants I have a strong dislike of static variables. Why you ask? When used to create various versions of singletons it leads to messy hidden code dependencies . It also makes it hard to do mock object stuff for testing, creates hidden initialization stuff and makes it difficult to create multiple environments in a single JVM. Just darn inflexible for no gain. I would go into details but this has been covered quite nicely here

Anyway, in summary, STATIC inner classes good, STATIC variables bad.
Goodnight ...

Saved by a Time Machine...

In the last 4 months I have had the good fortune of twice having my hard drive crash on me on my Macbook Pro. The first time I lost of bunch of stuff but was lucky to be able to recover some data off of various other machines. This last time I was saved by Time Machine. I'll be taking my computer to the apple store tonight for another hard drive replacement but I already have access to all my files. I just connected my backup drive to my wife's mac and clicked the time machine button. Selected use previous configuration, and I was able to recover some of the directories and files I needed to her machine. It was very simple and effective. So for those of you who have had lousy backup experiences and have given up. I recommend giving it another try with time machine. It bailed me out this time.

First experiment with JDK 1.6 on OS X

Ran into this article on JDK 1.6 on OS X from slashdot. I figured I would give it a whirl with Terracotta as an experiment. Turns out I just needed to hack the Terracotta OS version check in the ./common/src/com/tc/util/VendorVmSignature.java class because this jvm calls the OS Darwin instead of osx and then things just worked. Was kind of odd to see the JTable demo come up as an X window but things worked like a charm.