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

Andrew Hughes gnu.andrew at redhat.com
Sun Mar 9 22:30:52 UTC 2014

----- Original Message -----
> Hi Everybody,
> Here is webrev of changes I'm about to integrate:
> http://cr.openjdk.java.net/~dsamersoff/8009062/webrev.13/
> 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.
> But after intensive testing we figured out that it's not required to
> re-read stack bounds after create_attached_thread() because we are
> manually grow stack up to the bounds in create_attached_thread()
> Solution:
> 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, jck and and couple of ute tests. Wrote special regression test.
> -Dmitry
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.

I noticed this fix still isn't in 7u. Are there plans to backport it? 7017193,
which causes a major performance regression, is present in 7u.

Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

More information about the hotspot-dev mailing list