RFR: 8241825: Make compressed oops and compressed class pointers independent on x86_64

Fri Apr 24 14:16:00 UTC 2020

Hi Frederic,

Thanks for reviewing this.

On 2020-04-24 15:28, Frederic Parain wrote:
> Hi Erik,
>
> Why did you removed the code handling classes with hard coded layouts?
> This code was there to provide the freedom to play with layout algorithms
> without having to deal with these special cases. Without this code, any
> modification is now constrained by these special classes.

Good question. Since I started using the klass gap for fields, even when 
compressed oops is off, dealing with the
hardcoded offsets and layouts really became quite awkward, to the extent 
that I started wondering why do we even have
special layouts for these things anyway. I don't like special things. 
Treating it like any other object seemed far
easier, than matching the special special hardcoded layouts with the 
hardcoded offsets.

I wouldn't say that the whole layout algorithm is constrained by the 
fact that there are hardcoded offsets.
I would say that it's just a matter of whoever changes the layout 
algorithms such that the hardcoded offsets
are no longer the same, is just gonna have to update the offset to 
whatever the correct offsets are with the
new algorithm. And if you look at the classes where we actually do 
hardcode the offsets, they are rather vanilla
with relatively few ways you could change the layout other than changing 
it around for the sake of it. Especially
primitive box objects. My fantasy is quite limited how we expect a new 
layout algorithm is gonna do anything else
there really.

Philosophically, I really think it is up to the person hardcoding an 
offset to know what the offset is going to
be, ratherthan having completely different special (and worse) layouts 
produced for certain objects, just to
satisfy the expectations of the hardcoded offsets.Especially if the 
result is pretty bad memory waste in for
example Integer box objects, that can be quite plentyful in an application.

The code to figure out the right offsets if a very small amount of code, 
compared to the rather large amount of
code to create special layouts and syncing the special hardcoded layout 
code with the hardcoded offsets. That
is why my patch has a net negative amount of code.

Philosophically I also don't like having "special" layouts because we 
don't trust our ability to hardcode some
offset to the right value. Almost all "special" things are bad and 
create unnecessary complications, and hence
should have very good motivation for being allowed to be special. In 
this case, I really could not see any reason
why these layouts would be special, unless it was somehow super hard to 
figure out what the hardcoded offsets would be.
But for the classes we currently need hardcoded offsets, the 
calculations are trivial. So I don't think there is
enough motivation to have special (bad) layouts for these objects for 
that reason. It only makes things harder than
it needs to be, and makes the layout worse.

> And I’d prefer to keep the dispatch in FieldLayoutBuilder::build_layout()
> because we have more cases to handle there for the Valhalla project (the
> layout algorithm for inline types is different than the one in
> compute_regular_layout()).

Okay. There was no need for the dispatching any more since there was 
only the normal layout and nothing
else. But I can put that code back into the compute_regular_layout() 
function if that makes it easier for you
in Valhalla, and have FieldLayoutBuilder::build_layout() just call that 
function. Will update in the next webrev.

Thanks,
/Erik

> Regards,
>
> Fred
>
>
>> On Apr 24, 2020, at 04:17, Erik Österlund <erik.osterlund at oracle.com> wrote:
>>
>> Hi,
>>
>> Today, the use of compressed class pointers assumes the use of compressed oops.
>> This patch loosens up the relationship between compressed oops and compressed
>> class pointers, so that compressed class pointers can be used without compressed
>> oops. This benefits for example ZGC that wants compressed class pointers, but
>> not compressed oops, effectively giving ZGC 4 bytes smaller objects.
>>
>> Much of the complexity of the change is that r12 used to be used by compressed
>> class pointers as some kind of semi-fast temp register that one would restore
>> to the compressed oops heap base (or zero). That made it effectively a slightly
>> optimized spilling mechanism used to find a temp register. I replaced that
>> mechanism with a plain old normal temp register that you pass in as a parameter.
>> The bad news is that I had to find available temp registers in a lot of places.
>> The good news is that almost always were there temp registers available for free,
>> and hence the new temp register is even faster than the old optimized spilling
>> mechanism. Because we almost never need any spilling at all in the contexts where
>> this is used.
>>
>> Since I want the 4 new bytes to actually make objects smaller, I poked the new
>> layout code a bit so that the klass gap is made available for fields. That used
>> to be made available only with compressed oops enabled, due to restrictions in
>> the layout code. Our new layout code does not have such restrictions, and so
>> I will make the 4 bytes available for fields when the new layout code is used
>> and compressed class pointers are used.
>>
>> Now I'm only fixing this for HotSpot x86_64. Ideally the use of compressed oops
>> and compressed class pointers should not be entangled in other platforms and
>> Graal. But that is beyond the scope of this change, and I will let them behave
>> the way that they used to, to be potentially fixed later.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8241825
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8241825/webrev.00/
>>
>> Testing:
>> hs-tier1-7
>>
>> Thanks,
>> /Erik