vitalyd at gmail.com
Sat Feb 1 01:53:24 UTC 2014
One would have to measure of course, but intuitively, it seems like a good
change to reuse the stringbuilder. There's also the issue that the local
stringbuilder before was default-sized, and for large content, it would
generate even more garbage as the underlying array is expanded.
The "temporary short lived allocations are cheap" is, unfortunately, a
semi-myth, or at least somewhat misguided. It's true that individually
they may be cheap, but they have macro effects. The higher the allocation
rate, the more young GCs we get. Every young GC (on hotspot collectors, at
least) is a STW pause. Bringing threads to a safepoint has some cost,
especially if there are many of them on large many-core machines. With
larger heaps these days, young gens tend to be larger as well. When GC
runs, it trashes the cpu caches for the mutators, so when they resume, they
may get cache misses. At each young GC, some objects may get promoted
prematurely to tenured.
So no, I wouldn't say it's quite inexpensive :). When you have no option
but to allocate, it's nice to have collectors that can handle those
necessary allocations well. Otherwise, if it's a perf sensitive area and
avoiding allocations doesn't obfuscate or make the code significantly less
maintainable, it's usually better to avoid allocations.
Just my $.02
Sent from my phone
On Jan 31, 2014 2:06 PM, "Stuart Marks" <stuart.marks at oracle.com> wrote:
> On 1/31/14 10:46 AM, Chris Hegarty wrote:
>> I think your patch can be split into two logical, independent, parts. The
>> first is the use of unsafe to access the String UTF length. The seconds is
>> to reuse, where possible, the existing StringBuilder instances, skipping
>> primitive/object reading/writing where applicable, and general cleanup.
>> Since this is a very sensitive area I would like to consider these
>> separately. To that end, I have taken the changes that are applicable to
>> latter, removed any subjective stylistic changes, and made some additional
>> cleanup improvements.
> I agree with splitting the Unsafe usages so they can be reviewed
> separately. New
> and changed usage of Unsafe will require exacting scrutiny.
> In general, the cleanups and refactorings look fine.
> I have a question about the change to reuse StringBuilder instances. This
> replaces freshly allocated StringBuilders stored in local variables with
> reuse of a StringBuilder stored in a field of BlockDataInputStream, which
> in turn is stored in a field of ObjectInputStream. Thus, instead of
> creating of lots of temporaries that become gc-eligible very quickly, this
> creates a single long-lived object whose size is the high-water mark of the
> longest string that's been read. The change does reduce allocation
> pressure, but the point of generational GC is to make allocation and
> collection of temporaries quite inexpensive. Is this the right tradeoff?
More information about the core-libs-dev