RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs
Vladimir Kozlov
vladimir.kozlov at oracle.com
Fri Jun 21 15:41:29 PDT 2013
Hi,
On 6/21/13 3:30 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> that all sounds fine to me. I will wait pushing 4 until the
> bp_reloc removal change shows up in the staging repo.
> But we could go without that change, anyways.
> We need a bugid for the bp_reloc removal, please.
> I can make a webrev against the current hotspot-comp.
I already prepared patch with you as author (now we can do that ;) ) so
you don't need to do anything additional. Note that I swapped unused types:
yet_unused_type_1 = 13, // Still unused
yet_unused_type_2 = 14, // Still unused
I sent request for corresponding closed source changes. When it is
reviewed I will push these changes into hotspot-comp. We have few days
before regular sync from comp to main (and I am gatekeeper this month :) ).
Bug is: 8017308: Remove unused breakpoint relocation type
>
> It's good if you update the repository, because I have to
> do some changes to the patches queue, e.g., do the
> SuspendResume changes as they come with JEP 167 on aix.
> And I assume 8016157 will help the port, at least we had similar
> problems with rematerialization in our VM and the port.
Good.
Thanks,
Vladimir
>
> Best regards,
> Goetz.
>
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Friday, June 21, 2013 6:39 PM
> To: Volker Simonis
> Cc: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Bertrand Delsart; John Rose
> Subject: Re: RFR(S): 8016696: PPC64 (part 4): add relocation for trampoline stubs
>
> 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