[#RVM-371] 13956 broke PPC64 development build

RVM

13956 broke PPC64 development build

Created: 08/Feb/08 10:10 PM Updated: 06/Mar/08 08:39 AM

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Time Tracking:

Not Specified

Issue Links:

Related

This issue relates to:

~~RVM-368~~ Compiler confusion over equal but non-identical objects

This issue is related to:

RVM-324 Implement class unloading

Supercedes

This issue is superceded by:

~~RVM-374~~ Static field allocation is non-deterministic

~~RVM-390~~ VM_Statics/JTOC space saving has cost us single iteration fop performance

Description

« Hide

See: http://jikesrvm.anu.edu.au/cattrack/results/excalibur.watson.ibm.com/core-ppc64/2695/development/Output.txt

Bootimage got too big.

All

Comments

Work Log

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Ian Rogers - 09/Feb/08 04:16 AM

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)

[ Permlink | « Hide ]

Ian Rogers - 09/Feb/08 04:18 AM

This problem relates to solving ~~RVM-368~~.

[ Permlink | « Hide ]

David Grove - 09/Feb/08 05:33 AM

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).

[ Permlink | « Hide ]

Ian Rogers - 10/Feb/08 02:08 AM

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.

[ Permlink | « Hide ]

Ian Rogers - 13/Feb/08 10:46 AM

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.