Implementing Towards Better PEP/Serialization

[Brian Goetz]

>
> Using the method handles and field setters, the internal library has 
> bypassed two autoboxed Floats and the creation/destruction of the 
> Object[]. For a JSON parser, I wouldn't be too worried about this as
> text parsing is already expensive and the overhead wouldn't add much, 
> however, in a binary serialization this overhead could add up. In 
> older Java versions I've observed this type of autoboxing in 
> serialization put huge pressure on the garbage collector.
>
> Before getting stuck on this issue. Should I care? Will the later Java 
> compiler versions eventually see that the float values don't need to 
> be autoboxed and the Object[] could be put on the stack?

I wouldn't get stuck on it.  If you're going through reflection, there 
are plenty of other costs too; if you're going through method handles, 
there's a lot more that the JIT can do to elide the boxing costs (and 
more when Valhalla comes online.)

> If this PEP library is to be nice and adhere to not setting private 
> final fields directly and use the public constructor, I'm left 
> wondering if there's any way to improve the performance of the first 
> solution without waiting for the optimizer to kick in?
>
> The only potential solution I've thought of so far is to get the front 
> end serializer to create a MethodHandle that looks like:
>
> constructor( input.readFloat(), input.readFloat() );
>
> The problem with this is that the values must be serialized in the 
> correct order. This would potentially be ok for some binary formats.

MHs can handle things like this, though getting the sequencing right is 
tricky (there's no explicit sequencing combinator.)  But this can be done.