RVM

IdentityHashMaps in the bootimage

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 3.0
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

It's very likely that IdentityHashMaps can't be safely carried over from bootimage writing time to run time because our default hash code won't be the same as the host JVM. Verify this, and if it is the case, we need to rework code to avoid use of any such hash maps in the bootimage.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
David Grove added a comment -

If there are a small number, of "well-known' identity hash maps in the bootimage, then we could make them work by having the bootimage writer traverse their keys and build up a sidetable of objects in identity hash maps right before it starts writing objects to the bootimage. We would then write these objects in "HASHED_AND_MOVED" form with the hashcode being the system hashcode given them by the host JVM.

It's fragile and restricts the object model options for Jikes RVM to those that can represent the 32 bit hash from the host JVM, but if we must have identity hash maps in the bootimage it's probably the only way to make that actually work.

Show
David Grove added a comment - If there are a small number, of "well-known' identity hash maps in the bootimage, then we could make them work by having the bootimage writer traverse their keys and build up a sidetable of objects in identity hash maps right before it starts writing objects to the bootimage. We would then write these objects in "HASHED_AND_MOVED" form with the hashcode being the system hashcode given them by the host JVM. It's fragile and restricts the object model options for Jikes RVM to those that can represent the 32 bit hash from the host JVM, but if we must have identity hash maps in the bootimage it's probably the only way to make that actually work.
Hide
Permalink
Ian Rogers added a comment -

I think the right way to tackle this is to add a boot image interface that computes the identity hash code. In the boot image writer and object model we can then either throw errors, use the HASHED_AND_MOVED trick or possibly pre-allocate the object. The result of the boot image writer identity hash code method would be the identity hash code. We can call the interface in the RVM identity hash maps, and its also extensible if we need the identity hash code in other places in the future.

Show
Ian Rogers added a comment - I think the right way to tackle this is to add a boot image interface that computes the identity hash code. In the boot image writer and object model we can then either throw errors, use the HASHED_AND_MOVED trick or possibly pre-allocate the object. The result of the boot image writer identity hash code method would be the identity hash code. We can call the interface in the RVM identity hash maps, and its also extensible if we need the identity hash code in other places in the future.
Hide
Permalink
Ian Rogers added a comment -

Patch committed in r14714, extra support will be necessary for non address based hash codes as used in GC spy's object model.

Show
Ian Rogers added a comment - Patch committed in r14714, extra support will be necessary for non address based hash codes as used in GC spy's object model.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.