RFR JDK-8059510 Compact symbol table layout inside shared archive

[Aleksey Shipilev]

Hi Jiangli!

On 10/09/2014 11:51 PM, Jiangli Zhou wrote:
>> Anyhow, running the classloading benchmark from JDK-8053904 on
>> Nashorn-generated class files, using the -Xshare:on in both cases,
>> yields a small degradation:
>>
>>   current: 351 +- 2 ms/op
>>   patched: 357 +- 2 ms/op
>>
>> Therefore, I have to ask: what do we try to gain here?
> 
> Thank you so much for looking into this! The main goal here is for
> memory saving. There are two benefits of the separate compact table. One
> is making the shared table read-only by separating it from the runtime
> table as the runtime symbol table might be rehashed. Making the shared
> table read-only avoids write into the memory region and improves memory
> sharing. The other one is smaller entries in the shared table. The
> reduction was quite big. The original table uses 24-byte entries on
> 64-bit machine and 12-byte entries on 32-bit machine, while the new
> table uses 8-byte for each entry.

I understand why the footprint may be better, but do we have an
observable improvement that justifies doing this? I wouldn't bother if
there was no performance implications: in fact, most footprint changes
we do implicitly improve the performance because of better locality, etc.

But, the test above gives 2% degradation in class loading performance,
and that does not sound as improvement... We seem to trade this in for
better footprint, but optimizing footprint just for the sake of it does
not sound like a good approach to me.

I have to wonder if we should instead invest into optimizing the
SymbolTable footprint instead of patching it up with front-end
compressed map. We can dig up the story about Long front-cache in
java.util.HashMap -- which helped in some narrow cases, but was largely
a big performance and maintainability nuisance. I would not like us to
redo the same in native hash tables.

Thanks,
-Aleksey.