On Feb 3, 2014, at 11:01 PM, Stuart Marks <stuart.ma...@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
