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

Fri Jun 21 02:40:12 PDT 2013

That's OK for me.

Thanks for identifying a reloc type that could easily be recycled.

Bertrand.

On 06/21/13 10:55 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I removed the breakpoint_Relocation, see
> http://cr.openjdk.java.net/~goetz/webrevs/remove_bp_Reloc/
> It builds and runs on sparc_64 and linuxx86_64.
>
> section_word_Relocation can not be removed simply.
> Internal_word relocations are changed to section_word
> by pack_data_to.  I counted the relocations where they
> are generated, so I did not catch this.  So I didn't remove
> them.
>
> I guess we should make an extra change for this, maybe even
> push it to the hotspot-comp repository?  It's got nothing to
> do with the port.
>
> Bertrand, can I push 8016696: PPC64 (part 4), now as the problem
> with the enum is solved?
> It will not conflict with 0003, as they touch different files.
>
> Best regards,
>    Goetz.
>
>
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Freitag, 21. Juni 2013 00:12
> To: Lindenmaier, Goetz
> Cc: 'John Rose'; 'Bertrand Delsart'; 'Albert Noll (albert.noll at oracle.com)'; '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
>
> Hmm 'breakpoint_type'? I don't remember that and I only see one use
> place in MacroAssembler::safepoint() on sparc and that method is not
> used anymore.
> I build SPARC VM without breakpoint_Relocation class (commented out).
> Looks like we can remove this type.
>
> thanks,
> Vladimir
>
> On 6/20/13 2:23 PM, Lindenmaier, Goetz wrote:
>> 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.
>>
>>

-- 
Bertrand Delsart,                     bertrand.delsart at oracle.com
Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
38334 Saint Ismier,                                        FRANCE
Phone : +33 4 76 18 81 23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact
the sender by reply email and destroy all copies of the original
message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~