Replacing Unsafe.allocateInstance

[Christoph Engelbert]

Such optimizations would be absolutely awesome but yeah questions is the complexity.

About where you can find such kind of optimizations? At least in Hazelcast since we have our own high performance UTF8 encoder / decoder. To eventually create the String we either call String package private constructors or use other tricks (in the past) like sun.misc.JavaLangAccess::newStringUnsafe just to prevent the char[] copy in almost all cases. For a system that needs low jitter rate and predictable throughput any kind of additional allocation hurts.

And yeah I know that Java 9 String memory consumption optimization will give us a hard time. I guess somebody will already look into it. In the worst case we always have a fallback to call default constructors but we really don’t want to do that :) 


> Am 04.08.2015 um 21:49 schrieb Paul Sandoz <paul.sandoz at oracle.com>:
> 
> 
> On 4 Aug 2015, at 21:14, Henri Tremblay <henri at tremblay.pro> wrote:
> 
>> Hi,
>> 
>> I might have missed something but the purpose of injecting the char[] is to prevent copying it. But frozen arrays seem to require a copy to get the frozen version.
>> 
>> I would much prefer the JVM to be able to guess that an array will in fact never be modified and so could be used without copying (A copy can be made if needed afterwards). Or maybe just be able to annotate @Constant
>> 
>> Is there something I'm not understanding?
>> 
> 
> I was hoping in certain cases that the compiler would be able to work out that the frozen array does not escape and can therefore optimise away the copy. Perhaps i am being naive on this point :-) I don’t know how difficult/fragile that would be in practice to detect.
> 
> Paul.