With JDK7 b23 on Windows Server 2003 64-bit (using the 32-bit JDK):

C:\> z:\7\b23\windows-i586\fastdebug\bin\java -server -Xmn500m -Xms750m -Xmx750m
-Xss96k -XX:+UseParallelOldGC -XX:+AggressiveOpts -XX:+PrintCommandLineFlags -XX
:+UseLargePages -XX:+TracePageSizes -version
VM option '+UseParallelOldGC'
VM option '+AggressiveOpts'
VM option '+PrintCommandLineFlags'
VM option '+UseLargePages'
VM option '+TracePageSizes'
-XX:+AggressiveOpts -XX:MaxHeapSize=786432000 -XX:MaxNewSize=524288000 -XX:NewSi
ze=524288000 -XX:+PrintCommandLineFlags -XX:ThreadStackSize=96 -XX:+TracePageSiz
es -XX:+UseLargePages -XX:+UseParallelGC -XX:+UseParallelOldGC
code heap:  min=2359296 max=50331648 pg_sz=2097152 base=0x02000000 size=50331648

Java HotSpot(TM) Server VM warning: os::commit_memory failed
Error occurred during initialization of VM
Could not reserve enough space for code cache


This is fastdebug; it also fails with product VM.  It does not fail in b21.
Posted Date : 2007-12-17 21:45:30.0

Do not use large pages on windows (omit the option -XX:+UseLargePages).  This reduces performance on large heaps, so is not acceptable for many users.

The fix for 6588638 (improve support for large pages) generalized large page support and started mapping the code cache with large pages in addition to the java heap.  This did not work on systems where large page memory cannot be committed on demand.  Solaris MPSS (the default and preferred method on solaris 9 and later) allows large page memory to be committed on demand and works fine.

Linux and solaris with ISM use shared memory segments to get large pages; the memory cannot be committed on demand.  Windows uses VirtualAlloc() to get large pages; the memory cannot be committed on demand. 

There are multiple problems.  The first is that the hotspot ReservedSpace ctor takes a boolean parameter, large, which must be set to true to get large page memory on systems that cannot commit large pages on demand.  The code cache creation code was not passing large == true to the ReservedSpace ctor when attempting to get large pages.

The second is that the code cache memory must have execute permissions.  On windows, the code to reserve large page memory was not requesting execute permissions.  On linux and solaris + ISM, the shm* apis used to request large page memory do not allow the execute bit to be specified, so the code cache cannot be mapped using large pages on these systems.

The final problem, specific to solaris + ISM, is that the JVM's _page_size_table was not being initialized properly.

Created RFE 6677036 to track enabling large pages for the code cache on linux, when/if the kernel allows large page memory to have execute permission.
Posted Date : 2008-03-25 02:18:08.0

Other structures that may use large pages (the marking bitmap and region table used by the parallel compacting collector) must also set parameter large == true when constructing the ReservedSpace.
Posted Date : 2008-03-22 01:22:32.0

Even though there is no way to request it through the shm* apis, solaris with ISM enables execute permissions on large page memory, at least on solaris 10.  Using a JVM where can_execute_large_page_memory() returns true on solaris with ISM and the code cache is mapped at 0xfb800000:

   $ pmap -s 10827 | egrep FB800000
   FB800000   32768K   4M rwxsR    [ ism shmid=null ]

However, I was not able to test on solaris 8, the only release where ISM should be used, and the execute permissions are not documented.  So can_execute_large_page_memory() returns false on solaris with ISM.
Posted Date : 2008-03-25 03:11:56.0