RFR: 8263718: unused-result warning happens at os_linux.cpp
Thomas Stüfe
thomas.stuefe at gmail.com
Fri Mar 19 06:52:32 UTC 2021
It seems reasonable, since counter and alloca have no visible effect apart
from affecting each other.
- just assign the return value to a volatile pointer?
- and/or just write something into the alloca'd memory? (see
also _expand_stack_to)
..Thomas
On Fri, Mar 19, 2021 at 7:47 AM David Holmes <david.holmes at oracle.com>
wrote:
> On 19/03/2021 4:08 pm, David Holmes wrote:
> > On 19/03/2021 3:56 pm, Thomas Stüfe wrote:
> >> > It has also been raised (as it was here) whether the alloca is
> >> even left
> >> > in place by the compiler. Something I have yet to check.
> >>
> >> call _ZN6Thread26record_stack_base_and_sizeEv at PLT
> >> .LVL2492:
> >> .loc 3 666 3 is_stmt 1 view .LVU7882
> >> .loc 3 667 3 view .LVU7883
> >> .LBB6399:
> >> .LBI6399:
> >> .loc 3 1359 5 view .LVU7884
> >> .LBB6400:
> >> .loc 3 1360 3 view .LVU7885
> >> .loc 3 1360 18 is_stmt 0 view .LVU7886
> >> call getpid at PLT
> >> .LVL2493:
> >> .LBE6400:
> >> .LBE6399:
> >> .loc 3 668 3 is_stmt 1 view .LVU7887
> >> .loc 3 670 36 is_stmt 0 view .LVU7888
> >> movq %r13, %rdi
> >> .loc 3 668 3 view .LVU7889
> >> addl $1,
> _ZZL19thread_native_entryP6ThreadE7counter(%rip)
> >> .loc 3 670 3 is_stmt 1 view .LVU7890
> >> .loc 3 670 36 is_stmt 0 view .LVU7891
> >> call _ZN6Thread25initialize_thread_currentEv at PLT
> >>
> >> Appears the alloca has been elided, along with the arithmetic.
> >>
> >> Don't know if that is true for other platforms.
> >>
> >> David
> >> -----
> >>
> >>
> >> Which would explain why we don't see effects in benchmarks. Question
> >> is, do we repair this or remove it.
> >
> > I'm trying a repair and re-running the benchmarks.
> >
> > The repair is simply:
> >
> > static void* _stack_pad = alloca(...);
>
> That doesn't seem to work either:
>
> call getpid at PLT
> .LVL2493:
> .LBE6400:
> .LBE6399:
> .loc 3 668 3 is_stmt 1 view .LVU7887
> .loc 3 668 29 is_stmt 0 view .LVU7888
> movzbl _ZGVZL19thread_native_entryP6ThreadE10_stack_pad(%rip),
> %eax
> testb %al, %al
> je .L2250
> .L2214:
> .loc 3 670 3 is_stmt 1 view .LVU7889
> .loc 3 670 36 is_stmt 0 view .LVU7890
> movq %r13, %rdi
> call _ZN6Thread25initialize_thread_currentEv at PLT
>
> and:
>
> .L2250:
> .cfi_restore_state
> .loc 3 668 29 discriminator 1 view .LVU8015
> leaq _ZGVZL19thread_native_entryP6ThreadE10_stack_pad(%rip),
> %rdi
> call __cxa_guard_acquire at PLT
> .LVL2520:
> testl %eax, %eax
> je .L2214
> .loc 3 668 29 discriminator 2 view .LVU8016
> leaq _ZGVZL19thread_native_entryP6ThreadE10_stack_pad(%rip),
> %rdi
> addl $1, _ZZL19thread_native_entryP6ThreadE7counter(%rip)
> call __cxa_guard_release at PLT
> .LVL2521:
> jmp .L2214
>
> I'm not really sure what that is doing but now even the counter++ has
> been elided, along with the calculation and the alloca. ??
>
> Then I tried:
>
> void* _stack_pad = alloca(((pid ^ counter++) & 7) * 128);
> if (_stack_pad == 0) counter--;
>
> and still no alloca:
>
> call _ZN6Thread26record_stack_base_and_sizeEv at PLT
> .LVL2492:
> .loc 3 666 3 is_stmt 1 view .LVU7882
> .loc 3 667 3 view .LVU7883
> .LBB6399:
> .LBI6399:
> .loc 3 1360 5 view .LVU7884
> .LBB6400:
> .loc 3 1361 3 view .LVU7885
> .loc 3 1361 18 is_stmt 0 view .LVU7886
> call getpid at PLT
> .LVL2493:
> .LBE6400:
> .LBE6399:
> .loc 3 668 3 is_stmt 1 view .LVU7887
> .loc 3 671 36 is_stmt 0 view .LVU7888
> movq %r13, %rdi
> .loc 3 668 22 view .LVU7889
> addl $1, _ZZL19thread_native_entryP6ThreadE7counter(%rip)
> .loc 3 669 3 is_stmt 1 view .LVU7890
> .loc 3 671 3 view .LVU7891
> .loc 3 671 36 is_stmt 0 view .LVU7892
> call _ZN6Thread25initialize_thread_currentEv at PLT
>
> Have I missed something obvious here? (This is g++ -S output).
>
> David
> -----
>
> >> >> PR: https://git.openjdk.java.net/jdk/pull/3042
> >> <https://git.openjdk.java.net/jdk/pull/3042>
> >> >>
> >>
>
More information about the hotspot-dev
mailing list