RFR: 8263718: unused-result warning happens at os_linux.cpp

[Thomas Stüfe]

On Fri, Mar 19, 2021 at 6:54 PM Florian Weimer <fweimer at openjdk.java.net>
wrote:

> On Fri, 19 Mar 2021 17:33:35 GMT, Thomas Stuefe <stuefe at openjdk.org>
> wrote:
>
> >> I objdump'ed libjvm.so in JDK 16 Linux x64 from jdk.java.net , it also
> does not seem to expand the stack:
> >>
> >> 0000000000bd8500 <thread_native_entry(Thread*)>:
> >>   bd8500:       55                      push   %rbp
> >>   bd8501:       48 89 e5                mov    %rsp,%rbp
> >>   bd8504:       41 56                   push   %r14
> >>   bd8506:       41 55                   push   %r13
> >>   bd8508:       49 89 fd                mov    %rdi,%r13
> >>   bd850b:       41 54                   push   %r12
> >>   bd850d:       53                      push   %rbx
> >>   bd850e:       e8 ad 1e 1a 00          callq  d7a3c0
> <Thread::record_stack_base_and_size()>
> >>   bd8513:       e8 08 27 66 ff          callq  23ac20 <getpid at plt>
> >>   bd8518:       4c 89 ef                mov    %r13,%rdi
> >>   bd851b:       83 05 e6 a3 64 00 01    addl   $0x1,0x64a3e6(%rip)
>   # 1222908 <thread_native_entry(Thread*)::counter>
> >>   bd8522:       e8 39 1e 1a 00          callq  d7a360
> <Thread::initialize_thread_current()>
> >>   bd8527:       49 8b 9d 70 02 00 00    mov    0x270(%r13),%rbx
> >>   bd852e:       31 c0                   xor    %eax,%eax
> >>
> >> Result from `getpid()` will be stored into `%RAX`, however it is not
> used until `xor` at bd852e.
> >> And also I could not find out both `alloca()` call and manipulating
> `%RSP` at here.
> >
> > Writing to the *end* of the allocated area may do the trick.
> >
> > ..Thomas
>
> The use of `getpid` in this code suggests it dates back to LinuxThreads,
> where the PID differed from thread to thread. On current Linux, `getpid`
> really returns the PID, so this does nothing to randomize the offset within
> a single process.
>
> I would expect the system thread library to do this if it is beneficial.
> glibc replaced `COLORING_INCREMENT` (similar to this `alloca`, I believe)
> with `MULTI_PAGE_ALIASING` on i386 around 2003. `MULTI_PAGE_ALIASING` is
> implemented in a completely different way; it tweaks stack sizes to avoid
> accidental higher-level alignment (above the page level) between different
> threads.
>
>
Interesting. Ist this observable (eg via pthread_attr_getstacksize)?

..Thomas