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 <mike.fursov@gmail.com> wrote:
>
> On 1/11/07, Weldon Washburn <weldonwjw@gmail.com> 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
>
>