Very poor performance of JNI AttachCurrentThread on Linux

[Andrew Haley]

On 02/26/2013 08:38 PM, Dmitry Samersoff wrote:
> Andrew,
> 
> I'm repeating the answer I sent to Stephan Bergmann few days below,
> is it the same issue with Libre Office?
> 
> 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

It's clear now, as can be seen from that bug.

> 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.

I don't understand this.  Only reading the first 128 bytes makes sense
if you're trying to improve performance, but the performance is very
poor.

> 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)

Yes.  How is this relevant?  Do you think that getline() might
actually rely on the reported size of a file or on notification?

> 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.

OK.  I don't really mind how this gets fixed; I will go along with any
buffering strategy that brings the performance back to where it was
before.

> Is there a performance problems with other applications?

Other than what?  Every usage of JNI AttachCurrentThread is severely
impacted.

Andrew.