RFR: 8263718: unused-result warning happens at os_linux.cpp
David Holmes
david.holmes at oracle.com
Fri Mar 19 07:46:24 UTC 2021
On 19/03/2021 4:52 pm, Thomas Stüfe wrote:
> 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)
+ static void* volatile _stack_pad = alloca(((pid ^ counter++) & 7) * 128);
+ if (_stack_pad != 0) {
+ ((char*)_stack_pad)[0] = 1;
+ }
still didn't call alloca, or show the calculation of the value passed to
alloca.
call getpid at PLT
.LVL2493:
movl %eax, %ebx
.LVL2494:
.loc 3 1363 18 view .LVU7888
.LBE6400:
.LBE6399:
.loc 3 668 3 is_stmt 1 view .LVU7889
.loc 3 668 38 is_stmt 0 view .LVU7890
movzbl _ZGVZL19thread_native_entryP6ThreadE10_stack_pad(%rip),
%eax
.LVL2495:
.loc 3 668 38 view .LVU7891
testb %al, %al
je .L2255
.L2214:
.loc 3 669 3 is_stmt 1 view .LVU7892
.loc 3 669 7 is_stmt 0 view .LVU7893
movq _ZZL19thread_native_entryP6ThreadE10_stack_pad(%rip), %rax
.loc 3 669 3 view .LVU7894
testq %rax, %rax
je .L2216
.loc 3 670 5 is_stmt 1 view .LVU7895
.loc 3 670 6 is_stmt 0 view .LVU7896
movq _ZZL19thread_native_entryP6ThreadE10_stack_pad(%rip), %rax
.loc 3 670 28 view .LVU7897
movb $1, (%rax)
.L2216:
.loc 3 673 3 is_stmt 1 view .LVU7898
.loc 3 673 36 is_stmt 0 view .LVU7899
movq %r13, %rdi
call _ZN6Thread25initialize_thread_currentEv at PLT
I don't know what to suggest.
David
-----
> ..Thomas
>
> On Fri, Mar 19, 2021 at 7:47 AM David Holmes <david.holmes at oracle.com
> <mailto: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>
> >> <https://git.openjdk.java.net/jdk/pull/3042
> <https://git.openjdk.java.net/jdk/pull/3042>>
> >> >>
> >>
>
More information about the hotspot-dev
mailing list