JDK-8194687 : SA attach to process with AOT library takes too long
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 10,11
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2018-01-05
  • Updated: 2020-03-13
  • Resolved: 2020-03-13
Related Reports
Duplicate :  
JDK-8207363 - 42 serviceability/sa tests timed out when running with jtreg
Duplicate :  
JDK-8207363 - 42 serviceability/sa tests timed out when running with jtreg
Relates :  
JDK-8214797 - TestJmapCoreMetaspace.java timed out
Sub Tasks
JDK-8214759 :  
Problem list TestJmapCore.java and TestJmapCoreMetaspace.java for Graal - Closed
Description
Tests like jdk/sun/tools/jhsdb/BasicLauncherTest.java timeout attaching to a process with AOT libjava.base.so.   build_symtab_internal() is taking a long time to process all the symbols.
Comments
TestJmapCore.java and TestJmapCoreMetaspace.java are already timing out even without AOT. See JDK-8214797. Also, the following is normal for these test. It's what the test does to generate the core file: Crash: Internal Error ...debug.cpp...fatal error: OutOfMemory encountered: Metaspace So that leaves the original issue, which is the timeout of tests like BasicLauncherTest.java when run with AOT. There have been new sightings since 2018-11-10.
13-03-2020
"intermittent" label to denote that the test failures (TestJmapCore.java and TestJmapCoreMetaspace.java) seen due to this are intermittent.
30-11-2018
Planning on Problem listing TestJmapCore.java and TestJmapCoreMetaspace.java for Graal as a subtask for this.
30-11-2018
I don't think that the SA code wrt reading in the symbols from a shared object has changed for a while. SA does not distinguish between STB_GLOBAL and STB_LOCAL symbols. With the 'strip -x' version of libjava.base.so, SA reads in and hashes about 9,500 symbols, while without the local symbols stripped, SA reads in and about 1,400,000 symbols (and that accounts for the extra 5 mts to attach, in the case of a HelloWorld prg). Typically for C/C++ libs, we have the static symbols generated as STB_LOCAL entries in the symbol table. For AOT libs, I see a lot of STB_LOCAL symbols with names like M<number>_<number>_<class_name> or data.<number>.<number> or got.state.M<number>.
10-01-2018
The main problem seems to be local symbols. If I run 'strip -x' on the AOT libraries to remove local symbols, the problem goes away. Has SA always tried to hash all local library symbols on attach, or has AOT introduced new local symbols recently?
08-01-2018
I don't think we had this problem before, when we used native code to generate the AOT object file.
05-01-2018