RR(S): 8009062 poor performance of JNI AttachCurrentThread after fix for 7017193

[Dmitry Samersoff]

Hi Everybody,

Here is webrev of proposed changes:

http://cr.openjdk.java.net/~dsamersoff/8009062/webrev.04/

Any comments is much appreciated.

The problem:

Under Linux stack of main thread is growable, so we have to make sure
that address we plan to put a guard pages to and below is not mapped.

Historically we find bounds of the stack of main thread by seeking
/proc/self/maps for "[stack]" and parsing this line.

I don't like buffered reading of /proc files and sometimes ago rewrite
this function to read it byte-to-byte. Unfortunately, resulting
performance penalties is not acceptable.


Solution:

Below is slightly different approach - I use mincore(2) to check whether
the page is mapped or not. Typically mincore(2) is used to check whether
the page is resides in physical memory or not, but this function returns
-1 and set errno to ENOMEM if a region we are asking about contains not
mapped memory.

Testing:

Passed jprt and couple of jtreg tests. No special regression test
necessary as the test for 6929067 covers this case as well.

-Dmitry



On 2013-03-28 23:02, Adam Domurad wrote:
> On 03/11/2013 01:19 PM, Dmitry Samersoff wrote:
>> Adam,
>>
>> Sorry! I can't provide any estimations right now. But it's a high
>> priority issue in my queue, and I plan to provide a fix as soon as it
>> become possible.
>>
>> -Dmitry
>>
>> On 2013-03-06 21:45, Adam Domurad wrote:
>>> On 03/01/2013 11:00 AM, Dmitry Samersoff wrote:
>>>> Adam,
>>>>
>>>> Thank you for advice! I'm looking for a possibility to remove
>>>> get_stack_bounds function entirely as Dean suggested. But it takes some
>>>> time.
>>> Hi again, not to be a bother, but do you have a rough time-frame that
>>> the fix will take?
>>>
>>> Thanks,
>>> -Adam
>>
> 
> As per our off-list chat, I have attached my implementation of a revised
> implementation of get_stack_bounds with a small test-case. As far as
> performance is concerned, it's an order of magnitude faster from my
> timings. This should be suitable given that no problems were reported
> with the old implementation.
> 
> Happy hacking,
> -Adam


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