RVM

Apologies, we needed 2 hash maps, one for object -> literal location and one String -> literal location to fix the problem that the former map is an identity map and the latter not. I think there are 2 fixes:

1) bump the size up of the boot image
2) switch from using maps to find literals to a search of the JTOC. We've talked about doing this in the past. Searching the JTOC is rare so hopefully the speed difference between a map and a search is small. We'd need to order items in the JTOC into references that are literals and ones that are static fields.

(a guess as to why this didn't effect PPC32 is that the reference sizes are smaller, maybe compressed references would save the day)

This problem relates to solving RVM-368.

I believe all the bootimages bloated up, but we're closer to the edge with 64 bit references so we didn't notice on the 32 bit platofrms.

A possible alternative is to abandon the strategy of putting literals directly in the jtoc and put them in segregated structures that are 1 load further away. That at least bounds the search time to be O(# of literals of the relevant type).

For the idea of having different arrays we'd need 3. One for classes, one for strings and another for all other object literals. In the case of a class or string the search time would be bounded by the type, but for objects we'd still need to search all 3. I don't think there are any problems encoding the literal offset in the constant pool, we'd need to take care that we referenced the correct array when we had a particular type.

This isn't a huge worry to me, what I'm more concerned about is adding an indirection to get literals. I think searches occur much less frequently than a literal access, and the cost of a more expensive literal access may not be recouped by a faster search.

Patch committed in r13964:

"RVM-371: fixes to reduce the size of VM_Statics following RVM-368 that bloated the boot image size and regressed PPC64. This patch removes all but one hash map from VM_Statics. Bit vectors are used to record whether a value is a field or literal value. Support is added to state that final fields that are in initialized classes are literals (once the class is >= initialized). The string literals map is maintained but it is keyed now by either an atom or a String. Atom and String searches are approximately the same speed as before. Searching for int/long sized literals now involves searching the bottom half of the JTOC. Searching for class/object literals involves searching the top half of the JTOC. The output to RVM.map is reformatted to account for these changes. Additionally support is added to attempt to intern (make canonical) all String and Integer objects. The object address remapper is moved out of the BootImageWriter as its functionality grew. This patch reduces the size of the data image by ~1MB/3% and the root image map by ~32kb/4.4%."

I will keep an eye on the performance reports to see the impact this change has had. I will also watch PPC64 to see if it has resolved the issue.