ObjectIn/OutputStream improvements

[Paul Sandoz]

On Feb 3, 2014, at 11:01 PM, Stuart Marks <stuart.marks at oracle.com> wrote:

> Nobody took the bait on this yet? :-)
> 
> Certainly there's a lot of semi-myth on this topic, on both sides. Here's my source of mythology (or urban legend, as one might have it):
> 
> http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html
> 
> My concern here is not so much about leaking of the StringBuilder held in a field, as Chris seemed to be responding to. I'd expect the ObjectInputStream to be GC'd at some point along with any StringBuilders it contains references to.
> 
> I'm more concerned about defeating any optimizations that might occur if local variables are converted to fields. The article referenced above mentions escape analysis and possible stack allocation of locally-created objects. Offhand I don't know if stack allocation occurs for any of the builders in ObjectInputStream, but it certainly cannot occur if references are stored in fields.
> 

The caching of the StringBuffer seems reasonable point fix. (If one is worried about field access retain/expand the original method signatures so field access is hoisted outside of the loops.)

However, if we want to focus on performance i think it better to change the UTF decoding algorithm to target small'ish ASCII strings (size < CHAR_BUF_SIZE) thereby avoiding the use of StringBuilder for presumed common cases. (IIRC a similar approach in a different area was proposed by Sherman for converting strings to lower/upper cases.)

I think that would be a better way to spend our performance investigation budget. Thus, it might be better to remove the StringBuilder field from this patch and submit another one focusing on UTF decoding; the other changes in the patch look good.

Paul.

> It would good if there were some evidence we could discuss instead of myths and urban legends. :-) Perhaps the original poster (Robert Stupp) can rerun some benchmarks with and without the conversion from locals to fields. (Earlier in the thread he posted some significant performance improvements, but my suspicion is that most of that improvement came from the conversion to use Unsafe.)
> 
> I'm mindful that this may require a lot of effort. I think it would take a fair bit of work to come up with a benchmark that shows any difference between the two cases. I'm also mindful that one's intuition is often wrong.
> 
> s'marks