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

[Yasumasa Suenaga]

On Fri, 19 Mar 2021 18:38:53 GMT, hjl-tools <github.com+1072356+hjl-tools at openjdk.org> wrote:

>> 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.
>> 
>> @hjl-tools Do you think we need anything like this on current CPUs?
>
>> 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.
>> 
>> @hjl-tools Do you think we need anything like this on current CPUs?
> 
> We don't need MULTI_PAGE_ALIASING anymore in glibc.

> It would be good to confirm that the alloca is also being elided with
> clang and VS.

I debug'ed fastdebug JDK on Visual Studio, it seems to work `alloca()`:

  // Try to randomize the cache line index of hot stack frames.
  // This helps when threads of the same stack traces evict each other's
  // cache lines. The threads can be either from the same JVM instance, or
  // from different JVM instances. The benefit is especially true for
  // processors with hyperthreading technology.
  static int counter = 0;
  int pid = os::current_process_id();
00007FFFDEBDCFF0  add         byte ptr [rbx-7A78FEF3h],cl  
  _alloca(((pid ^ counter++) & 7) * 128);
00007FFFDEBDCFF6  add         byte ptr [rbx-2FCC2Fh],cl  
00007FFFDEBDCFFC  ror         dword ptr [rcx-7A790AF3h],0  
00007FFFDEBDD003  and         edx,7  
00007FFFDEBDD006  shl         edx,7  
00007FFFDEBDD009  mov         eax,edx  
00007FFFDEBDD00B  lea         rcx,[rdx+0Fh]  
00007FFFDEBDD00F  cmp         rcx,rax  
00007FFFDEBDD012  ja          thread_native_entry+6Eh (07FFFDEBDD01Eh)  
00007FFFDEBDD014  mov         rcx,0FFFFFFFFFFFFFF0h  
00007FFFDEBDD01E  and         rcx,0FFFFFFFFFFFFFFF0h  
00007FFFDEBDD022  mov         rax,rcx  
00007FFFDEBDD025  call        __chkstk (07FFFDEEFF430h)  
00007FFFDEBDD02A  sub         rsp,rcx  

`alloca()` is also in os_bsd.cpp and os_aix.cpp, but I cannot check them because I do not have them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3042