64 bit and safepoint polling

[Tom Rodriguez]

You think we can use the noaccess_prefix stuff to get the space we need?  It looks like in some cases we will fall back to using large pages for the noaccess prefix.  Am I reading that right?  The logic in ReservedSpace is fairly complicated.

tom

On Sep 22, 2010, at 10:53 AM, Vladimir Kozlov wrote:

> I don't think you need to use large page for polling even if codecache use large pages.
> We do the same trick with perm gen and the rest of java heap where we use smaller page
> size for perm gen.
> 
> Vladimir
> 
> Tom Rodriguez wrote:
>> On Sep 22, 2010, at 10:34 AM, Chuck Rasbold wrote:
>>> 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. 
>> It does seem to be rare since we've only just seen a report of it and it's been a problem all along.  I'll try to push out the fix sometime soon since it's an annoyance.
>>> 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?  
>> It chews up physical memory for no good reason and large pages can be very large.  I don't know what the large page support in the code cache is like though.  Maybe we can tack a small page on at the end.
>> tom
>>> 
>>> 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
>>>