64 bit and safepoint polling

[Vladimir Kozlov]

I mean we can first reserve memory for (codecache_size + 1) in
large pages to get continues space. After that we can release
first page and ask again to reserver small polling page at that
released space. But windows may not allow to do it.

Or we can simple ask (in a loop until we get it) OS to reserver
small polling page after codecache at given address range which
is not larger then 4Gb, we don't need to have this page on
the border of codecache.

Vladimir

Tom Rodriguez wrote:
> 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
>