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

[Lindenmaier, Goetz]

Hi,

I checked what relocations are used, see below.
I also evaluated whether an additional filler is needed if
we reduce the offset size by one bit.
The number of extra fillers is very small, 0,1%, so that I would
propose to add an extra bit to the type information.

Besides breakpoint, section_word and static call
the distribution is fairly even.

Alternatively we remove some relocations:
Which platform uses section_word?  Is breakpoint
necessary on sparc?

Best regards,
  Goetz.



  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


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



From: 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; 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/9b8f61cf/attachment-0001.html