It's hard to understand what these very long threads concluded if one has
not been on it all along.
So:
1. JIT Optimized arraycopy disabled now
2. When turned on, gc_safe and will use object remembering barrier
3. Jit=>gc interface will add gc::does_it_support_object_remembering()
4. chunk-wise optimized barrier update unnecessary till someone ever
uses a long enough Java array :-)
??
On 1/11/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 1/11/07, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>
> Actually unless there is some compelling real app data it might make
sense
> to hold off attempting any "chunk" optimization. I think Robin posted
> some
> numbers indicating gc latency for a big array copy is probably no big
deal
> right now. Also, adding optimizations that don't help workloads we need
> to
> focus on can clutter the code, make debugging harder and reduce
> reliability.
>
Yes, I also think so. If memory copying becomes too long it can indicate
that there is some swapping activity. If this kernel operation is done
with
higher priority then normal program execution we have a delay for the
whole
system, regardless of number of CPUs. At least I see such a behaviour
every
day when my antivirus program run it's scans :)
--
Mikhail Fursov
