Understanding Memory Administration > 자유게시판

• 목록
• 답변
• 글쓰기
• 게시판 리스트 옵션
  • 수정
  • 삭제

Memory administration is the means of allocating new objects and eradicating unused objects to make house for those new object allocations. This part presents some fundamental memory administration ideas and explains the basics about object allocation and rubbish assortment within the Oracle JRockit JVM. For information about how to make use of command line choices to tune the Memory Wave management system, see Tuning the Memory Administration System. Java objects reside in an space referred to as the heap. The heap is created when the JVM begins up and may increase or decrease in measurement while the application runs. When the heap turns into full, rubbish is collected. Throughout the garbage collection objects that are not used are cleared, thus making house for brand new objects. Observe that the JVM makes use of extra memory than just the heap. For example Java methods, MemoryWave Community thread stacks and native handles are allotted in memory separate from the heap, in addition to JVM inner data constructions.

The heap is sometimes divided into two areas (or generations) referred to as the nursery (or younger space) and the previous house. The nursery is part of the heap reserved for allocation of recent objects. When the nursery turns into full, rubbish is collected by operating a particular younger assortment, where all objects which have lived long enough in the nursery are promoted (moved) to the old space, thus freeing up the nursery for extra object allocation. When the previous area turns into full garbage is collected there, a process called an old assortment. The reasoning behind a nursery is that the majority objects are momentary and brief lived. A young collection is designed to be swift at finding newly allocated objects that are nonetheless alive and transferring them away from the nursery. Usually, a younger assortment frees a given quantity of memory a lot quicker than an old assortment or a rubbish collection of a single-generational heap (a heap and not using a nursery). In R27.2.0 and later releases, a part of the nursery is reserved as a keep space.

The keep area comprises essentially the most not too long ago allotted objects in the nursery and isn't garbage collected till the following young collection. This prevents objects from being promoted just because they have been allocated right earlier than a young assortment started. Throughout object allocation, the JRockit JVM distinguishes between small and large objects. The restrict for when an object is taken into account giant depends upon the JVM version, the heap measurement, the garbage assortment strategy and the platform used, however is usually someplace between 2 and 128 kB. Please see the documentation for -XXtlaSize and -XXlargeObjectLimit for more information. Small objects are allocated in thread local areas (TLAs). The thread native areas are free chunks reserved from the heap and given to a Java thread for exclusive use. The thread can then allocate objects in its TLA without synchronizing with different threads. When the TLA turns into full, the thread simply requests a new TLA.

The TLAs are reserved from the nursery if such exists, otherwise they are reserved anywhere in the heap. Massive objects that don’t match inside a TLA are allocated immediately on the heap. When a nursery is used, the big objects are allotted directly in outdated area. Allocation of giant objects requires extra synchronization between the Java threads, although the JRockit JVM makes use of a system of caches of free chunks of different sizes to cut back the necessity for synchronization and improve the allocation pace. Garbage collection is the strategy of freeing area in the heap or the nursery for allocation of new objects. This part describes the garbage collection in the JRockit JVM. The JRockit JVM makes use of the mark and sweep rubbish assortment model for performing rubbish collections of the entire heap. A mark and Memory Wave sweep garbage collection consists of two phases, the mark phase and the sweep phase. In the course of the mark phase all objects that are reachable from Java threads, native handles and different root sources are marked as alive, as effectively as the objects which are reachable from these objects and so forth.