Using apcs frame layout

Anton Kozlov akozlov at azul.com
Fri Mar 25 13:42:06 UTC 2016


Hi, All!

As you know, frame layout isn't specified on aarch32 platform. Although it provide us flexibillity in choosing interpreter and compiled frame layouts, it causes some troubles with existing tools, such as perf.

Perf is great, because it can show system and java code simultaniously, more in http://techblog.netflix.com/2015/07/java-in-flames.html, for example.
There is PreserveFramePointer jdk option, which prevents jit compiler from using fp as general-purpose register. With this, java callstack should have same shape as any general callstack, which can be unwinded by any tool, perf in specific.

On aarch32, PreserveFramePointer (using fp as frame link) is not enough to capture call stack, as, again, frame layout is not specified. Here, special debug info is provided by executable to point unwinder where frame links are stored on stack. Another option for application is to use deprecated APCS layout, consisting of 4 words (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0041c/Cegbidie.html), which is also supported by gcc, perf, gdb, ....

Considering these options with aarch32-port in mind, with current frame layout, perf should be modifed to understand java frames or to take debug info from java runtime instead of some application debug info. These changes are unlikely to be integrated to perf.

I suggest that APCS frame layout will be easier and more straightforward to implement. Extra bonus for this is not only perf, but gdb will show backtraces too.
Since APCS layout is bigger, it make sense to not use it allways.
How about to add a flag that forces APCS layout for interpreter and compiled frames? Maybe use PreserveFramePointer for this?
What do you think? Are there objections against APCS layout or flag?

Thanks,
Anton


More information about the aarch32-port-dev mailing list