<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
Hi Andrew, I was on vacation and this isn't a complete answer but
some points.<br>
<br>
<div class="moz-cite-prefix">On 10/9/24 5:00 AM, Andrew Haley wrote:<br>
</div>
<blockquote type="cite" cite="mid:fed8d8ba-a814-448e-a230-b8a5c3e2fabe@littlepinkcloud.com">On
10/9/24 06:53, John Rose wrote:
<br>
<br>
> It looks like the compression needs to be partial, down to
about 32 bits.
<br>
<br>
Yes, that's true. Slightly fewer bits would be nice, for tags.
<br>
<br>
> So it looks like (a) having ALL klass IDs fit in 32 bits, and
(b)
<br>
> having all CONCRETE klass IDs fit into a smaller part of the
same
<br>
> range, would meet all requirements. Doing it right might
require TWO
<br>
> new companion types for Klass*, a compact concrete klass ID,
and a
<br>
> 32-bit klass ID (supertype to compact concrete klass ID). I
think
<br>
> the larger one could be called narrowKlass (current name),
and maybe
<br>
> the narrower concrete ID could be called narrowConcreteKlass
or
<br>
> narrowestKlass or something like that.
<br>
<br>
I see, I think.
<br>
<br>
Simply keeping all of metadata in a single 32-bit range would be
very
<br>
useful. We could have instantiable Klasses in one region, followed
by
<br>
non-instantiable Klasses.
<br>
</blockquote>
<br>
The important aspect of class metaspace area is that it's a fixed
size and this is also its problem. It's not location in the area,
it's that the area is fixed. There's piles of code and math to map
the class metaspace and deal with its interaction with CDS (and
there's also bug <a class="issue-link" data-issue-key="JDK-8340212" href="https://bugs.openjdk.org/browse/JDK-8340212" id="key-val" rel="5139178" style="color: rgb(0, 101, 255); text-decoration: var(--aui-link-decoration); cursor: pointer; outline-style: none; box-shadow: 0 0 0 2px var(--aui-focus); border-radius: 2px; scroll-margin-bottom: 25rem;">JDK-8340212</a>
affecting Lilliput). This idea would add more code to that. Also,
adding more code to metaspace to direct placement location in the
class metaspace is code I don't wish to imagine.<br>
<br>
<blockquote type="cite" cite="mid:fed8d8ba-a814-448e-a230-b8a5c3e2fabe@littlepinkcloud.com">
<br>
> (Because of CDS, and maybe other factors, some compact
concrete
<br>
> klass IDs will actually point to interfaces or abstract
classes. So
<br>
> narrowConcreteKlass suggests a property of its referents that
isn’t
<br>
> exactly true.)
<br>
<br>
> The way I read this is to think about putting, not klass and
<br>
> non-klass, but concrete-klass and non-concrete-klass IDs in
the same
<br>
> range. (By ID I mean a compressed Klass pointer, or
alternatively an
<br>
> index into some sort of special table that we haven’t needed
to
<br>
> invent.)
<br>
<br>
While I've now thought of a way to encode Klass pointers that
doesn't
<br>
need them all to be in the same 32-bit range, it may well be very
<br>
useful in other contexts to ensure that they will be.
<br>
</blockquote>
<br>
I suppose that's good you don't need the interface pointers to be in
the same memory area as the klass pointers. There may be a
performance bug with moving them so we might have to undo part of
this change. The goal was to have the generated classes not be in
class metaspace and interfaces came for the ride. But it was never
a design to have Metaspace pointers in Metaspace be compressed and a
lot of CDS and code throughout the JVM expects to just be able to
use pointers without adjustment.<br>
<br>
<blockquote type="cite" cite="mid:fed8d8ba-a814-448e-a230-b8a5c3e2fabe@littlepinkcloud.com">
<br>
Maybe we could reduce the footprint of Klass instances. Right now,
<br>
though, my invokeinterface prototypes *increase* the size of Klass
<br>
instances, so I really want to have the possibility of using
<br>
compressed metadata pointers.
<br>
</blockquote>
<br>
Increasing the size of Klass instances is painful. Make your new
thing something that Klass points to. It doesn't matter how much
memory you use in non-class metaspace.<br>
<br>
<blockquote type="cite" cite="mid:fed8d8ba-a814-448e-a230-b8a5c3e2fabe@littlepinkcloud.com">
<br>
For what it's worth, I'm relieved that we're not yet making Klass
<br>
pointers a table index. Another chained load in the path of method
<br>
dispatch, at a time when I'm trying to get rid of chained loads,
would
<br>
be a Bad Thing for me.
<br>
<br>
</blockquote>
<br>
Sorry about this Bad Thing but we are investigating exactly how to
do this and not lose performance. We haven't given up on this idea
because of aforementioned piles of code we don't like to maintain,
and the allure of not having the special "Class Metaspace" for each
ClassLoaderData anymore.<br>
<br>
Coleen<br>
<br>
</body>
</html>