On 12/01/2010 12:18 AM, Charles Oliver Nutter wrote:
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
I hope that Hotspot will never implement stack allocation.
Hotspot currently use TLAB (thread local allocation buffer) which is almost
as fast as stack allocation but without blowing the stack.
Rémi
--
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.
