JADE: Another HashMap and more

Performance Tuning
#21

[quote]Which one is it? I had assumed the first, but its taken so long to appear that that points to an actual addition to the bytecode language.
[/quote]
Autoboxing is purely a compile-time trick. The only new thing that it uses is some valueOf() methods which were added to Integer and the like.

One kind of “optimization” that could be done with autoboxing is removing it entirely. This could be done if primitives were handled in a manner similar to the way Smalltalk handles numbers.

God bless,
-Toby Reyelts

#22

[quote]What you want is the generics stuff, and a JRE/VM that will optimise for this. Ie you use a HashMap that is compile time constrained to only use int’s for the keys and/or values. At runtime the JRE or VM can then substitute in an int optimised HashMap instead of the default one.
[/quote]
Yes, we need type-specific instantiations of parameterized classes - just like you’d get in C++ or PolyJ. No, we don’t need to be delaying the generation of those classes until runtime. That’s just a pure waste of compute power.

[quote]However, I don’t think primatives can be specified for generics - ie would have to be Integer object not int.
[/quote]
No, in the current implementation of JSR14 we can’t use primitives for type parameters. Yes, in a good implementation of parametric genericity we can. Look at PolyJ. http://pmg.lcs.mit.edu/polyj/

Sun’s complaint with Poly was that it wasn’t as backwards compatible as GJ was. My suggestion to Sun is that they use a mixed-style strategy then. Continue to use type-erasure for instantiations with reference type parameters, where compatibility is actually an issue. Use heterogeneous or PolyJ-style translation for instantiations with primitive type parameters, where compatibility isn’t an issue.

Then, everybody would get what they need.

God bless,
-Toby Reyelts

#23

If you wanna squeeze some extra performance from your collections without reinventing the wheel you may want to check out primitive collections for java http://pcj.sourceforge.net/ and the jakarta commons package http://jakarta.apache.org/commons/collections.html

Tom

#24

[quote]If you wanna squeeze some extra performance from your collections without reinventing the wheel
[/quote]
There’s also another one, which I haven’t seen mentioned in this thread yet, though it has been talked about on JavaLobby and on this board many moons ago.

fastutil - http://fastutil.dsi.unimi.it/

The laughable part is that they used the brain-dead C preprocessor to generate the library for them. The proliferation of these kinds of libraries is a strong reflection of the gaping hole in Java generics.

God bless,
-Toby Reyelts

#25

[quote]Which one is it? I had assumed the first, but its taken so long to appear that that points to an actual addition to the bytecode language.
[/quote]
AIUI autoboxing in 1.5 will just be a compiler trick so its just syntax.

As you and others have pointed out, there really is no way for the VM to recognize it since theres no “box” opcode.

A VM COULD theoretically be designed to treat int AS an object. (Some smalltalk VMs do this) but it would take some pretty deep-in-the-design things in the VM, and the repercussions of that on the existing syntax are inbovious and would have to be carefully considered.

On the bright side, I don’t think this feature in CLR is anything other then syntactic sugar, also :slight_smile:

#26

Jeff, I am well aware that Java’s heap allocation is faster than that of C/C++, I was only asking about optimizations that could make per-object heap allocated collections perform as well as collections that allocate several objects at a time (ArrayList) or avoid doing much allocation at all (by using object pools or by implementing ListEntry in the storage object).

I know the GC is the main issue and that this is both application and VM specific, that’s why I was asking for research on optimizations to the current VMs that could make the general collections as efficient as specific ones (like how escape analysis can eliminate some heap allocations and their need for garbage collection, or how generational GC helped speed up allocation).

For instance, couldn’t the compiler perhaps use the new metadata facility to hint to the VM that a collection is being used as a primitive container with boxing, allowing the VM to eliminate the boxing and its associated garbage collection?

#27

well I am NOT a VM or compiler expert… but I don’t follow what this code would look like,

How would you write a collection so that it could use unboxed primatives without completely different code from Object collections?? Remember, general pointers don’t exist in the VM, only object pointers (“references”).

#28

I guess you’re right, the gains of replacing or re-generating a collection to natively support primitives wouldn’t be very big, except for perhaps for ArrayList, since you’d still need to have the List/Map-entry object.

I can understand now why they didn’t add primitive versions of the collections to the package. They would only be able to get rid of per-object allocations/GC for ArrayList, which is the easiest of the collections to implement yourself, and if you can accept one allocation per object to store you can probably also accept the allocation that the auto-boxing brings.

I used to think that they didn’t provide primitive collections because they had some smart optimization up their sleeves that would make auto-boxed primitive use of the Object collections real efficient.