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

[Erik Österlund]

Hi Coleen,

On 2020-04-24 16:36, coleen.phillimore at oracle.com wrote:
>
>
> On 4/24/20 10:16 AM, Erik Österlund wrote:
>> 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.
>
> We used to have a lot more special hardcoded layouts but most have 
> been removed. The reason these few classes are hardcoded is because 
> the interpreter generates code using these offsets before 
> JavaClasses::compute_offsets is run.  We tried to get rid of all of 
> them and maybe there's a way to indirectly refer to them in the 
> generated code so we can do so in the future.

Makes sense. If the hardcoded offsets of the few remaining classes ever 
become annoying to a future layout
algorithm, then removing the hardcoding seems like a good option.

Thanks,
/Erik