@retronym In the new backend (ie bytecode emitter + optimizer, GenBCode + BCodeOpt for short) all uses of Namer's chrs are read-only.

Besides that use, the new backend enters via newTypeName the JVM-level internal name of a bytecode-level type (eg `java/lang/Object` or `[Ljava/lang/String;` ) this in turn is done for interning: the resulting index to chrs follows a one-to-one correspondence with the "bytecode-level type" in question (a BType instance represents one such "bytecode-level type").

In turn, having one-to-one indices allows BType to become a value class (that's part of upcoming commits, not yet merged from http://magarciaepfl.github.io/scala/ )

If not Namers, any other table providing interning would do. The current write-use of Namers (via newTypeName) by the new backend is single-threaded (there's only one typer-dependent thread in all of GenBCode + BCodeOpt, newTypeName is only be invoked from there).

Both GenBCode and BCodeOpt perform concurrent read-only accesses to Namer's chrs.