Call for Discussion: New Project: Lilliput
rkennke at redhat.com
Tue Mar 9 18:10:26 UTC 2021
>> Please let me know what you think!
> Hi Roman,
> you can also reduce the size of the header for certain kind of classes, by example for a record, you know that the field are truly final so you can avoid to compute the hashCode and use the fields to calculate the identity hashCode the same way Valhalla does for the primitive classes.
> for a primitive class, when they are on the heap, again, you can avoid the identity hashCode (and also the lock bits, but that's less interresting).
Right. That is a great idea! It is interesting to note that we don't
ever need a i-hash for most objects. Some experiments have shown that in
most workloads, fewer than 1% of all objects are ever i-hashed. And of
those 1% it is questionable how many even survive until the GC moves
them for the first time. Which means we can recompute i-hash until that
first move happens and avoid storing the i-hash for *many* objects this
way. Then, as you said, we can avoid even more by considering a number
of well-known types. Etc. As mentioned before, we have a huge array of
> An a question, for the class pointer, using compact class pointer is not enough to have them using 32 bits instead of 64 bits.
> For me, having the hashCode optional and having a 32 bits class pointer seems to be a good way to free 64 bits per header.
I am not sure what the question is :-) But yes, that seems like a good
Would you like to be included as initial project committer?
More information about the discuss