Whatever happened to Java chips?

Ages ago, I was coming home from a vacation and bought a copy of Byte magazine... back when there was a Byte magazine... and its cover story was about Java performance. This was back in the 1.1 era, I guess, and it has a pull out diagram showing a lot of the potential approaches for getting your Java code to run faster, with estimated trade-offs of difficulty and payoff for each approach. For example, the authors placed a fair amount of hope in just-in-time compilers, which not only paid off, but were replaced by Hotspot's even better dynamic compilation approach.

There was item in the group that I distinctly remember underachieving, and that was the Java chip. Highest in difficulty for obvious reasons, it promised the highest potential payoff in terms of bytecode execution.

So whatever happened to the Java chip?

We get a reply from Terrence Barr in one of today's featured forum messages. In Re: Java execution acceleration, he writes:

Java hardware acceleration has been a long-time subject of investigations. In fact, I actually worked on Sun's picoJava hardware acceleration engine way back when. Also, phoneME has the hooks to support ARM's Jazelle technology. However, I think the general experience has been that providing hardware acceleration is a losing battle except for very specific and constrained applications. General purpose CPUs benefit from the rapid evolution of semiconductor technology and there is a lot of economy of scale for using the CPU for most, if not all, processing requirements in a system including Java execution - with the notable exception of graphics engines (this seems to be too demanding for even modern CPUs to support). We have found over the years that Java hardware acceleration provides marginal and short-lived performance benefits in most real-world applications - although there are specific application scenarios in which it does provides tangible benefits.

So, since we can't expect hardware to save us, and since Moore's Law takes so darn long, what else can we do? Wisely, the top recommendation from the old Byte article, the best tradeoff for difficulty and result, was "write better code". Seems like a "duh", but when was the last time I ran my code through a profiler? It's been a while, actually...