Моя рекомендация для работы с общим кодом (особенно с Java и .NET или библиотекой C / C ++) - использовать два набора репозиториев: один для исходного кода, а другой для контроля версий выпущенных изображений. Когда вы вносите изменения в «общий» проект, вы фиксируете свои исходные изменения в дереве исходных текстов, затем строите его и затем публикуете двоичные файлы, фиксируя их как новую ревизию в дереве релизов. Проекты, использующие «общий» проект, затем используют свойство svn: externals для добавления освобожденных двоичных файлов. Нет соблазна изменить локальные изображения общего кода. Если кто-то хочет изменить «общий» код, он делает это с помощью обычной практики разработки для этого проекта.
Подробнее см. В этом ответе на аналогичный вопрос.
Только Windows Server 2003 поддерживает большую страничную память. Чтобы использовать его, администратор должен сначала назначить дополнительные привилегии пользователю, который будет запускать приложение: 1. выберите Панель управления -> Администрирование -> Локальная политика безопасности. 2. выберите Локальные политики -> Назначение прав пользователя. 3. дважды щелкните «Заблокировать страницы в памяти», добавьте пользователей и / или группы. 4. перезагрузите компьютер
Поиск в Google ошибки приводит к исходному файлу hotspot / src / os / win32 / vm / os_win32.cpp в openjdk-6, который содержит следующий комментарий:
// Windows large page support is available on Windows 2003. In order to use
// large page memory, the administrator must first assign additional privilege
// to the user:
// + select Control Panel -> Administrative Tools -> Local Security Policy
// + select Local Policies -> User Rights Assignment
// + double click "Lock pages in memory", add users and/or groups
// + reboot
// Note the above steps are needed for administrator as well, as administrators
// by default do not have the privilege to lock pages in memory.
//
// Note about Windows 2003: although the API supports committing large page
// memory on a page-by-page basis and VirtualAlloc() returns success under this
// scenario, I found through experiment it only uses large page if the entire
// memory region is reserved and committed in a single VirtualAlloc() call.
// This makes Windows large page support more or less like Solaris ISM, in
// that the entire heap must be committed upfront. This probably will change
// in the future, if so the code below needs to be revisited.
Если вы используете Windows 2003, это может помочь. Если нет, у меня нет других предложений.