get_stack_bounds using read(2) syscalls to read /proc/self/maps byte-by-byte

[Stephan Bergmann]

On 02/12/2013 06:46 PM, Stephan Bergmann wrote:
> On some Linux box (Fedora 18, using
> java-1.7.0-openjdk-1.7.0.9-2.3.5.fc18.x86_64) I happened to look at an
> strace of a LibreOffice process (which can instantiate the JVM
> in-process), and noticed lots of calls to read(2) to read individual
> bytes of /proc/self/maps.
>
> And get_stack_bounds in os/linux/vm/os_linux.cpp indeed calls out to
> os::get_line_chars in share/vm/runtime/os.cpp that does
>
>    read(fd, &buf[i], 1)
>
> This appears to be introduce with
> <http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/677234770800>
> "7017193: Small memory leak in get_stack_bounds
> os::create_stack_guard_pages" to fix
> <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7017193> "Small
> memory leak in get_stack_bounds // os::create_stack_guard_pages."
>
> Is this a known performance issue?  A (likely naive) Web search did not
> show anything that looked relevant, but I have vague memories of having
> seen it mentioned somewhere a while ago.

This lead to bug reports like 
<https://bugzilla.redhat.com/show_bug.cgi?id=902004> "very bad 
performance with E-Porto Add-In für OpenOffice Writer installed" against 
LibreOffice now, so I took another look.

The design of the LibreOffice extension infrastructure can lead, under 
certain conditions, to frequent (main thread) JNI 
Attach/DetachCurrentThread calls.  This is a known problem with 
LibreOffice and modern JVMs on Linux, but one for which there is 
unfortunately no quick and easy fix in LibreOffice.

So I prepared a local OpenJDK 1.7.0 version where I reverted 
<http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/677234770800> 
"7017193: Small memory leak in get_stack_bounds 
os::create_stack_guard_pages" and instead applied the changes discussed 
in <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7017193> "Small 
memory leak in get_stack_bounds // os::create_stack_guard_pages" to 
get_satck_bounds in openjdk/hotspot/src/os/linux/vm/os_linux.cpp, i.e., 
changing from using per-byte read(2) calls to using larger getline(2) 
calls when reading /proc/self/maps.  This caused the problems described 
in <https://bugzilla.redhat.com/show_bug.cgi?id=902004> "very bad 
performance with E-Porto Add-In für OpenOffice Writer installed" to 
become much less dramatic.

So I wonder, what was the reason to address 
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7017193> "Small 
memory leak in get_stack_bounds // os::create_stack_guard_pages" with 
<http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/677234770800> 
"7017193: Small memory leak in get_stack_bounds 
os::create_stack_guard_pages" and accept a performance degradation in 
certain cases?  I see no obvious problems with the suggested fix in 
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7017193> "Small 
memory leak in get_stack_bounds // os::create_stack_guard_pages?"

Stephan