64 bit and safepoint polling
rasbold at google.com
Wed Sep 22 10:34:21 PDT 2010
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
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?
> 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
> > If not, should there be a guarantee in JVM startup about the maximum
> displacement supported?
> > -- Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev