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

Vladimir Kozlov vladimir.kozlov at oracle.com
Fri Jun 21 09:38:56 PDT 2013 

It should be in jdk8/hotspot in 2 weeks. We will push in comp repo today 
or on Monday. It would be best if you can wait. I will file next bugs 
for part 6 and part 7 so we can start working on them.

About my push for 'part 3'. I used it for an experiment :) which was not 
successful :( . We have several JPRT connected systems and I tried to 
keep files on one system with bigger disk space but to run on an other 
JPRT with much less jobs in queue. And it was disaster - job did not 
complete after 14 hours (NFS access was terrible). So I am rerunning it 
again in local JPRT. That was the reason why it was not pushed yet.

I also want to do sync from main forest after that, we pushed big 
changes there this week.

Thanks,
Vladimir

On 6/21/13 8:48 AM, Volker Simonis wrote:
> What do you think how much time it will take to push this change to
> hsx/ and jdk8/hotspot (as far as I see it is already reviewed -
> right?). If you could do it fast, perhaps we can wait until it arrives
> in the staging repository from up-stream (anyway we wanted to sync
> regularly with upstream).
>
> I think omitting this patch will not block the next few changes we
> have and if it will arrive in jdk8/hotspot within 2 or 3 weeks it may
> save us the pain of the merging.
>
> What do you think?
> Volker
>
>
> On Fri, Jun 21, 2013 at 5:35 PM, Vladimir Kozlov
> <vladimir.kozlov at oracle.com> wrote:
>> Goetz,
>>
>> Thank you for preparing patch. Yes, we better do it separate in our repo
>> because we may need to change closed sources also. The marge with your (part
>> 4) changes later will be pain but we will manage.
>>
>> Thanks,
>> Vladimir
>>
>>
>> On 6/21/13 1: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.
>>>>
>>>>
>>

More information about the ppc-aix-port-dev mailing list