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

[Lindenmaier, Goetz]

Hi,

here the table from my last mail once more, with better formatting.
It shows what relocations are used in a simple jvm98 run.

                  | x86_32  |  x86_64   | ppc_64
--------------------------------------------------
oop               | 44566   |  37129    | 24090
virtual_call      | 10422   |   9265    |  9727
opt_virtual_call  |  9083   |   8085    |  8344
static_call       |   435   |    404    |   423
static_stub       |  9518   |   8489    |  8767
runtime_call      | 61762   |  57695    | 27899
external_word     |  6919   |   9622    |     0
internal_word     |  3747   |   5898    | 40903
poll              |  2807   |   2476    |  2705
poll_return       |  2219   |   1989    |  2188
breakpoint        |     0   |      0    |     0
section_word      |     0   |      0    |     0
trampoline_stub   |     0   |      0    | 30428

current fillers   |     2   |     34    |     3
new filler needed |     9   |    144    |     0

Sum               | 140176  |  130978   | 144942


I did this with hs24, therefore metadata is missing, but
that should not affect the basic picture.

Best regards,
  Goetz.



From: ppc-aix-port-dev-bounces at openjdk.java.net<mailto:ppc-aix-port-dev-bounces at openjdk.java.net> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of John Rose
Sent: Dienstag, 18. Juni 2013 21:40
To: Bertrand Delsart
Cc: Roland Westrelin; ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-dev at openjdk.java.net>; hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>
Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs

On Jun 18, 2013, at 1:36 AM, Bertrand Delsart <bertrand.delsart at oracle.com<mailto: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/20130620/1b3e4582/attachment.html