64 bit and safepoint polling

[Chuck Rasbold]

I'm seeing a problem as a result of a collection of factors.  We have an
internal agent (on by default), on a particular Linux release, when running
under make, provokes an odd memory pattern with a large displacement between
the polling page and the CodeCache.  So... Queens fails when the safepoint
poll is executed.

We haven't seen the problem under other circumstances, so it isn't a
pressing need.   But the Queens crashing is annoying and a guarantee would
be nice.

Orthogonally, the cause of the strange layout is of concern here.

I also thought about moving the polling page into the code cache.  Do you
think a single large page will impact the code cache significantly?


On Wed, Sep 22, 2010 at 10:15 AM, Tom Rodriguez <tom.rodriguez at oracle.com>wrote:

> No it doesn't work correctly.  I think I filed a bug about this a little
> while ago but I can't find it at the moment.  The code should just be
> updated to handle it properly though we'd really like to ensure that it
> isn't far away since it makes the polling code sequence a lot worse.  I'd
> considered something like allocating the polling page out of the code cache
> to make sure it's near but that doesn't work that well if we use large pages
> for the code cache.  Maybe there's a way to make it work though.  Have you
> hit this problem?
>
> tom
>
> On Sep 22, 2010, at 9:47 AM, Chuck Rasbold wrote:
>
> > In a 64 bit JVM, when the polling page is more than a 32 displacement
> from the codeCache, does the code generated by C2 for safepoint polling work
> correctly?
> >
> > If not, should there be a guarantee in JVM startup about the maximum
> displacement supported?
> >
> > -- Chuck
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100922/bf3ed8ac/attachment-0001.html