RFR: 8263718: unused-result warning happens at os_linux.cpp
Yasumasa Suenaga
ysuenaga at openjdk.java.net
Fri Mar 19 12:53:40 UTC 2021
On Fri, 19 Mar 2021 09:04:12 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:
>>> + static void* volatile _stack_pad = alloca(((pid ^ counter++) & 7) * 128);
>>> + if (_stack_pad != 0) {
>>> + ((char*)_stack_pad)[0] = 1;
>>> + }
>>
>> I guess `_stack_pad` will be overwritten in each `threaad_native_entry()` call, so it might be elided.
>> I modified the code as following, it seems to work - we cannot see `alloca()`, however the stack is expanded.
>>
>> diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_linux.cpp
>> index 5af63befb58..bdb2dc89615 100644
>> --- a/src/hotspot/os/linux/os_linux.cpp
>> +++ b/src/hotspot/os/linux/os_linux.cpp
>> @@ -665,7 +665,8 @@ static void *thread_native_entry(Thread *thread) {
>> // processors with hyperthreading technology.
>> static int counter = 0;
>> int pid = os::current_process_id();
>> - alloca(((pid ^ counter++) & 7) * 128);
>> + void *ptr = alloca(((pid ^ counter++) & 7) * 128);
>> + ((char *)ptr)[0] = 1;
>>
>> thread->initialize_thread_current();
>>
>> 659 thread->record_stack_base_and_size();
>> 0x00007ffff7154d53 <+35>: call 0x7ffff75b3a80 <_ZN6Thread26record_stack_base_and_sizeEv>
>>
>> 660
>> 661 // Try to randomize the cache line index of hot stack frames.
>> 662 // This helps when threads of the same stack traces evict each other's
>> 663 // cache lines. The threads can be either from the same JVM instance, or
>> 664 // from different JVM instances. The benefit is especially true for
>> 665 // processors with hyperthreading technology.
>> 666 static int counter = 0;
>>
>> 667 int pid = os::current_process_id();
>>
>> 668 void *ptr = alloca(((pid ^ counter++) & 7) * 128);
>> 0x00007ffff7154d63 <+51>: mov 0xc1daff(%rip),%eax # 0x7ffff7d72868 <_ZZL19thread_native_entryP6ThreadE7counter>
>> 0x00007ffff7154d69 <+57>: lea 0x1(%rax),%edx
>> 0x00007ffff7154d6c <+60>: xor %r8d,%eax
>> 0x00007ffff7154d6f <+63>: shl $0x7,%rax
>> 0x00007ffff7154d73 <+67>: mov %edx,0xc1daef(%rip) # 0x7ffff7d72868 <_ZZL19thread_native_entryP6ThreadE7counter>
>> 0x00007ffff7154d79 <+73>: and $0x380,%eax
>> 0x00007ffff7154d7e <+78>: add $0x17,%rax
>> 0x00007ffff7154d82 <+82>: and $0x7f0,%eax
>> 0x00007ffff7154d87 <+87>: sub %rax,%rsp
>> 0x00007ffff7154d8a <+90>: lea 0xf(%rsp),%rax
>> 0x00007ffff7154d8f <+95>: and $0xfffffffffffffff0,%rax
>>
>> 669 ((char *)ptr)[0] = 1;
>> 0x00007ffff7154d93 <+99>: movb $0x1,(%rax)
>
>> > I modified the code as following, it seems to work - we cannot see `alloca()`, however the stack is expanded.
>>
>> Sorry but I'm not seeing where the stack actually gets expanded?
>
> 0x00007ffff7154d87 <+87>: sub %rax,%rsp
>
> I guess `%rax` seems to contain the result of `((pid ^ counter++) & 7) * 128`, then `alloca()` is replaced to `sub` for `%RSP`.
> I saw the warning for this issue as `void* __builtin_alloca(long unsigned int)`. It might be it. We can just expand `%RSP` if we want to allocate buffer on the stack.
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.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3042
More information about the hotspot-dev
mailing list