Huge pages

[Volker Simonis]

Hi Tiago,

thanks for the information.

I think under these circumstances it will be not so easy to make huge
pages work with the current way how the HotSpot VM allocates memory
(i.e mmapping huge memory areas with MAP_NORESERVE and later
committing them partially and independently of each other with
MAP_FIXED|MAP_HUGETLB).

This would probably require a bigger rework of the allocation code. I
think I have some basic ideas how this can be done - it requires a
bookkeeping for every region to remember if it should use huge pages
or not. Unfortunaltey it's notoriously hard to bring such shared code
changes into the HotSpot main code line, but perhaps this will become
easier once our port is part of the HotSpot main code line.

Regards,
Volker

On Mon, Apr 29, 2013 at 4:51 PM, Tiago Stürmer Daitx
<tdaitx at linux.vnet.ibm.com> wrote:
>> On Thu, 2013-04-11 at 16:26 +0200, Volker Simonis wrote:
>>
>> > I think it will be not trivial to get this working with all the
>> > combinations of different GCs and +/- compressed oops on all Linux
>> > architectures.
>> >
>> > It would be really great if you could find sombody from the LTC who
>> > can explain why mmap with MAP_HUGETLB behaves differently on x86 and
>> > ppc.
>
> Volker, I got the following response from a PPC Kernel dev:
>
> 'On ppc64, you can only have one page size in a "slice".  Slices are
> 256M below 4G, then 4G-1TB then 1TB slices above that.  Since the
> MAP_NORESERVE is not a hugepage mapping, it is not being placed to
> accomodate these restrictions. Overmapping with MAP_FIXED is then
> failing.'
>
> Let me know if you need additional information on this issue.
>
> --
> Tiago Stürmer Daitx
> tdaitx at linux.vnet.ibm.com
> IBM - Linux Technology Center
>