4 ms·

Like what? I'm honestly curious, the only docs i see say the opposite: "To implement the Java Virtual Machine correctly, you need only be able to read the cla

Like what? I'm honestly curious, the only docs i see say the opposite: "To implement the Java Virtual Machine correctly, you need only be able to read the class file format and correctly perform the operations specified therein. Implementation details that are not part of the Java Virtual Machine's specification would unnecessarily constrain the creativity of implementors. For example, the memory layout of run-time data areas, the garbage-collection algorithm used, and any internal optimization of the Java Virtual Machine instructions (for example, translating them into machine code) are left to the discretion of the implementor." From the JVM spec: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.htm... I also know of static java compilers that do mess around with this.

robryk 12y ago
More importantly, even if a compiler does optimize that, you can't rely on that: next version of the compiler could have slightly different conditions that trigger the optimization and your code could run 5x slower for no obvious reason.
- DannyBee 12y ago
  Compiler bugs and regressions are a fact of life, it's why we have regression tests :)
epistasis 12y ago
>correctly perform the operations specified therein Not sure how you're reading the JVM docs to the contrary, as the actual JVM instruction set differs quite a bit from a normal CPU. The JVM has limited operations for calculating memory addresses for arrays. Typically, this is a great thing, as it means that all memory accesses are bounds checked and an entire class of memory errors are eliminated. However, if you're trying to do what geophile is trying do with memory layout, you want a calculation like i * (sizeof(struct) + base_pointer But with Java the sizeof(struct) can only be one of the base types. And then you have to pop memory addresses and treat them as different things, etc. And even if you store things as byte arrays and perform an extra multiplication and add on your own, you then have to collate bytes and cast, which involves lots and lots of jvm operations. With special JVM support, it may be possible, but it's not something that is the least bit natural. And you'd want some sort of standardized support so that you could ensure that your JVM would support the special translation of 10 instructions into a single machine instruction every time, basically the Value Types proposal, I guess.
- DannyBee 12y ago
  I think you may be confused. At the point at which you compile this, you are no longer dealing with JVM bytecode, but your own IR (translated from JVM bytecode), and can do whatever you want. Thus, you are not limited by what the JVM has in terms of instructions. (and in general, you never are. You are only limited by correctness of program execution) If you want to support it at the bytecode level, yes, what you are suggesting is correct, but it doesn't have to be done this way at all, and rarely is in any language. In general, having to muck up source-code to get optimal data-layouts is a non-starter. Second, the actual optimal data layouts are rarely what programmers think they are due to cache/other complications (it's usually some very complicated nested struct layout with explicit packing and unions in various places) In any case, i believe my base point stands: There is nothing that stops java from being fast in these cases, because you don't need any support from bytecode to do it.

robryk 12y ago

More importantly, even if a compiler does optimize that, you can't rely on that: next version of the compiler could have slightly different conditions that trigger the optimization and your code could run 5x slower for no obvious reason.

DannyBee 12y ago
Compiler bugs and regressions are a fact of life, it's why we have regression tests :)

epistasis 12y ago

>correctly perform the operations specified therein Not sure how you're reading the JVM docs to the contrary, as the actual JVM instruction set differs quite a bit from a normal CPU. The JVM has limited operations for calculating memory addresses for arrays. Typically, this is a great thing, as it means that all memory accesses are bounds checked and an entire class of memory errors are eliminated. However, if you're trying to do what geophile is trying do with memory layout, you want a calculation like i * (sizeof(struct) + base_pointer But with Java the sizeof(struct) can only be one of the base types. And then you have to pop memory addresses and treat them as different things, etc. And even if you store things as byte arrays and perform an extra multiplication and add on your own, you then have to collate bytes and cast, which involves lots and lots of jvm operations. With special JVM support, it may be possible, but it's not something that is the least bit natural. And you'd want some sort of standardized support so that you could ensure that your JVM would support the special translation of 10 instructions into a single machine instruction every time, basically the Value Types proposal, I guess.

DannyBee 12y ago
I think you may be confused. At the point at which you compile this, you are no longer dealing with JVM bytecode, but your own IR (translated from JVM bytecode), and can do whatever you want. Thus, you are not limited by what the JVM has in terms of instructions. (and in general, you never are. You are only limited by correctness of program execution) If you want to support it at the bytecode level, yes, what you are suggesting is correct, but it doesn't have to be done this way at all, and rarely is in any language. In general, having to muck up source-code to get optimal data-layouts is a non-starter. Second, the actual optimal data layouts are rarely what programmers think they are due to cache/other complications (it's usually some very complicated nested struct layout with explicit packing and unions in various places) In any case, i believe my base point stands: There is nothing that stops java from being fast in these cases, because you don't need any support from bytecode to do it.