Call for Discussion: New Project: Lilliput

[Roman Kennke]

Hi Remi,


>> 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 
possibilities.

> 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 
starting point!

Would you like to be included as initial project committer?

Thanks Remi!
Roman