RFR: 8326378: [PPC64] CodeEntryAlignment too large

Martin Doerr mdoerr at openjdk.org
Thu Feb 22 04:51:53 UTC 2024


On Wed, 21 Feb 2024 20:53:00 GMT, Dean Long <dlong at openjdk.org> wrote:

>> I'd like to save space in the code cache. No performance regression observed. See JBS issue for more details.
>> 
>> Old:
>> 
>> [Instructions begin]
>>  ;; N1181: #	out( B1 ) <- BLOCK HEAD IS JUNK  Freq: 1
>>   0x00007fff7cbda880:   nop                                 ;   {no_reloc}
>>   0x00007fff7cbda884:   nop
>>   0x00007fff7cbda888:   nop
>>   0x00007fff7cbda88c:   nop
>>   0x00007fff7cbda890:   nop
>>   0x00007fff7cbda894:   nop
>>   0x00007fff7cbda898:   nop
>>   0x00007fff7cbda89c:   nop
>>   0x00007fff7cbda8a0:   nop
>>   0x00007fff7cbda8a4:   nop
>>   0x00007fff7cbda8a8:   nop
>>   0x00007fff7cbda8ac:   nop
>>   0x00007fff7cbda8b0:   nop
>>   0x00007fff7cbda8b4:   nop
>>   0x00007fff7cbda8b8:   nop
>>   0x00007fff7cbda8bc:   nop
>>   0x00007fff7cbda8c0:   nop
>>   0x00007fff7cbda8c4:   nop
>>   0x00007fff7cbda8c8:   nop
>>   0x00007fff7cbda8cc:   nop
>>   0x00007fff7cbda8d0:   nop
>>   0x00007fff7cbda8d4:   nop
>>   0x00007fff7cbda8d8:   nop
>>   0x00007fff7cbda8dc:   nop
>>   0x00007fff7cbda8e0:   nop
>>   0x00007fff7cbda8e4:   nop
>>   0x00007fff7cbda8e8:   nop
>>   0x00007fff7cbda8ec:   nop
>>   0x00007fff7cbda8f0:   nop
>> [Entry Point]
>>   # {method} {0x00007fff407064e8} 'bogus_test' '()V' in 'TestAlloc'
>>   #           [sp+0x90]  (sp of caller)
>>   0x00007fff7cbda8f4:   lwz     r11,8(r3)
>>   0x00007fff7cbda8f8:   ld      r12,8(r19)
>>   0x00007fff7cbda8fc:   td      3,r11,r12               ;trap: ic miss check
>> [Verified Entry Point]
>> 
>> 
>> New:
>> 
>> [Instructions begin]
>>  ;; N1181: #	out( B1 ) <- BLOCK HEAD IS JUNK  Freq: 1
>>   0x00007fff802f8380:   nop                                 ;   {no_reloc}
>>   0x00007fff802f8384:   nop
>>   0x00007fff802f8388:   nop
>>   0x00007fff802f838c:   nop
>>   0x00007fff802f8390:   nop
>>   0x00007fff802f8394:   nop
>>   0x00007fff802f8398:   nop
>>   0x00007fff802f839c:   nop
>>   0x00007fff802f83a0:   nop
>>   0x00007fff802f83a4:   nop
>>   0x00007fff802f83a8:   nop
>>   0x00007fff802f83ac:   nop
>>   0x00007fff802f83b0:   nop
>> [Entry Point]
>>   # {method} {0x00007fff487064e8} 'bogus_test' '()V' in 'TestAlloc'
>>   #           [sp+0x90]  (sp of caller)
>>   0x00007fff802f83b4:   lwz     r11,8(r3)
>>   0x00007fff802f83b8:   ld      r12,8(r19)
>>   0x00007fff802f83bc:   td      3,r11,r12               ;trap: ic miss check
>> [Verified Entry Point]
>
> src/hotspot/cpu/ppc/globals_ppc.hpp line 62:
> 
>> 60: 
>> 61: // Use large code-entry alignment.
>> 62: define_pd_global(uintx, CodeCacheSegmentSize,  128);
> 
> Shouldn't also changing CodeCacheSegmentSize to match CodeEntryAlignment save a little more in the code cache?
> 
> If we did all alignment on the actual address rather than an offset that is relative, I think we could get rid of some of the constraints that require CodeCacheSegmentSize to be at least as large as CodeEntryAlignment and OptoLoopAlignment.

This may make sense. However, almost all platforms use a CodeCacheSegmentSize of 128 Bytes. So, I think this should better get addressed separately for all platforms.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17939#discussion_r1498633155


More information about the hotspot-compiler-dev mailing list