Replacing Unsafe.allocateInstance

Henri Tremblay henri at tremblay.pro
Tue Aug 4 19:14:51 UTC 2015


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?

Thanks,
Henri


On 4 August 2015 at 11:39, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> On 2 Aug 2015, at 09:52, Christoph Engelbert <chris at hazelcast.com> wrote:
>
> > Hey Paul,
> >
> > The assumption of non creating JDK classes without calling constructors
> is not completely right.
> > Seen serialization frameworks that create String instances and
> “injecting” a char[] afterwards however I prefer calling the package
> private constructor to just prevent copying of the char[] (in cases where
> it won’t break the immutability contract like deserialisation)
>
> This is of course playing with fire on many levels and totally unsupported
> :-)
>
> The package private constructor could go away, the internals of String
> could change (e.g. optimise for UTF-8 ) in a manner that is also not global
> (imagine species of String, each with different layouts, char[], byte[]
> UTF-8, String object header fused with an array).
>
> We need frozen arrays:
>
>   http://cr.openjdk.java.net/~jrose/arrays/frozen-array-value-rules.html
>
> Paul.
>
>
>
>
>
>


More information about the jdk9-dev mailing list