直接分配给老一代的巨大对象的大小 [英] Size of Huge Objects directly allocated to Old Generation

问题描述

最近我一直在阅读Java中不同时代的对象分配。大多数时候，新对象分配在伊甸园（年轻一代的一部分），然后，如果满足以下任何条件，他们将被提升到老一代。

（ 1）对象的年龄达到使用期限


（2）当对象从Eden（或）另一个幸存者空间（from）复制时，幸存者空间（to）已满。

但也有一种特殊情况，其中的对象直接分配给老一代，而不是从年轻一代晋升。当我们尝试创建的对象很大时（可能是几MB的顺序），就会发生这种情况。

---

有什么方法可以知道巨大/庞大物体的大小/限制吗？我意识到G1垃圾收集器的巨大对象标准。我只想知道在Java 6之前或在Java 6中的大小限制。

感谢您的时间：）

解决方案

一个对象HotSpot JVM在年轻一代可能分配的最大大小几乎与Eden（YoungGen减去两个Survivor空间）的大小一样大。 >

这就是分配的样子：

1. 使用线程本地分配缓冲区（TLAB） ，如果 tlab_top + size <= tlab_end >
   这是最快的路径。分配只是 tlab_top 指针增量。


2. 如果TLAB差不多满了，请在Eden中创建一个新的TLAB，然后在新的TLAB中重新尝试。


3. 如果TLAB剩余空间不够，仍然大到丢弃，试图直接在伊甸园分配一个对象。在Eden中的分配也是一个指针增量（ eden_top + size < = eden_end <

4. 如果在Eden中分配失败，通常会发生次要集合。


5. 如果在年轻GC之后伊甸园没有足够的空间，那么会尝试在老一代中直接分配。




Recently I've been reading about object allocations in different generations in Java. Most of the times new objects are allocated in Eden (part of Young Generation) and then they're promoted to Old Generation if any of the following criteria are met.

(1) Object's age reached the tenuring threshold
(2) Survivor space (to) is full when objects are being copied from Eden (or) another survivor space(from)

But there's also a special case in which objects are directly allocated in the Old Generation instead of being promoted from the young generation. This happens when the object that we're trying to create is huge (possibly of the order of few MBs).

---

Is there any way to know the size/limit of the huge/humongous objects? I'm aware of the humongous objects criteria for G1 Garbage Collector. I just want to know the size limit before or in Java 6.

Thanks for your time :)

解决方案

The maximum size of an object HotSpot JVM may allocate in young generation is nearly as large as the size of Eden (YoungGen minus two Survivor spaces).

That's how the allocation rougly looks like:

1. Use thread local allocation buffer (TLAB), if tlab_top + size <= tlab_end
   This is the fastest path. Allocation is just the tlab_top pointer increment.
2. If TLAB is almost full, create a new TLAB in Eden and retry in a fresh TLAB.
3. If TLAB remaining space is not enough but is still to big to discard, try to allocate an object directly in Eden. Allocation in Eden is also a pointer increment (eden_top + size <= eden_end) using atomic operation, since Eden is shared between all threads.
4. If allocation in Eden fails, a minor collection typically occurs.
5. If there is not enough space in Eden even after Young GC, an attempt to allocate directly in Old generation is made.

这篇关于直接分配给老一代的巨大对象的大小的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！