lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: svn commit: r1141510 - /lucene/dev/trunk/modules/facet/src/java/org/apache/lucene/util/
Date Fri, 01 Jul 2011 13:04:49 GMT
On Fri, Jul 1, 2011 at 1:47 AM, Simon Willnauer
<> wrote:

> Mike I think we should do that but the real issue here is what if
> somebody comes up with any arbitrary method in the future claiming its
> slow we back out and use the "we think safe way" what if it is
> actually the other way around and copyOf is optimized by new VMs and
> the copyarray is slightly slower.

I think we take it case by case?  We do need to be careful when using
low level ops in Java.

In this specific case, we have been almost burned already by
Arrays.copyOf, and never by System.arraycopy (that I'm aware of), so
we should not cutover until we have some confidence that burning will
not occur.  Other cases will be different, but this one has enough
history that the bias seems clear.

> I just want
> to prevent the "we should not do this" it might be a problem in the
> big picture while the microbenchmark doesn't show a difference. At
> some point we have to rely on the JVM.

I agree, but generally the burden of proof is on the "new one".  Just
because we can use Java 1.6 code now doesn't mean we should blindly
cutover to new stuff.

System.arraycopy is tried & true and we've never hit a perf issue with
it, in my memory.

> Even if we benchmark on all OS with various JVMs we can't prevent jvm
> bug based perf hits.

Right, nothing is perfect here; this is just about mitigating risk.
We were lucky to have tracked down this slowdown down last time, I
think only because Robert was using a -client JVM at the time?

> While there was no bug reported for primitives
> here we don't have to be afraid of it either. I don't think its saver
> to use arraycopy at all its just a level of indirection safer but
> makes development more of a pain IMO.

Yes it's a slight hassle (2 extra lines), but if this mitigates risk,
it's worth it.

That said, if we can convince ourselves that in the primitives only
case, Arrays.copyOf has very little risk, then I'm OK w/ using it for
those cases.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message