On Nov 30, 11:35 am, Jochen Theodorou <[email protected]> wrote: > I was wondering... is there still really a good reason as of why we have > for example no iadd that can take Integer objects? Wouldn't it be > possible to implement all the primitive operations on the JVM so that > they work with boxed numbers without loosing performance?
I think the design decision for this (and erasure as well) is the decision of not having runtime types at the bytecode level. So, a value of the primitive types of the JVM, int, float, double, long, reference and return-address are just 32bit values (or a pair of 32bit values) without a runtime tag to distinguish them. The verifier statically checks that only correct operations are run on the right types but after it is finished all this type information can be (and probably is) thrown away safely. Is it, what you propose that the JVM replaces iadd instructions (et al) with the resp. bytecodes to extract the primitive integer value and apply the operation on that value? How would that improve performance? I can think of two possible explanations for bad performance with boxed primitives: 1. added redirection. 2. allocation costs. How would you make that go away? I see the way out of there only through something along the lines of John Rose's proposals of introducing tagged values like tuples and fixnums as outlined here: http://blogs.sun.com/jrose/entry/tuples_in_the_vm http://blogs.sun.com/jrose/entry/fixnums_in_the_vm Johannes -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
