RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs

[John Rose]

On Jun 18, 2013, at 1:36 AM, Bertrand Delsart <bertrand.delsart at oracle.com> wrote:

> This change is consuming the last unused relocType (yet_unused_type_2)
> 
> Unfortunately, that relocType is also used for other projects both within the embedded team and the compiler team (you should not which one I am speaking about Roland :-))
> 
> This means relocType will no longer fit into 4 bits. I'll let you see with the compiler team whether this can easily be solved (by increasing the size or recycling other reloc types) or whether we need to discuss more before deciding how to use the last available relocType.

The relocInfo records are stored as an array of unsigned shorts (u2).  This slightly simplifies random access compared with a CompressedStream representation, but otherwise is less dense and pits tag space directly against offset space.

At some point I would like to see them re-engineered using CompressedStream, which is built on the more robust UNSIGNED5 representation.  That would allow reloc info tokens to be built from 32-bit values, as long as most of them were small in magnitude.

For now, as an incremental change, it would be reasonable to make the tag width (type_width) be variable.  The most common tags could be encoded as 4 bits and the least common 25% in (say) 6, giving a 75% increase in coding space at small cost.  The extra tag bits would break into the value field (for the less-common tags). There is already a mechanism for dealing with value field overflow, which could be adapted to be sensitive to the tag width.

The variability could be encoded in the tag field itself (Huffman style, right-to-left):
  type_width = 4,
  type_width_2 = 6,
  type_width_2_mask = 0x0003,
  ...
  bool type_width() { (_value & type_width_2_mask) == type_width_2_mask ? type_width_2 : type_width; }
  ...

— John

P.S.  Back in the day, I wrote the flyweight object mechanism by which reloc info streams are loaded with objects that are both by-value and virtual-function-bearing.  It is somewhat fragile and (I now think) over-clever.  This is another thing I would like to change about the relocinfo mechanism, if it were rewritten.  Since then other parts of the JVM have used stream-like structs like RelocIterator, but they don't mess around with vtables in rewritable stack objects, which (IMO) are at the edge of the C++ language.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20130618/1610e4d9/attachment.html