On Tue, Nov 30, 2010 at 10:02 AM, Jochen Theodorou <[email protected]> wrote: > Does the JVM even has to realize an int object before something specific to > the object is done? I think not. I think that in many cases the JVM does not > have to create an actual Integer and thus does not have to pay the cost of > creating the actual object. About bad performance... > The problem is that either I handle Integer, then for a Integer+Integer I > have to unbox both and most probably also box again. Or I handle int, and > then I have to live with the problems regarding for example assigning null.
I am also confused what you're looking for. An Integer is a full-on object, with an object header and a 32-bit payload. The same logic goes for the other boxed numerics. iadd takes two 32-bit values from the stack and adds them. iadd against an object doesn't make sense, whether it's Integer or not, since it's not a 32-bit value, it's an arbitrarily-sized object behind a pointer reference into the garbage-collected heap somewhere. Where ints on the stack are likely loaded into registers, Integer objects are in memory/cache with only their pointer/reference in a register. iadd against a pointer or against a glob of bytes somewhere in memory doesn't make sense either. Perhaps what you're asking for is for the JVM to turn iadd against an Integer into the sequence of calls that would unbox the values, add them, and then produce a primitive int on the stack? Since the cost of an Integer object is that you had to create it in the first place (and to a lesser extent some level of GC pressure since it will eventually go away) would such an iadd shortcut actually improve anything? It seems like the same amount of work would be done in both cases. Perhaps it's escape analysis you want, which will in very localized cases avoid the initial allocation of the Integer object and just pass around the primitive int? Perhaps it's fixnums or value types or stack-allocated objects you want, so that the cost of the Integer object itself is either removed (treating tagged pointers as 32-bit values directly) or blunted (by allocating objects on the stack along with normal execution context). Can you clarify? - Charlie -- 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.
