4星 · 超过85%的资源 需积分: 9 32 浏览量 更新于2023-05-30 评论 5 收藏 42KB PDF 举报
该资料很详细的讲述了在Windows环境下Java进程的内存分配问题，包括内核空间和用户空间内存分配，为什么Java堆的实际最大内存分配为1.5G，为什么需要同时配置xms和xmx以及如何扩大用户空间等。 1. How is the space in a basic Win32 process allocated ? The 32-bit Windows secret ! Structure of a standard Win32 process 2. What are the Win32 java process memory requirements ? Java Virtual Machine Java heap JIT compiled code Java threads Hitting the buffers 3. Can we extend the Win-32 process space ?
Windows Java address space
This article applies to the IBM 32-bit SDK and Runtime Environment for
Windows, Java2 Technology Edition. It explains how the process space
for Java is divided and explores a way of increasing the available space.
How is the space in a basic Win32 process allocated ?
A 32-bit architecture imposes a fundamental limit on an address range
of 4 GB. Hence, on a 32-bit platform any given process can theoretically
achieve a maximum size of 4 GB.
Unfortunately, on Win-32, the process space available to an application
is only 2 GB. Why is this ?
When the NT kernel was being designed, it was decided to conceptually
split the process space into two. One half for the application and one
half for use by the OS. At the time 2 GB must have seemed far more
space than anyone could possibly use. This split had certain
advantages, in that the internal address tables used by NT only needed
to be 31 bits wide.
Inside this 2 GB space, the process code and its memory requirements
are loaded at the ‘bottom’ of the space. (For the purpose of this article
we will refer to virtual address 0x00000000 as the ‘bottom’ of the
process space and address 0x7FFFFFFF as the ‘top’ of the space.)
Every application has at least one thread. A thread has an associated
stack, which is storage space allocated on its behalf from the process
space. In addition, most applications will use dynamic memory space,
either explicitly by calls such as ‘malloc’ and ‘free’, or implicitly for
example by the C++ ‘new’ operator. Stack and dynamic memory
storage is managed by Windows by means of a ‘heap’. The heap is
usually loaded above the application code and grows upwards.
When linking your application, you need to link in certain OS libraries. A
Java process loads a large number of Java libraries - the JVM
executable is very small, most of the VM comprises Dynamic Link
Libraries (DLLs). In addition, most applications link in application
libraries. For the purposes of this article, we consider application native
code libraries to be part of the application; they are loaded at addresses
determined by the application. In the case of the VM, the VM link
libraries are sometimes loaded at the bottom of the process space or
sometimes not, depending on whether you are in a WebSphere
environment and the version of the JVM you are using. The OS libraries
are loaded at the top of the process 2 GB space (address 0x70000000
and upwards). These libraries are important when considering the
memory map of a Java process as we shall see.
The 32-bit Windows secret !
It’s a little known ‘secret’, but the vast majority of Windows applications
are 31-bit code, not 32-bit ! An application’s address range is from
0x00000000 to 0x7FFFFFFF. A default Windows process can never
have a ‘negative’ pointer (where the most significant bit of the pointer is
Structure of a standard Win32 process
What are the Win32 java process memory requirements ?
A Java process executable code is the Java Virtual Machine (VM). It
has the same requirements as any other Windows process, but in
addition needs memory space for
y Application byte codes (Java classes)
y The Java heap
y JIT-compiled code
Java Virtual Machine
The virtual machine (VM) is the mechanism for executing the byte codes
in your java application. It is just a C application.
The Java heap is where the VM stores Java objects. It should not be
confused with the standard Windows heap space we already alluded to.
A Java process therefore has two heaps. To distinguish them we refer
to the ‘Java heap’ and the ‘native heap’. The Java heap is a single
contiguous chunk of memory. It is a single malloc’d chunk of memory
which is never freed and is internally managed by the VM storage
component, the Garbage Collector.
The Java heap is allocated as a single chunk of memory whose size is
specified by the -Xmx command line parameter. If you don’t specify
Xmx it takes a default value of half of available physical memory up to a
maximum of (2 GB - 1) bytes. It is allocated as virtual memory. The
amount of physical memory initially committed to the heap is specified
by the -Xms parameter. As with Xmx, this parameter takes a default if
Tip ! Specify the max heap size you want with -Xmx. Specify Xms
as a low value
. These settings allow the Java process to start
with the minimum amount of physical memory and, as the heap
grows, the Garbage Collector can optimise it. It is rarely a
good idea to specify a large value for Xms.
JIT compiled code
A Java process interpreting Java byte codes cannot approach the
performance of compiled code. A VM has a bundled compiler that
compiles Java byte codes into true platform code. Because the
compiler is invoked at runtime and compiles the code ‘just in time’ to
execute, it is known as a Just-In-Time compiler or more commonly by its
initials as a JIT compiler. In fact, we usually just refer to the JIT
compiler as ‘the JIT’ and to JIT-compiled code as ‘JIT’d code’.
It is important to note that the JIT does NOT compile Java byte codes
the first time those byte codes are executed. If it did this, then the VM
would take a very long time to start up, as thousands of methods were
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额