RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs
Volker Simonis
volker.simonis at gmail.com
Fri Jun 21 08:48:43 PDT 2013
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