pushkarajthorat

Hi All,

Many of my friends are saying about slowness of java. Reasons of this is as follows:

1. Java Virtual Machine.
2. Garbage Collection Mechanism.
3. Runtime type checking of Code.
etc.

I was thinking about how if we could solve the first problem of Virtual Machine..

If we create a Hardware or a Processor which executes the Java byte code Instructions. I know it sounds harder but still I am hopeful in this.

I want your views about this idea.

[Pushkaraj]

Infinite Recursion

I think it is overkill. I rather wait a few additional seconds as opposed to putting new hardware in my box. I would also use a program written in a different language if this became a requirement for Java based apps.

__________________
http://jasonpowers.net

"There are a thousand hacking at the branches of evil to one who is striking at the root."

DaWei

It destroys the very reason for having a VM in the first place, which is (theoretically) hardware independence. Put the hardware dependence back and you just have a language that compiles to machine code.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

ReggaetonKing

What's wrong with the Java VM? Isn't the fastest VM out here?

__________________
I would love to change the world, but they won't give me the source code!

pushkarajthorat

Work as hard as possible but a Interpreter will always be slow..than a compiled raw code.

I hope you will not oppose this.

[Pushkaraj]

pushkarajthorat

"It destroys the very reason for having a VM in the first place, which is (theoretically) hardware independence"

Hey cool down, just look the concept form different point-of-view

Look a machine which executes byte-code which is implemented in Hardware itself. I think it would be possible in near future. At least not for our desktop pc but for the busy servers.

Only one java <Mainclass> will be running nothing else on the system.

DaWei

Read the sentence, sonny boy. It's a straightforward sentence carrying information, but no heat. The information is still there for you to read, since you obviously didn't get it in the first place.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

ReggaetonKing

DaWei is correct. Why don't you just use C++ or something similar to Java than that making Java's code compile to machine code. It makes no sense to do that!

Have you seen that lastest Java VM benchmark? How much faster do you want a interpreted language?? It is not even that much slower than native apps.

__________________
I would love to change the world, but they won't give me the source code!

lectricpharaoh

I heard somewhere that there are, or were soon going to be, processors whose machine code was identical to Java bytecode. In other words, they would be a 'real machine' instead of a 'virtual machine'.

That said, I don't think it's necessary. DaWei is correct- such an approach negates the hardware independence that Java touts as its main strength. Such a beast would have somewhat limited appeal, and thus, would not sell as many units as a mainstream CPU. Factor in economies of scale, and it would also be expensive (and would require a new motherboard capable of supporting it); many people would prefer to upgrade their CPUs and/or improve their hardware with less expensive approaches that would also yield better performance, and have across the board improvements.

Another issue would be device contention. If the Java processor operated in parallel (and realistically, it would have to), then you'd have busy cycles while one CPU accessed hardware (memory, for example) and the other had to wait. This is an issue in pretty much any parallel multiprocessor setup, and is a key reason why performance does not scale linearly with the number of processors (ie, going from one processor to two does not mean doubling the performance). In some cases, you can get close to linear improvement, but that happens when the software is specifically written to take advantage of the parallel nature of the hardware.

Lastly, there are many techniques for improving real-world performance. One common approach is just-in-time compilation, used by many Java VMs and the .NET runtime (among others). This converts the bytecode (or sections of it) into native code the first time it is executed, and then when it is subsequently executed, it is much faster. Since many functions are called multiple times, this can yield significant performance increases. True, the JIT compiler can't optimize as well as a real compiler (if it did, the conversion would take too long, and negate the increases), but it's still a big help.

None of this is to say that there is no value to your idea. It might work well in specific circumstances, like a low-power embedded system (where the hardware was designed around the Java 'real machine'), but as a solution for slow Java code on modern PCs, there are more practical solutions.

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

DaWei

Further, it is unlikely that an embedded system, low-power or otherwise, is going to take on the huge development expense for a system that would range from (at best) a marginal improvement to (at worst) a substantial penalty.

The reason that the idea sounds beneficial is that the proponent apparently doesn't realize that he is re-inventing the microprocessor, and that high-level languages were invented to divorce one from the raw micropressor, at a penaly in performance and a benefit in programming costs.

The result would be a hardware device with byte-code as it's 'machine language', but underlying that would be a hardware megalith adapting to that with tons of microcode (read hardware logic).

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers