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

[Dmitry Samersoff]

Stephan,

There was some reasons for me to go off getline:

1. Behaviour of getline is not properly documented so it's not clean for
me whether we should clean the buffer on all platforms for all version
of libc in case of getline error.

see http://sourceware.org/bugzilla/show_bug.cgi?id=5666

2. The fix reduces number of heap memory allocations/deallocations
within VM.

Huge java app with long paths to DSO could have huge map file, getline
version read it entirely, but we are interesting in first
128 bytes of each line only.

3. Kernel doesn't report size of /proc files and doesn't notify process
on /proc/* files changes
(see e.g. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/454722)

So buffered reading of /proc/* files could lead to subtle errors or
crashes if file is changed during read e.g. after suspend/resume.


It might be possible to reduce number of read syscalls by implementing
some internal bufferisation but I definitely would prefer not to return
getline. Is there a performance problems with other applications?


-Dmitry




On 2013-02-21 18:02, Stephan Bergmann wrote:
> 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


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer