Benefit from computing String Hash at compile time?

[Artur Biesiadowski]

Osvaldo Doederlein wrote:
> - Some constructors (remarkably for substring and cloning) rely on
> Arrays.copyOfRange(), which implementation is more efficient than any Java
> loop (I guess it's a HotSpot intrinsic with optimization for alignment
> etc.). In that case, using an explicit loop so we can smuggle the hashcode
> calculation inside it, will probably have a measurable disadvantage. But
> this disadvantage is only for construction (and then only for large
> strings); for strings that are ever hashed, the net saving will always be
> still positive.
Especially in case of substring, optimized private constructor is used, 
which just does 3 assignments. With your idea, it would have to iterate 
over all elements. This is quite common operation.

I wonder if there is anything (some Hotspot intrinsic?) preventing quick 
hack on java.lang.String, putting it in bootclasspath/a and measuring 
time of javac few thousands source files, reindexing huge lucene data 
and maybe hsql on some test database. It should at least give a rough 
figure if it changes the speed in any measurable way.

Regards,
Artur Biesiadowski