Bug ID: JDK-7072317 move metadata from CodeCache

Type: Enhancement
Component: hotspot
Sub-Component: compiler
Affected Version: hs22,9,10

Priority: P3
Status: Open
Resolution: Unresolved
OS: generic
CPU: generic

Submitted: 2011-07-28
Updated: 2024-11-08

Other
tbdUnresolved

The meta data vs code ratio is 1:1 in the product bits for sparc.  The 2:1 ratio I quoted is for x86 code in debug mode where the code is smaller and we keep extra meta data which skews the results.  In product mode x86 is about 1.4:1. It's not as bad as 2:1 but there's still quite a bit of meta data in between the chunks of code.

Tom

We tried different prototypes which was an amount of non-code separated from nmethod. Our main goal is to have as less non-code mixed with code as possible. One of things complicating a lot is the C++ hierarchy of CodeBlob classes. We think we should get rid of it where it is possible. CodeCache has its own memory management. They should be POD for the better.
18-01-2024
The layout of nmethods goes back to the earliest days of HotSpot. In the old days, it was less common to make a distinction between memory regions with code and those with data. Today and in the future, there may be firmer distinction, based on the desire to avoid accidental code patching, and/or accidental execution of data as code. If we need to set special execute permissions in the code cache, then it might be convenient to move nmethod data into a distinct area of memory. In the old days, the system malloc routine did not scale very well, and our GC scaled better, so it gave more controllable scaling and performance to put metadata into permgen. That was another reason to put it there. Nowadays, malloc performance seems to be a solved problem. Still, the VM prefers, when it can, to manage its own dynamic storage allocation, simply because that gives it more control over certain boundary conditions: What happens if a sys-op wants to find out how much memory we are using? What happens if the VM finds it is running low on memory? If there is less malloc, there are easier answers to those questions. In the old days, we had something called “permgen” which was an area of the VM heap, and we put everything in there, including symbols and classfile metadata and n-methods. Those items were managed by the GC alongside Java user data. Nowadays we make a firm three-way distinction between the Java heap and metadata and code cache. When n-methods were managed by the GC there was an obvious benefit to having fewer larger blocks, so we “sewed together” all the parts in one long object, managed in permgen. It might make sense, today, to put some (or all) non-code items into metaspace. BTW, many code parts of an n-method are editable code. If we ever wish to segregate editable (RWX) from non-editable (R-X or even --X) code, we surely need to find a different place to store those mutable code bits. This is a distinct reason to think about breaking up n-methods across memory regions. After (and if) we break metadata out from n-methods, we should think about breaking out mutable code sections, especially the “stubs” at the end, and maybe even call sites. Maybe the editable part of an n-method could go within 2Gb (long branch) of the main n-method body, but in a RWX segment of memory. Well, we can have a separate discussion of that, if we move metadata out first. On balance, I think it makes sense to think about breaking up n-methods, moving metadata into metaspace or (not my preference) the malloc heap. But it’s not an easy decision. One big issue: When you flush an nmethod, how do you free its metadata resources? Maybe you used malloc: then it’s easy. But if it’s metaspace, you need separately flushable metadata sections for each n-method. Maybe that’s OK… We do support this, and it might scale OK, since n-methods tend to be large. We could attempt to place n-method metadata into the metadata of the class declaring the top-level method, but when it must be deoptimized and discarded, you have a storage leak. That’s not attractive. I think we need a distinct metadata area for each n-method. Luckily, this is something we know how to do, and even have multiple allocations in each such area. Besides tidiness (and perhaps enhanced security) from putting only code in R-X segments, there is another advantage: The average distance between n-methods will be cut in half (assuming a current 50/50 split of code and metadata). This will help some platforms that would greatly prefer to use shorter branches, even for call sites. There is yet another advantage for Project Leyden: We expect to place both code and additional metadata resources into CDS files in the future. If the resources are organized separately (according to kind, code vs. data), it will be easier to manage them in the CDS file. We know how to put the whole code cache image into the CDS file, but if we ever wish to compress some parts of the CDS file, it will surely be easier if the code part (uncompressed) is on a completely different set of pages than the metadata part (compressible, depending on usage).
18-01-2024
If we need to keep oops and other pointers near code (for patching, for example) we can move them to Constant section (may be rename it) of code.
18-01-2024
This may help to Leyden project where we can keep AOT code metadata in CDS archive.
18-01-2024
It is still important but not urgent. Future JIT is also affected.
05-03-2018
We should also re-evaluate the default size of the code heap segments according to the min/average/max size of nmethods (see JDK-8034052).
31-01-2017

Blocks :	JDK-8152664 - Support non-continuous CodeBlobs in HotSpot
Duplicate :	JDK-8034052 - Investigate using different CodeCacheSegmentSizes in segmented code cache
Relates :	JDK-8324181 - enhance compressed streams
Relates :	JDK-8331087 - Move immutable nmethod data from CodeCache
Relates :	JDK-8343789 - Move mutable nmethod data out of CodeCache
Relates :	JDK-8324175 - [premain] Investigate compression/decompression of CDS archive file