RFR JDK-8059510 Compact symbol table layout inside shared archive

[Aleksey Shipilev]

Hi,

On 10/09/2014 07:04 PM, Gerard Ziemski wrote:
> #1 Re: "SymbolTable::lookup”
> 
>  Symbol* SymbolTable::lookup(int index, const char* name,
>                                int len, unsigned int hash) {
> +  Symbol* s = _shared_table.lookup(name, hash, len);
> +  if (s != NULL) {
> +    return s;
> +  }
> +
>    int count = 0;
>    for (HashtableEntry<Symbol*, mtSymbol>* e = bucket(index); e != NULL;
> e = e->next()) {
>      count++;  // count all entries in this bucket, not just ones with
> same hash
>      if (e->hash() == hash) {
>        Symbol* sym = e->literal();
> 
> a) Do we need to evaluate the lookup time performance, now that some
> entries will have to be looked up in 2 separate tables in
> "SymbolTable::lookup"?

Wait a minute! I think we need to revisit this. The synopsis for the
change is misleading: synopsis talks about the *insides* of shared
archive, and not the actual runtime symbol table.

SymbolTable::lookup is performance-sensitive method, at least during the
warmup/startup when intensive classloading happens.

Doing (potentially) twice as much work there will have an impact on
warmup/startup performance, quite possibly negating the performance wins
from compacting. Not to mention the shared table seems to be an
open-address hashtable -- are we actually guaranteed the consistent
performance there under collisions? Not to mention the further code
complication within our native hash tables.

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?

Thanks,
-Aleksey.