Java With Jiva

How not to fix a bug several times
I've always tried to fix bugs in such a way that I don't have to revisit that particular bug ever again. Instead of just fixing what's wrong, I try to look at what else can go wrong and make sure that those issues are also covered as well. Well sometimes I screw up, and badly at that. Last couple of weeks I've been working on several bug fixes that just had to make it for Java5 update 6, and there wasn't alot of time left. So rather than being thorough I was going for speed and attempting to fix my back log of bugs as rapidly as possible. Well I made a few mistakes which caused other issues. Now this is all factored into the release schedule, and I still have time to make changes into a respin of update 6, but it just doesn't look all the good in front of my peers and manager. Let that be a warning to all you developers, speed is not enough, you have to be thorough as well.

Free Java Developer tools!
How would you like to get world class developer tools for FREE! And not just any old tools, but tools direct from Sun Microsystems! Well you can now get Java Studio Creator and Java Studio Enterprise for free with SDN membership! Check it out

Flickr FS
I usually don't use Flickr to store my images, instead I prefer to use my CalPoly alumni shell account to store any files that I want people to see. But I found this really cool virtual filesystem that allows you to access your Flickr files as a directory on a Linux machine. Its called Flickr FS and it acts like a normal filesystem. The nicest thing is that to search for a file, you create a directory with the tags you want to search for. Example:

# pwd /tmp/flickrfs/tags/public
# mkdir linux:ubuntu

Now FlickFS will search in the background (multi-threaded W00T!), and you can access the directory as the search results are updated. Way neat, and if you are a heavy Flickr user, check it out.

SubSpace Continuum
Back in College (around 1997) I use to play this game by Virgin Interactive called Subspace. It's an overhead multiplayer space game the allows you to run around shooting up other people around the world. The point of the game is to pick up powerups that give you better guns, bombs, faster energy recharge, etc and use your ship to take down others that are trying to do the same. It was dropped by Virgin probably because they didn't see anyone willing to pay for such a simple game. The game while simple to learn, is quite challenging to play against other people. So surprisingly the source was acquired by someone and the servers and a new client are available to play again! The game is now called Subspace Continuum and let me tell you, its a blast! The system requirements are inline for a computer from 1996, so its not hard to find a computer that can play it. While its not the latest in graphics, and sound it is one of the few free multiplayer games that you can play for a few minutes and not worry about missing out on quests or events.

Eid Mubarak
Today is Eid ul-Fitr which marks the end of the holy month of Ramadan. Ramadan is the month where Muslims fast from dawn to dusk, and refrain from other worldly pleasures. Today Muslims traditionally put on their best clothes and head to Eid Prayers. After which families get together for big meals and celebrations. So Eid Mubarak everyone!

SGI Delisted :(
SGI has been delisted from the NYSE and is now a penny stock! Very unfortunte since I use to work at SGI back in 1996 as a system builder. My dad worked there for nearly 12 years, so SGI has a very dear place in our hearts.

Fix for the Eclipse bug

The Eclipse bug mentioned on October 24th has been fixed and should make its way into Sun's Java SQA group (excellent people btw). Right now for those of you with this issue, should grab B59 of Mustang which will be available later this week. The fix will also be putback to Java5 update 6, which will be available sometime this year.

What was this bug that caused me nearly six months of debugging pain? Well first off all I would not have been able to find this issue if it hadn't been for Steve G, but the issue was actually quite simple. AMD64 has REX bits that optionally precede an instructions first opcode. These REX bits specify the following:

• New General Purpose Registers, and XMM Registers
• 64bit operand size
• Additional control registers
• And potentially additional debug registers (none are defined currently)

The problem was that an encoding for an instruction (NEGL) was setting the REX bits incorrectly. This was a subtle bug, that was causing problems with instructions further down the stream than the NEGL. But its fixed now

Advertising Digest
When did Reader's Digest have more advertising then content? It seems every month the amount of advertising, especially medicine increases while the content gets sparse and quite boring actually.

.hotspotrc and .hotspot_compiler
There are two configuration files that let you control how the Hotspot VM behaves. Both .hotspotrc and .hotspot_compiler are optional and not supported and can go away at any time. The easiest place to put these files is the application directory that you want controlled, that limits the scope of these files and prevents unusual things happening to other Java applications. Both files have very simple syntax, in the case of .hotspotrc which lets you set VM settings without having to specify them on the command-line. The syntax is the same as on the commandline, minus the class name and Java launcher

-Xms512m
-Xmx1024m

That would let your heap grow from a minimum of 512mb to a maximum of 1024mb inclusively. You can set any standard VM option in the .hotspotrc file and it'll be as if the option was specified on the command line. The .hotspot_compiler file lets you exclude methods from being compiled. If you want to exclude A.B.C.D::methodName(), the syntax is:

exclude A/B/C/D methodName

Now when you run your application the Compiler will realize that A.B.C.D::methodName() should not be compiled, and will print out on the console :

### Excluding compile: A.B.C.D::methodName

Eclipse crashing
There seems to be a very hot bug that is affecting many people running Eclipse on Linux/AMD64 machines. While I'm working on this bug, there is a better workaround then just reverting to the interpreter. Create the following file in your Eclipse directory:

.hotspot_compiler

With the contents of:

exclude org/eclipse/jdt/internal/compiler/parser/Scanner optimizedCurrentTokenSource3
exclude org/eclipse/jdt/internal/core/util/CommentRecorderScanner recordComment

Since its a dot file, it'll be hidden from ls, etc so remember to remove it when I do get this fixed Performance should be much better than the interpreter.

I'm back!

I'm back! After being away for nearly six months, I've decided to get back into the blogging world! You may have known my previous blog as C2VMGuy, but I like my new JavaWithJiva much better! This time I've decided that I will start off slow and do at least one new blog posting every week and go from there.

Some good news, first off I'm going to be working extensively with the java.sun.com people on getting some VM content on there. Things will be very busy, but in a good way. Secondly I'm going to be posting regular info on Compiler optimizations, stuff going on in the Java organization and much more. Stay tuned for lots more!