-
Enhancement
-
Resolution: Fixed
-
P4
-
10
-
b31
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8196246 | 8u191 | Zhengyu Gu | P4 | Resolved | Fixed | b01 |
| JDK-8201043 | 8u181 | Unassigned | P4 | Resolved | Fixed | b01 |
| JDK-8192048 | 8u172 | Zhengyu Gu | P4 | Resolved | Fixed | b01 |
| JDK-8203085 | emb-8u181 | Zhengyu Gu | P4 | Resolved | Fixed | master |
Vladimir Kozlov wrote:
> Compilers also use a lot thread local ResourceArea -
> Thread::current()->resource_area() and NEW_RESOURCE_ARRAY() macro.
> But thread local area is defined as mtThread:
> Thread() is called from CompilerThread() and we can pass a parameter to
> indicate user. Or add a virtual method to Thread class to check type of
> thread.
>
> In the past we had compiler local changes to get information how much
> memory was used during compilation but it was never get pushed. We
> accessed Arena::_bytes_allocated for that.
Following email thread for details:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-September/028360.html
> Compilers also use a lot thread local ResourceArea -
> Thread::current()->resource_area() and NEW_RESOURCE_ARRAY() macro.
> But thread local area is defined as mtThread:
> Thread() is called from CompilerThread() and we can pass a parameter to
> indicate user. Or add a virtual method to Thread class to check type of
> thread.
>
> In the past we had compiler local changes to get information how much
> memory was used during compilation but it was never get pushed. We
> accessed Arena::_bytes_allocated for that.
Following email thread for details:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-September/028360.html
- backported by
-
JDK-8192048 NMT: Tracking compiler memory usage of thread's resource area
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- relates to
-
JDK-8204128 NMT might report incorrect numbers for Compiler area
-
- Resolved
-