Category: Work

When DNS Fails

Tonight I needed to do a bit of work as we’re coming up to a deadline and as usual things are running a bit behind. Normally I just VPN into work and use remote desktop to drive my desktop. Unfortunately when I went to do this tonight I wasn’t able to connect to my workstation via remote desktop.

A quick NSLookup query turned up the problem – it seems the DNS server at work had been reset and the DHCP lease for my workstation had not expired yet.  This means that the DNS server had no idea what IP my machine is using, but my workstation is under the assumption it has the rights to that IP address still.

Jim happened to be one of the few online, so I chatted with him a bit to see if he had any ideas how to resolve the problem.  He mentioned that this had happened to him a couple of times and his solution ended up being to drive back into work, I figured that would be my backup plan.

Jim then suggested using arp on a machine I had recently ssh‘d into from my workstation.  While I hadn’t actually used ssh to connect to any of our lab machines, it  got me thinking about our CVS server – as I was running Eclipse on my workstation and did have in theory an active connection.  From my laptop I was able to ssh into the CVS server, then using netstat I got a full list of the active connections.  Looking through the list turned up a few which were numeric (clearly where DNS had failed to provide a reverse name mapping).  From there it was a simple matter to remote desktop to the “right” numeric address to reach my workstation – I got lucky on my 1st try.

Future of Java Embedded VMs

I’m writing about this topic based on a request made by Artur Lojewski back in November last year, it has taken me a while to collect my thoughts on this topic as well as find time to sit down and write a posting.  Artur attended Eclipse Summit Europe where Dave Thomas (Big Dave) gave a talk entitled “Next Generation Embedded Software – The Imperative is Agility!” and asked what my opinion was.

Unfortunately I didn’t attend that Eclipse Summit Europe, so I didn’t hear what Dave had to say.  Talking to some folk that I do know who went – their impression was “Vintage Dave“.  I have made reference to this in the past – but I did work for Object Technology International and my university education was heavily influenced by Dave Thomas – myself and my classmates were some of the first to work our way through learning datastructures etc., in Smalltalk.  So a lot of my opinions of what Dave says are going to be coloured by my past experience (and his influence on the start of my career).

Almost any talk given by Dave will get people to sit back and think – he’s also not afraid to stand in front of an audience full of Java programmers and tell them that they’ve picked the wrong language.  In my experience he always has some good points and is worth listening to, but to interpret his talks as a set of black and white statements (or out of context) is dangerous.  There were two other bloggers that gave some in person accounts of his talk – I’d encourage you to read those.  Another reasonable reference is to read about Dave’s thoughts on JavaScript – and if you go back to what got Java started (the browser plug-in) and where Java is today, it is clear that the language didn’t fulfill the original promise.

There are others who are predicting that embedded java is dead, even James Gosling has suggested that J2ME is done.  However, if we take a look at embedded Java today – you’ll see that the Blu-ray format is a new niche for this technology.  As well, even low cost phones such as the Nokia 2760 support the J2ME profile.  This means that as a platform, there are actually billions of devices out there – how is this not success?

I think it depends on what the original goals were, and the future of the platform.  Among the various J2ME enabled devices, there are differences.  This isn’t really a lot better in the browser / javascript space, but Web2.0 holds the spotlight at the moment.  Probably the biggest threat to the J2ME space is the new generation of smart phones:  iPhone, G1 and Palm Pre – none of these have embraced Java as the path forward.

Looking at embedded hardware, we’re starting to see more and more capable hardware in the palm of your hand.  For example – iPhone is a 400MHz ARM cpu compare this to a hot desktop circa 1998 (PentiumII 400MHz), the very definition of what embedded means is changing.  In the near term J2ME will continue to be an expected feature in cell phones, so there is still a market which will continue for several (5?) years.  As the smart phone market sorts itself out we’ll see which new (or old) technology rises to the top.  It is probably safe to say that J2ME will have an impact on the outcome,  but to bet on it as the winner is probably long odds.

Disclaimer: The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.

64bit Follow-up

The decision to start including work related items in my blog certainly had a dramatic impact.

Hopefully I’m not a one hit wonder and will never say anthing relevant (or at least link worthy) again.  I remain open to suggestions for content, so if you have questions you think I might be able to answer contact information is available on my About page.

The spike was generated by my posting about 64bit java performance, and this post is a follow up to provide a bit more data on some areas I touched on.

There is some more data on the Sun JDK implementation on the HotSpot wiki.  Based on the recent publish of some SpecJBB2005 results, it seems there is (or will be) a supported version of compressed pointers from Sun.

Of course, the careful observer may noticed that the results are from an x86 based platform.  Does compressed pointer technology only matter on x86 based platforms?  In my original posting I focused on the x86-64 architecture and the benefits (and pitfalls) it brought to applications.  In brief, by moving to 64bits the gain was both bigger and more registers.  If we look at Sparc or POWER CPUs – these were both created with an eye on 64bit implementations, and thus the move to 64bits had less of an impact on the instruction set or register width.  This means that for these systems, 64bit support results in more data (due to pointer size doubling) to move without any real benefit in terms of instruction set (read: code optimization).

Currently I believe Sun has only implemented their compressed pointer solution on x86-64 systems.  There is no strong technical reason preventing it from being done on a Sparc system, but as I pointed out above the benefit may be harder to realize.  The IBM Java6 JDK supports compressed pointers on POWER (AIX/Linux) and there is a measurable improvement on memory intensive benchmarks.  IBM also supports this feature on zSeries (yup, the mainframe) and the following graph shows how the 64bit environment nearly matches the performance of the 31bit environment under Linux.

The -Xlp option is used to configure the IBM JDK to use ‘large pages’ to allocate the heap.  The details about large page support I’ll save for a future posting.   

So while most of the excitement around Java performance on 64bit systems is focused on x86-64, it is worth considering on other architectures.   I believe this will become more important as java applications continue to grow and start hitting the limits of the 32bit address space, forcing a move to 64bit.