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