RFR: 8302369: Reduce the stack size of the C1 compiler

[SUN Guoyun]

On Wed, 15 Feb 2023 00:30:47 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> The current fact is that C1 uses more stack space than the C2 compiler, taking method `java.lang.Object::<init>`as an example on the x86_64 platform , the stack size used is 48 bytes for C1 compiler, while only 16 bytes is used for C2 compiler.
>> 
>> ========== C1-compiled nmethod =====
>> 0x00007f93311cc747: push %rbp
>> 0x00007f93311cc748: sub $0x30,%rsp // stack sizes is 48 bytes
>> 
>> 
>> ========== C2-compiled nmethod =======
>>     pushq rbp # Save rbp
>>     subq rsp, #16 # Create frame //stack sizes is 16 bytes
>> 
>> After this patch, the C1 compiler will use less stack space. also taking method `java.lang.Object::<init>`as an example on the x86_64 platform , the stack size used is 16 bytes, which is the same as C2 compiler.
>> 
>> ========== C1-compiled nmethod =====
>> 0x00007f80491ce647:   push   %rbp
>> 0x00007f80491ce648:   sub    $0x10,%rsp   //stack sizes is 16 bytes
>
> I got SEGV in almost all `serviceability/sa/` tests when run with -Xcomp:
> 
> 
> V  [libjvm.so+0xa8c950]  ClassLoaderData::is_alive() const+0x0  (classLoaderData.cpp:644)
> V  [libjvm.so+0x16a3b43]  nmethod::metadata_do(MetadataClosure*)+0x303  (nmethod.cpp:1614)
> V  [libjvm.so+0xb44761]  CompiledMethod::unload_nmethod_caches(bool)+0x101  (compiledMethod.cpp:557)
> V  [libjvm.so+0x16a299b]  nmethod::do_unloading(bool)+0xdb  (nmethod.cpp:1742)
> V  [libjvm.so+0x177577b]  CodeCacheUnloadingTask::work(unsigned int)+0x9b  (parallelCleaning.cpp:95)
> V  [libjvm.so+0xe77f77]  G1ParallelCleaningTask::work(unsigned int)+0x27  (g1ParallelCleaning.cpp:70)
> V  [libjvm.so+0x1bf6d10]  WorkerThread::run()+0x80  (workerThread.cpp:69)
> V  [libjvm.so+0x1a93a10]  Thread::call_run()+0x100  (thread.cpp:224)
> V  [libjvm.so+0x17341a3]  thread_native_entry(Thread*)+0x103  (os_linux.cpp:737)

@vnkozlov After I ran `make test CONF=release JTREG="VM_OPTIONS=-Xcomp" TEST=serviceability/sa/*` on x86_64 linux, all tests passed. How can I reproduce the SEGV problem you mentioned above?

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

PR: https://git.openjdk.org/jdk/pull/12548