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