You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Xiao-Feng Li <xi...@gmail.com> on 2007/01/07 06:59:19 UTC
[DRLVM][JIT] write barrier broken by new jit opts?
Hi, I found write barrier in DRLVM can't catch all reference fields
updates, and the problem is identified to be caused by new jit opts
that do not observe the write barrier invariant for fields updates.
For example, JIT may generate code to copy consecutive fields of an
object without invoking write barrier. In order to revive the write
barrier functionality while not sacrificing the opt performance, I'd
suggest to introduce an object remember write barrier which will be
invoked after the object is copied. So the JIT doesn't need to insert
barrier for each field store. GC has an interface
gc_heap_wrote_object(p_obj) for this case. I think it's ok to insert
only the runtime native call at first. Then later we can consider to
inline the object remembering barrier as well as the slot remembering
barrier.
Thanks,
xiaofeng
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x25A day of Apache Harmony Weldon Washburn wrote:
> On 10 Jan 2007 12:05:57 +0600, Egor Pasko <eg...@gmail.com> wrote:
> >
> > On the 0x259 day of Apache Harmony Weldon Washburn wrote:
> > > On 1/9/07, Robin Garner <ro...@anu.edu.au> wrote:
> > > >
> > > > > On 09 Jan 2007 16:54:03 +0600, Egor Pasko <eg...@gmail.com>
> > wrote:
> > > > >>
> > > > >> On the 0x258 day of Apache Harmony Weldon Washburn wrote:
>
>
>
>
> > [snip]
>
>
>
> > >
> > > > Off the top of my head, if the barrier is called before any data is
> > copied
> > > > I think the arraycopy code is GC-safe, provided another barrier call
> > is
> > > > made after the GC and before the next pointer write. It's probably
> > better
> > > > to make the arraycopy code uninterruptible.
> > >
> > >
> > > Yes, I agree it's probably better to make the arraycopy code
> > > uninterrutible. The only caution is the impact on GC latency. Um, does
> > > this require a new additional API or can we simply use what is existing?
> >
> > well, you are probably saying that "optimized version of arraycopy
> > should be uninterruptable". In general, arraycopy can thow exceptions
> > => that should be a safepoint.
>
>
> Actually all the exceptions can be pre-screened and, if necessary, thrown
> before the copy loop.
no, API spec says:
if any actual component of the source array from position srcPos
through srcPos+length-1 cannot be converted to the component type
of the destination array by assignment conversion, an
ArrayStoreException is thrown.
we optimize arraycopy only for primitive types and for cases when
declared src component class is a subclass for the dst component
type. See JavaByteCodeTranslator.cpp:2883
(JavaByteCodeTranslator::arraycopyOptimizable).
> Thus the copy loop can proceed w/o worry about exceptions. Below
> are comments in the native method helper version (vm_arrays.h).
> Does the JIT do something similar to the code in
> vm_arrays.cpp::array_copy() ?
>
>
> VM_RT_CHAR_ARRAYCOPY_NO_EXC=950,
>
> // Arguments:
>
> // - Object reference for the source array. Must be non-null and refer to an
> array
>
> // of 16 bit chars.
>
> // - int32 containing the starting index of the source array to copy.
>
> // - Object reference for the destination array. Must be non-null and refer
> to an array
>
> // of 16 bit chars.
>
> // - int32 containing the starting index of the destination array to copy
> into.
>
> // - int32 containing the number of 16 bit chars to copy.
>
> // Return value: none.
>
> //
>
> // This runtime helper function provides a specialized implementation for
> System.arraycopy
>
> // for the common case where the elements of the arrays are
>
> // 16 bit characters and the array references are both non-null. The JIT
> must guarantee
>
> // that no exceptions will need to be thrown. That is, both array references
> are non-null,
>
> // the types match (and are both arrays of 16 bit characters),
>
> // and the starting indexes and length are such that the copying will only
> access
>
> // data in the bounds of the arrays.
> Looking at
>
> > Anyway, GC latency is a good note to mention here. Ideally we could
> > separate an array in parts for copying and put safepoints in between
> > the parts (that would require an extra JIT->GC interface pecularity to
> > tell which part of the array the barrier corresponds to). Something
> > tells me (my gut?) that this "optimization" would not give anything in
> > real situations :)
> >
> > > My gut feel is that scalars don't generally have enough pointers to make
> > > > the object remembering barrier worthwhile.
> > >
> > >
> > > That's my hunch also. However, if someone wants to spend time analyzing
> > > enterprise workloads to discover if there is any cheese down that
> > tunnel, I
> > > won't get in the way.
> >
> > Anyway, these days object copying/moving is NOT performed by code
> > emitted by Jitrino, and this kind of behaviour is not going to be
> > implemented in the nearest future. Thus, it cannot be the root cause
> > of the original bug we are discussing. The only problem left is
> > arraycopy (recent changes in arraycopy impl makes me more confident in
> > this version)
>
>
>
>
> --
> > Egor Pasko
> >
> >
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
--
Egor Pasko
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Weldon Washburn <we...@gmail.com>.
On 10 Jan 2007 12:05:57 +0600, Egor Pasko <eg...@gmail.com> wrote:
>
> On the 0x259 day of Apache Harmony Weldon Washburn wrote:
> > On 1/9/07, Robin Garner <ro...@anu.edu.au> wrote:
> > >
> > > > On 09 Jan 2007 16:54:03 +0600, Egor Pasko <eg...@gmail.com>
> wrote:
> > > >>
> > > >> On the 0x258 day of Apache Harmony Weldon Washburn wrote:
> [snip]
> >
> > > Off the top of my head, if the barrier is called before any data is
> copied
> > > I think the arraycopy code is GC-safe, provided another barrier call
> is
> > > made after the GC and before the next pointer write. It's probably
> better
> > > to make the arraycopy code uninterruptible.
> >
> >
> > Yes, I agree it's probably better to make the arraycopy code
> > uninterrutible. The only caution is the impact on GC latency. Um, does
> > this require a new additional API or can we simply use what is existing?
>
> well, you are probably saying that "optimized version of arraycopy
> should be uninterruptable". In general, arraycopy can thow exceptions
> => that should be a safepoint.
Actually all the exceptions can be pre-screened and, if necessary, thrown
before the copy loop. Thus the copy loop can proceed w/o worry about
exceptions. Below are comments in the native method helper version
(vm_arrays.h). Does the JIT do something similar to the code in
vm_arrays.cpp::array_copy() ?
VM_RT_CHAR_ARRAYCOPY_NO_EXC=950,
// Arguments:
// - Object reference for the source array. Must be non-null and refer to an
array
// of 16 bit chars.
// - int32 containing the starting index of the source array to copy.
// - Object reference for the destination array. Must be non-null and refer
to an array
// of 16 bit chars.
// - int32 containing the starting index of the destination array to copy
into.
// - int32 containing the number of 16 bit chars to copy.
// Return value: none.
//
// This runtime helper function provides a specialized implementation for
System.arraycopy
// for the common case where the elements of the arrays are
// 16 bit characters and the array references are both non-null. The JIT
must guarantee
// that no exceptions will need to be thrown. That is, both array references
are non-null,
// the types match (and are both arrays of 16 bit characters),
// and the starting indexes and length are such that the copying will only
access
// data in the bounds of the arrays.
Looking at
> Anyway, GC latency is a good note to mention here. Ideally we could
> separate an array in parts for copying and put safepoints in between
> the parts (that would require an extra JIT->GC interface pecularity to
> tell which part of the array the barrier corresponds to). Something
> tells me (my gut?) that this "optimization" would not give anything in
> real situations :)
>
> > My gut feel is that scalars don't generally have enough pointers to make
> > > the object remembering barrier worthwhile.
> >
> >
> > That's my hunch also. However, if someone wants to spend time analyzing
> > enterprise workloads to discover if there is any cheese down that
> tunnel, I
> > won't get in the way.
>
> Anyway, these days object copying/moving is NOT performed by code
> emitted by Jitrino, and this kind of behaviour is not going to be
> implemented in the nearest future. Thus, it cannot be the root cause
> of the original bug we are discussing. The only problem left is
> arraycopy (recent changes in arraycopy impl makes me more confident in
> this version)
--
> Egor Pasko
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x25B day of Apache Harmony Mikhail Fursov wrote:
> On 1/11/07, Alexey Varlamov <al...@gmail.com> wrote:
> >
> > Hmm, AFAIU "optimized" arraycopy has no GC specifics. Moreover it is,
> > like API magics, codegen-specific and I do not quite see how it can be
> > expressed in vmmagics...
>
>
> One of the GC specific issues is WB :) But we can have several options how
> optimize array copy in JIT: make a loop and remove call, use special CPU
> instructions...
> After some thoughts I agree that VM magic is not the best candidate here and
> additional WB method to report several entries at once can be a better
> solution.
Yes, that pretty looks like JIT internals (a special inst for rep
mov).
The problem with current impl is that it is not easy to read. Writing
the most of JIT-arraycopy in Java would help. So, to be elegant at the
maximum we could make a "JIT-magic-in-Java" -- a simple method that
does all the exceptions & slowpath tricks in Java leaving the fastpath
to JIT. This JIT-magic can be resolved and inlined in translator.
--
Egor Pasko
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Mikhail Fursov <mi...@gmail.com>.
On 1/11/07, Alexey Varlamov <al...@gmail.com> wrote:
>
> Hmm, AFAIU "optimized" arraycopy has no GC specifics. Moreover it is,
> like API magics, codegen-specific and I do not quite see how it can be
> expressed in vmmagics...
One of the GC specific issues is WB :) But we can have several options how
optimize array copy in JIT: make a loop and remove call, use special CPU
instructions...
After some thoughts I agree that VM magic is not the best candidate here and
additional WB method to report several entries at once can be a better
solution.
--
Mikhail Fursov
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Alexey Varlamov <al...@gmail.com>.
11 Jan 2007 17:26:13 +0600, Egor Pasko <eg...@gmail.com>:
> On the 0x25B day of Apache Harmony Mikhail Fursov wrote:
> > IMO disabling GC for inlined arraycopy IR region is a good idea and it
> > should work.
> > Other proposals from me here:
> > 1) Why to report each object separately? May be calling wb helper once with
> > array of objects could be better?
>
> AFAIR, Robin proposed to report array updates by chunks, which is a
> good idea for fast thread suspension. WB once for small arrays, wb
> several times for large arrays.
>
> > 2) Another solution could be if GC will provide a helper written with
> > vmmagic for array copying by itself?
>
> yes, that makes it a) more elegant/supportable than JIT magic b) has
> GC specifics in GC. But on the other hand we should limit this vmmagic
> functionality by the "optimized" part of arraycopy. All other
> exception throwing pecularities are more natural to implement on JIT
> or VM side.
Hmm, AFAIU "optimized" arraycopy has no GC specifics. Moreover it is,
like API magics, codegen-specific and I do not quite see how it can be
expressed in vmmagics...
--
Alexey
>
> --
> Egor Pasko
>
>
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x25C day of Apache Harmony Rana Dasgupta wrote:
> It's hard to understand what these very long threads concluded if one has
> not been on it all along.
Rana,
writing thread summaries is a good practice, thank you for this one.
> So:
> 1. JIT Optimized arraycopy disabled now
to be precise, it is enabled, but incorrectly when WBs are enabled.
> 2. When turned on, gc_safe and will use object remembering barrier
yes
curently the question left is how to implement it in "the right" way
(VM/GC magic, JIT magic, JIT-Java-code-with-JIT-magic) but we can
leave the current implementation for a while and decide later
> 3. Jit=>gc interface will add
> gc::does_it_support_object_remembering()
yes
> 4. chunk-wise optimized barrier update unnecessary till someone ever
> uses a long enough Java array :-)
yes
--
Egor Pasko
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Rana Dasgupta <rd...@gmail.com>.
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 <mi...@gmail.com> wrote:
>
> On 1/11/07, Weldon Washburn <we...@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
>
>
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Mikhail Fursov <mi...@gmail.com>.
On 1/11/07, Weldon Washburn <we...@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
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Weldon Washburn <we...@gmail.com>.
On 1/11/07, Mikhail Fursov <mi...@gmail.com> wrote:
>
> On 11 Jan 2007 17:26:13 +0600, Egor Pasko <eg...@gmail.com> wrote:
> >
> > On the 0x25B day of Apache Harmony Mikhail Fursov wrote:
> > > IMO disabling GC for inlined arraycopy IR region is a good idea and it
> > > should work.
> > > Other proposals from me here:
> > > 1) Why to report each object separately? May be calling wb helper once
> > with
> > > array of objects could be better?
> >
> > AFAIR, Robin proposed to report array updates by chunks, which is a
> > good idea for fast thread suspension. WB once for small arrays, wb
> > several times for large arrays.
>
>
> The issues that I did not understand from Robin's post are:
> 1) Why do we need chunks?
> 2) What does object_write_barrier(dest) report in algorithm with chunks?
>
> > 2) Another solution could be if GC will provide a helper written with
> > > vmmagic for array copying by itself?
> >
> > yes, that makes it a) more elegant/supportable than JIT magic b) has
> > GC specifics in GC. But on the other hand we should limit this vmmagic
> > functionality by the "optimized" part of arraycopy. All other
> > exception throwing pecularities are more natural to implement on JIT
> > or VM side.
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.
Dividing arraycopy into different parts implies additional layer in GC-JIT
> communication in this case. I see no reasons why not to do nullpointer or
> bounds check in vmmagic helper.
>
> --
> > Egor Pasko
> >
> >
>
>
> --
> Mikhail Fursov
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Robin Garner <ro...@anu.edu.au>.
> On the 0x25B day of Apache Harmony Mikhail Fursov wrote:
>> On 11 Jan 2007 17:26:13 +0600, Egor Pasko <eg...@gmail.com> wrote:
>> >
>> > On the 0x25B day of Apache Harmony Mikhail Fursov wrote:
>> > > IMO disabling GC for inlined arraycopy IR region is a good idea and
>> it
>> > > should work.
>> > > Other proposals from me here:
>> > > 1) Why to report each object separately? May be calling wb helper
>> once
>> > with
>> > > array of objects could be better?
>> >
>> > AFAIR, Robin proposed to report array updates by chunks, which is a
>> > good idea for fast thread suspension. WB once for small arrays, wb
>> > several times for large arrays.
>>
>>
>> The issues that I did not understand from Robin's post are:
>> 1) Why do we need chunks?
>
> 1. arraycopy is uninterruptable
> 2. big arrays may take long to copy
>
> => the thread doing a big array copying cannot be suspended for a long
> time (which is a performance problem)
>
> first solution that came into our mind is to copy by uninterruptable
> chunks, WB after each chunk and check for suspension flag after each
> chunk.
>
>> 2) What does object_write_barrier(dest) report in algorithm with chunks?
>
> it should report the chunk update. Of course, it should have have more
> parameters to outline the exact chunk that has been updated.
The barrier that has been measured in the literature is simply an object
remembering barrier. The only information in it is the address of the
object. At (nursery) GC time, the GC uses the object pointer as a root,
and scans the array as a source of pointers into the nursery.
This is an optimization because
a) scanning arrays is fast
while (++slot < array_bound)
if (*slot > NURSERY_BOUNDARY)
*slot = evacuate(*slot);
hardware prefetch kicks in and even large arrays are quickly scanned.
b) The barrier is fast.
if (!atomic_test_and_set(array_header->remembered_bit))
*array_remset++ = array_address
While a barrier that saved a sub-range of an array might save some time
during a nursery GC, it would be far more expensive at runtime,
particularly if you use a structured remset that allows multiple
overlapping writes to the same array to be coalesced.
To put it another way, I _can_ imagine workloads for which an array-range
remembering barrier might be faster, but I don't know of any right now.
It might be worthwhile to remember slots for small arrays, eg < 8
elements, and use object remembering for the larger ones.
>> > 2) Another solution could be if GC will provide a helper written with
>> > > vmmagic for array copying by itself?
>> >
>> > yes, that makes it a) more elegant/supportable than JIT magic b) has
>> > GC specifics in GC. But on the other hand we should limit this vmmagic
>> > functionality by the "optimized" part of arraycopy. All other
>> > exception throwing pecularities are more natural to implement on JIT
>> > or VM side.
>>
>>
>> Dividing arraycopy into different parts implies additional layer in
>> GC-JIT
>> communication in this case. I see no reasons why not to do nullpointer
>> or
>> bounds check in vmmagic helper.
>
> and type checks? IMHO, these checks are not GC-ish. It has to be one
> more contract if we want to tickle with this performance issue. The
> question is will it be a new CG-JIT contract or GC-VM contract (to
> throw exceptions). I see no much difference here. Need to decide.
FWIW, JikesRVM makes a fast-syscall to the OS memcpy() function.
I think it would be very hard to beat an inlined barrier followed by an
out-of-line call to memcpy or a hand-coded equivalent.
> --
> Egor Pasko
>
>
cheers,
Robin
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x25B day of Apache Harmony Mikhail Fursov wrote:
> On 11 Jan 2007 17:26:13 +0600, Egor Pasko <eg...@gmail.com> wrote:
> >
> > On the 0x25B day of Apache Harmony Mikhail Fursov wrote:
> > > IMO disabling GC for inlined arraycopy IR region is a good idea and it
> > > should work.
> > > Other proposals from me here:
> > > 1) Why to report each object separately? May be calling wb helper once
> > with
> > > array of objects could be better?
> >
> > AFAIR, Robin proposed to report array updates by chunks, which is a
> > good idea for fast thread suspension. WB once for small arrays, wb
> > several times for large arrays.
>
>
> The issues that I did not understand from Robin's post are:
> 1) Why do we need chunks?
1. arraycopy is uninterruptable
2. big arrays may take long to copy
=> the thread doing a big array copying cannot be suspended for a long
time (which is a performance problem)
first solution that came into our mind is to copy by uninterruptable
chunks, WB after each chunk and check for suspension flag after each chunk.
> 2) What does object_write_barrier(dest) report in algorithm with chunks?
it should report the chunk update. Of course, it should have have more
parameters to outline the exact chunk that has been updated.
> > 2) Another solution could be if GC will provide a helper written with
> > > vmmagic for array copying by itself?
> >
> > yes, that makes it a) more elegant/supportable than JIT magic b) has
> > GC specifics in GC. But on the other hand we should limit this vmmagic
> > functionality by the "optimized" part of arraycopy. All other
> > exception throwing pecularities are more natural to implement on JIT
> > or VM side.
>
>
> Dividing arraycopy into different parts implies additional layer in GC-JIT
> communication in this case. I see no reasons why not to do nullpointer or
> bounds check in vmmagic helper.
and type checks? IMHO, these checks are not GC-ish. It has to be one
more contract if we want to tickle with this performance issue. The
question is will it be a new CG-JIT contract or GC-VM contract (to
throw exceptions). I see no much difference here. Need to decide.
--
Egor Pasko
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Mikhail Fursov <mi...@gmail.com>.
On 11 Jan 2007 17:26:13 +0600, Egor Pasko <eg...@gmail.com> wrote:
>
> On the 0x25B day of Apache Harmony Mikhail Fursov wrote:
> > IMO disabling GC for inlined arraycopy IR region is a good idea and it
> > should work.
> > Other proposals from me here:
> > 1) Why to report each object separately? May be calling wb helper once
> with
> > array of objects could be better?
>
> AFAIR, Robin proposed to report array updates by chunks, which is a
> good idea for fast thread suspension. WB once for small arrays, wb
> several times for large arrays.
The issues that I did not understand from Robin's post are:
1) Why do we need chunks?
2) What does object_write_barrier(dest) report in algorithm with chunks?
> 2) Another solution could be if GC will provide a helper written with
> > vmmagic for array copying by itself?
>
> yes, that makes it a) more elegant/supportable than JIT magic b) has
> GC specifics in GC. But on the other hand we should limit this vmmagic
> functionality by the "optimized" part of arraycopy. All other
> exception throwing pecularities are more natural to implement on JIT
> or VM side.
Dividing arraycopy into different parts implies additional layer in GC-JIT
communication in this case. I see no reasons why not to do nullpointer or
bounds check in vmmagic helper.
--
> Egor Pasko
>
>
--
Mikhail Fursov
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x25B day of Apache Harmony Mikhail Fursov wrote:
> IMO disabling GC for inlined arraycopy IR region is a good idea and it
> should work.
> Other proposals from me here:
> 1) Why to report each object separately? May be calling wb helper once with
> array of objects could be better?
AFAIR, Robin proposed to report array updates by chunks, which is a
good idea for fast thread suspension. WB once for small arrays, wb
several times for large arrays.
> 2) Another solution could be if GC will provide a helper written with
> vmmagic for array copying by itself?
yes, that makes it a) more elegant/supportable than JIT magic b) has
GC specifics in GC. But on the other hand we should limit this vmmagic
functionality by the "optimized" part of arraycopy. All other
exception throwing pecularities are more natural to implement on JIT
or VM side.
--
Egor Pasko
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Mikhail Fursov <mi...@gmail.com>.
IMO disabling GC for inlined arraycopy IR region is a good idea and it
should work.
Other proposals from me here:
1) Why to report each object separately? May be calling wb helper once with
array of objects could be better?
2) Another solution could be if GC will provide a helper written with
vmmagic for array copying by itself?
--
Mikhail Fursov
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Robin Garner <ro...@anu.edu.au>.
Egor Pasko wrote:
> On the 0x259 day of Apache Harmony Weldon Washburn wrote:
>> On 1/9/07, Robin Garner <ro...@anu.edu.au> wrote:
[snip]
>>> Off the top of my head, if the barrier is called before any data is copied
>>> I think the arraycopy code is GC-safe, provided another barrier call is
>>> made after the GC and before the next pointer write. It's probably better
>>> to make the arraycopy code uninterruptible.
>>
>> Yes, I agree it's probably better to make the arraycopy code
>> uninterrutible. The only caution is the impact on GC latency. Um, does
>> this require a new additional API or can we simply use what is existing?
>
> well, you are probably saying that "optimized version of arraycopy
> should be uninterruptable". In general, arraycopy can thow exceptions
> => that should be a safepoint.
>
> Anyway, GC latency is a good note to mention here. Ideally we could
> separate an array in parts for copying and put safepoints in between
> the parts (that would require an extra JIT->GC interface pecularity to
> tell which part of the array the barrier corresponds to). Something
> tells me (my gut?) that this "optimization" would not give anything in
> real situations :)
>
Until DRLVM gets into soft realtime workloads, which will need some kind
of incremental/concurrent collector, a delay of 1-2ms waiting for an
array copy shouldn't be a problem. Testing with linux memcpy, a 512k
array can be copied in ~1.5ms. Calling the barrier every 512k (or 128K
or 64k) of copy doesn't sound like too much of an overhead.
The fast array copy needs to disable GC, or reload base address and
recalculate offset continually in case the array(s) move during GC. The
array copy code would have to look something like:
copied = 0;
while (copied < size) {
disableGC();
srcPtr = src + copied; // Reload in case GC occurred
destPtr = dest + copied;
copy_size = size - copied < CHUNK_SIZE ? size - copied : CHUNK_SIZE;
object_write_barrier(dest);
memcpy(destPtr,srcPtr,copy_size); // Or equiv hand-generated code
copied += copy_size;
enableGC();
}
Since the barrier is an object remembering barrier, it doesn't need to
know which bit of the array has been copied, and can be called multiple
times on the same object. Object remembering barriers have the
advantage that they can set a 'remembered bit' in the object header and
ensure they are only ever in the remset once.
cheers
--
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x259 day of Apache Harmony Weldon Washburn wrote:
> On 1/9/07, Robin Garner <ro...@anu.edu.au> wrote:
> >
> > > On 09 Jan 2007 16:54:03 +0600, Egor Pasko <eg...@gmail.com> wrote:
> > >>
> > >> On the 0x258 day of Apache Harmony Weldon Washburn wrote:
> > >> > It looks like multiple interesting design topics. My comments
> > inlined
> > >> > below.
> > >> >
> > >> [..snip..]
> > >> >
> > >> > > Hi, I found write barrier in DRLVM can't catch all reference fields
> > >> > > updates, and the problem is identified to be caused by new jit opts
> > >> > > that do not observe the write barrier invariant for fields updates.
> > >> > > For example, JIT may generate code to copy consecutive fields of an
> > >> > > object without invoking write barrier. In order to revive the write
> > >> > > barrier functionality while not sacrificing the opt performance,
> > >> >
> > >> > Yes. But first how much performance is being
> > sacrificed? .2%? 8%??
> >
> > >>
> > >> JIT magic arraycopy gives up to 30% boost on a microbenchmark (see
> > >> HARMONY-2247). I did not measure boosts on specific benchmarks, but I
> > >> think users would expect System.arraycopy() to be pretty faster than
> > >> manual array copying. We should care about performance numbers as
> > >> such.
> > >
> > >
> > > Let me re-phrase the question. Arraycopy performance is important and
> > > deserves the special case treatment it has always gotten. Setting aside
> > > arraycopy, how much performance gain can be expected by optimizing
> > > consecutive writes to fields of an object for the benchmarks we care
> > > about?
> > > What about simply marking the consecutive writes regions as
> > > "Uninterruptible"? This would eliminate yet another API between the GC
> > > and
> > > JIT. I think this is basically the same as Robin's suggestion.
> > >
> > > Regarding arraycopy, is there a problem with making the entire arraycopy
> > > loop "Uninterruptible"? This will impact GC latency but is the impact a
> > > big
> > > deal for workloads we care about? If it is, why not have the compiler
> > > unroll the loop a bunch and put WBs every, say, 10th write. The body of
> > > 10
> > > writes would be Uninterruptible.
> >
> > With arraycopy, much of the saving is in barrier costs themselves. Apart
> > from the overhead on the write, there's a reduction in remset entries, and
> > the cost of scanning the object at GC time is minimal for a reference
> > array.
> >
> > The original motivating benchmark was jess iirc.
> >
> > Off the top of my head, if the barrier is called before any data is copied
> > I think the arraycopy code is GC-safe, provided another barrier call is
> > made after the GC and before the next pointer write. It's probably better
> > to make the arraycopy code uninterruptible.
>
>
> Yes, I agree it's probably better to make the arraycopy code
> uninterrutible. The only caution is the impact on GC latency. Um, does
> this require a new additional API or can we simply use what is existing?
well, you are probably saying that "optimized version of arraycopy
should be uninterruptable". In general, arraycopy can thow exceptions
=> that should be a safepoint.
Anyway, GC latency is a good note to mention here. Ideally we could
separate an array in parts for copying and put safepoints in between
the parts (that would require an extra JIT->GC interface pecularity to
tell which part of the array the barrier corresponds to). Something
tells me (my gut?) that this "optimization" would not give anything in
real situations :)
> My gut feel is that scalars don't generally have enough pointers to make
> > the object remembering barrier worthwhile.
>
>
> That's my hunch also. However, if someone wants to spend time analyzing
> enterprise workloads to discover if there is any cheese down that tunnel, I
> won't get in the way.
Anyway, these days object copying/moving is NOT performed by code
emitted by Jitrino, and this kind of behaviour is not going to be
implemented in the nearest future. Thus, it cannot be the root cause
of the original bug we are discussing. The only problem left is
arraycopy (recent changes in arraycopy impl makes me more confident in
this version)
--
Egor Pasko
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Weldon Washburn <we...@gmail.com>.
On 1/9/07, Robin Garner <ro...@anu.edu.au> wrote:
>
> > On 09 Jan 2007 16:54:03 +0600, Egor Pasko <eg...@gmail.com> wrote:
> >>
> >> On the 0x258 day of Apache Harmony Weldon Washburn wrote:
> >> > It looks like multiple interesting design topics. My comments
> inlined
> >> > below.
> >> >
> >> [..snip..]
> >> >
> >> > > Hi, I found write barrier in DRLVM can't catch all reference fields
> >> > > updates, and the problem is identified to be caused by new jit opts
> >> > > that do not observe the write barrier invariant for fields updates.
> >> > > For example, JIT may generate code to copy consecutive fields of an
> >> > > object without invoking write barrier. In order to revive the write
> >> > > barrier functionality while not sacrificing the opt performance,
> >> >
> >> > Yes. But first how much performance is being
> sacrificed? .2%? 8%??
>
> >>
> >> JIT magic arraycopy gives up to 30% boost on a microbenchmark (see
> >> HARMONY-2247). I did not measure boosts on specific benchmarks, but I
> >> think users would expect System.arraycopy() to be pretty faster than
> >> manual array copying. We should care about performance numbers as
> >> such.
> >
> >
> > Let me re-phrase the question. Arraycopy performance is important and
> > deserves the special case treatment it has always gotten. Setting aside
> > arraycopy, how much performance gain can be expected by optimizing
> > consecutive writes to fields of an object for the benchmarks we care
> > about?
> > What about simply marking the consecutive writes regions as
> > "Uninterruptible"? This would eliminate yet another API between the GC
> > and
> > JIT. I think this is basically the same as Robin's suggestion.
> >
> > Regarding arraycopy, is there a problem with making the entire arraycopy
> > loop "Uninterruptible"? This will impact GC latency but is the impact a
> > big
> > deal for workloads we care about? If it is, why not have the compiler
> > unroll the loop a bunch and put WBs every, say, 10th write. The body of
> > 10
> > writes would be Uninterruptible.
>
> With arraycopy, much of the saving is in barrier costs themselves. Apart
> from the overhead on the write, there's a reduction in remset entries, and
> the cost of scanning the object at GC time is minimal for a reference
> array.
>
> The original motivating benchmark was jess iirc.
>
> Off the top of my head, if the barrier is called before any data is copied
> I think the arraycopy code is GC-safe, provided another barrier call is
> made after the GC and before the next pointer write. It's probably better
> to make the arraycopy code uninterruptible.
Yes, I agree it's probably better to make the arraycopy code
uninterrutible. The only caution is the impact on GC latency. Um, does
this require a new additional API or can we simply use what is existing?
My gut feel is that scalars don't generally have enough pointers to make
> the object remembering barrier worthwhile.
That's my hunch also. However, if someone wants to spend time analyzing
enterprise workloads to discover if there is any cheese down that tunnel, I
won't get in the way.
>> > I'd
> >> > > suggest to introduce an object remember write barrier which will be
> >> > > invoked after the object is copied. So the JIT doesn't need to
> >> insert
> >> > > barrier for each field store.
> >> >
> >> > hmm.... what happens if some other app thread causes a GC to happen
> in
> >> the
> >> > middle of writing a bunch of fields of a given object? If the
> >> > gc_heap_wrote_object() is called before JITed code scribbles on
> slots,
> >> then
> >> > the early slots will be scanned and handled properly by the GC. But
> >> how do
> >> > we handle the slots written after the GC completes? One approach
> >> would
> >> be
> >> > for the JIT to mark such regions of emitted code "Uninterruptable".
> >> > Another approach would be to emit a WB both before and after a region
> >> of
> >> > multiple ref field scribbles. In any case, it looks like we need
> >> patch
> >> up
> >> > the holes in the contract between jit and gc. However, as I said
> >> above
> >> is
> >> > there anything wrong with a real simple dumb contract for now? That
> >> is
> >> each
> >> > ref write has a matching WB with no intervening instructions.
> >> >
> >> > >GC has an interface
> >> > > gc_heap_wrote_object(p_obj) for this case. I think it's ok to
> >> insert
> >> > > only the runtime native call at first. Then later we can consider
> to
> >> > > inline the object remembering barrier as well as the slot
> >> remembering
> >> > > barrier.
> >> > >
> >> > > Thanks,
> >> > > xiaofeng
> >> > >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Weldon Washburn
> >> > Intel Enterprise Solutions Software Division
> >>
> >> --
> >> Egor Pasko
> >>
> >>
> >
> >
> > --
> > Weldon Washburn
> > Intel Enterprise Solutions Software Division
> >
>
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Robin Garner <ro...@anu.edu.au>.
> On 09 Jan 2007 16:54:03 +0600, Egor Pasko <eg...@gmail.com> wrote:
>>
>> On the 0x258 day of Apache Harmony Weldon Washburn wrote:
>> > It looks like multiple interesting design topics. My comments inlined
>> > below.
>> >
>> [..snip..]
>> >
>> > > Hi, I found write barrier in DRLVM can't catch all reference fields
>> > > updates, and the problem is identified to be caused by new jit opts
>> > > that do not observe the write barrier invariant for fields updates.
>> > > For example, JIT may generate code to copy consecutive fields of an
>> > > object without invoking write barrier. In order to revive the write
>> > > barrier functionality while not sacrificing the opt performance,
>> >
>> > Yes. But first how much performance is being sacrificed? .2%? 8%??
>>
>> JIT magic arraycopy gives up to 30% boost on a microbenchmark (see
>> HARMONY-2247). I did not measure boosts on specific benchmarks, but I
>> think users would expect System.arraycopy() to be pretty faster than
>> manual array copying. We should care about performance numbers as
>> such.
>
>
> Let me re-phrase the question. Arraycopy performance is important and
> deserves the special case treatment it has always gotten. Setting aside
> arraycopy, how much performance gain can be expected by optimizing
> consecutive writes to fields of an object for the benchmarks we care
> about?
> What about simply marking the consecutive writes regions as
> "Uninterruptible"? This would eliminate yet another API between the GC
> and
> JIT. I think this is basically the same as Robin's suggestion.
>
> Regarding arraycopy, is there a problem with making the entire arraycopy
> loop "Uninterruptible"? This will impact GC latency but is the impact a
> big
> deal for workloads we care about? If it is, why not have the compiler
> unroll the loop a bunch and put WBs every, say, 10th write. The body of
> 10
> writes would be Uninterruptible.
With arraycopy, much of the saving is in barrier costs themselves. Apart
from the overhead on the write, there's a reduction in remset entries, and
the cost of scanning the object at GC time is minimal for a reference
array.
The original motivating benchmark was jess iirc.
Off the top of my head, if the barrier is called before any data is copied
I think the arraycopy code is GC-safe, provided another barrier call is
made after the GC and before the next pointer write. It's probably better
to make the arraycopy code uninterruptible.
My gut feel is that scalars don't generally have enough pointers to make
the object remembering barrier worthwhile.
>> > I'd
>> > > suggest to introduce an object remember write barrier which will be
>> > > invoked after the object is copied. So the JIT doesn't need to
>> insert
>> > > barrier for each field store.
>> >
>> > hmm.... what happens if some other app thread causes a GC to happen in
>> the
>> > middle of writing a bunch of fields of a given object? If the
>> > gc_heap_wrote_object() is called before JITed code scribbles on slots,
>> then
>> > the early slots will be scanned and handled properly by the GC. But
>> how do
>> > we handle the slots written after the GC completes? One approach
>> would
>> be
>> > for the JIT to mark such regions of emitted code "Uninterruptable".
>> > Another approach would be to emit a WB both before and after a region
>> of
>> > multiple ref field scribbles. In any case, it looks like we need
>> patch
>> up
>> > the holes in the contract between jit and gc. However, as I said
>> above
>> is
>> > there anything wrong with a real simple dumb contract for now? That
>> is
>> each
>> > ref write has a matching WB with no intervening instructions.
>> >
>> > >GC has an interface
>> > > gc_heap_wrote_object(p_obj) for this case. I think it's ok to
>> insert
>> > > only the runtime native call at first. Then later we can consider to
>> > > inline the object remembering barrier as well as the slot
>> remembering
>> > > barrier.
>> > >
>> > > Thanks,
>> > > xiaofeng
>> > >
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> > Weldon Washburn
>> > Intel Enterprise Solutions Software Division
>>
>> --
>> Egor Pasko
>>
>>
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Weldon Washburn <we...@gmail.com>.
On 09 Jan 2007 16:54:03 +0600, Egor Pasko <eg...@gmail.com> wrote:
>
> On the 0x258 day of Apache Harmony Weldon Washburn wrote:
> > It looks like multiple interesting design topics. My comments inlined
> > below.
> >
> [..snip..]
> >
> > > Hi, I found write barrier in DRLVM can't catch all reference fields
> > > updates, and the problem is identified to be caused by new jit opts
> > > that do not observe the write barrier invariant for fields updates.
> > > For example, JIT may generate code to copy consecutive fields of an
> > > object without invoking write barrier. In order to revive the write
> > > barrier functionality while not sacrificing the opt performance,
> >
> > Yes. But first how much performance is being sacrificed? .2%? 8%??
>
> JIT magic arraycopy gives up to 30% boost on a microbenchmark (see
> HARMONY-2247). I did not measure boosts on specific benchmarks, but I
> think users would expect System.arraycopy() to be pretty faster than
> manual array copying. We should care about performance numbers as
> such.
Let me re-phrase the question. Arraycopy performance is important and
deserves the special case treatment it has always gotten. Setting aside
arraycopy, how much performance gain can be expected by optimizing
consecutive writes to fields of an object for the benchmarks we care about?
What about simply marking the consecutive writes regions as
"Uninterruptible"? This would eliminate yet another API between the GC and
JIT. I think this is basically the same as Robin's suggestion.
Regarding arraycopy, is there a problem with making the entire arraycopy
loop "Uninterruptible"? This will impact GC latency but is the impact a big
deal for workloads we care about? If it is, why not have the compiler
unroll the loop a bunch and put WBs every, say, 10th write. The body of 10
writes would be Uninterruptible.
> > I'd
> > > suggest to introduce an object remember write barrier which will be
> > > invoked after the object is copied. So the JIT doesn't need to insert
> > > barrier for each field store.
> >
> > hmm.... what happens if some other app thread causes a GC to happen in
> the
> > middle of writing a bunch of fields of a given object? If the
> > gc_heap_wrote_object() is called before JITed code scribbles on slots,
> then
> > the early slots will be scanned and handled properly by the GC. But
> how do
> > we handle the slots written after the GC completes? One approach would
> be
> > for the JIT to mark such regions of emitted code "Uninterruptable".
> > Another approach would be to emit a WB both before and after a region of
> > multiple ref field scribbles. In any case, it looks like we need patch
> up
> > the holes in the contract between jit and gc. However, as I said above
> is
> > there anything wrong with a real simple dumb contract for now? That is
> each
> > ref write has a matching WB with no intervening instructions.
> >
> > >GC has an interface
> > > gc_heap_wrote_object(p_obj) for this case. I think it's ok to insert
> > > only the runtime native call at first. Then later we can consider to
> > > inline the object remembering barrier as well as the slot remembering
> > > barrier.
> > >
> > > Thanks,
> > > xiaofeng
> > >
> >
> >
> >
> >
> >
> >
> > --
> > Weldon Washburn
> > Intel Enterprise Solutions Software Division
>
> --
> Egor Pasko
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x258 day of Apache Harmony Weldon Washburn wrote:
> It looks like multiple interesting design topics. My comments inlined
> below.
>
[..snip..]
>
> > Hi, I found write barrier in DRLVM can't catch all reference fields
> > updates, and the problem is identified to be caused by new jit opts
> > that do not observe the write barrier invariant for fields updates.
> > For example, JIT may generate code to copy consecutive fields of an
> > object without invoking write barrier. In order to revive the write
> > barrier functionality while not sacrificing the opt performance,
>
> Yes. But first how much performance is being sacrificed? .2%? 8%??
JIT magic arraycopy gives up to 30% boost on a microbenchmark (see
HARMONY-2247). I did not measure boosts on specific benchmarks, but I
think users would expect System.arraycopy() to be pretty faster than
manual array copying. We should care about performance numbers as
such.
> > I'd
> > suggest to introduce an object remember write barrier which will be
> > invoked after the object is copied. So the JIT doesn't need to insert
> > barrier for each field store.
>
> hmm.... what happens if some other app thread causes a GC to happen in the
> middle of writing a bunch of fields of a given object? If the
> gc_heap_wrote_object() is called before JITed code scribbles on slots, then
> the early slots will be scanned and handled properly by the GC. But how do
> we handle the slots written after the GC completes? One approach would be
> for the JIT to mark such regions of emitted code "Uninterruptable".
> Another approach would be to emit a WB both before and after a region of
> multiple ref field scribbles. In any case, it looks like we need patch up
> the holes in the contract between jit and gc. However, as I said above is
> there anything wrong with a real simple dumb contract for now? That is each
> ref write has a matching WB with no intervening instructions.
>
> >GC has an interface
> > gc_heap_wrote_object(p_obj) for this case. I think it's ok to insert
> > only the runtime native call at first. Then later we can consider to
> > inline the object remembering barrier as well as the slot remembering
> > barrier.
> >
> > Thanks,
> > xiaofeng
> >
>
>
>
>
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
--
Egor Pasko
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x25A day of Apache Harmony Weldon Washburn wrote:
> On 09 Jan 2007 16:47:52 +0600, Egor Pasko <eg...@gmail.com> wrote:
> >
> > On the 0x258 day of Apache Harmony Weldon Washburn wrote:
> > > On 1/7/07, Robin Garner <ro...@anu.edu.au> wrote:
> > > >
> > > > Xiao-Feng Li wrote:
> > > > > On 1/8/07, Weldon Washburn <we...@gmail.com> wrote:
> > > > >> > I'd
> > > > >> > suggest to introduce an object remember write barrier which will
> > be
> > > > >> > invoked after the object is copied. So the JIT doesn't need to
> > insert
> > > > >> > barrier for each field store.
> > > > >>
> > > > >> hmm.... what happens if some other app thread causes a GC to happen
> > in
> > > > >> the
> > > > >> middle of writing a bunch of fields of a given object? If the
> > > > >> gc_heap_wrote_object() is called before JITed code scribbles on
> > slots,
> > > > >> then
> > > > >> the early slots will be scanned and handled properly by the GC.
> > But
> > > > >> how do
> > > > >> we handle the slots written after the GC completes? One approach
> > > > >> would be
> > > > >> for the JIT to mark such regions of emitted code "Uninterruptable".
> > > > >> Another approach would be to emit a WB both before and after a
> > region
> > > > of
> > > > >> multiple ref field scribbles. In any case, it looks like we need
> > > > >> patch up
> > > > >> the holes in the contract between jit and gc. However, as I said
> > > > >> above is
> > > > >> there anything wrong with a real simple dumb contract for
> > now? That
> > > > >> is each
> > > > >> ref write has a matching WB with no intervening instructions.
> > > > >
> > > > > Why can that be an issue? GC can only happen at safepoint, it can't
> > > > > happen in the middle of object copy. Object copy exists no matter
> > > > > there is write barrier or not.
> > > >
> > > > I think this is the specification of the contract (if DRLVM persists
> > > > with non-substituting write-barriers): no GC safe point can occur
> > > > between the write of a field and write-barrier completion. Within a
> > > > basic block (or a chunk of @Uninterrubtible code) , the compiler can
> > do
> > > > whatever instruction scheduling it likes.
> > >
> > >
> > > I like it. Its concise and as far as I know, accurate.
> >
> > And to the more.. it *is* the current contract in DRLVM
>
>
> This is good. Thanks for confirming this.
>
> > Moving to substituting write barriers exclusively is very attractive
> > > now that vmmagic is supported in drlvm. Given that we still have
> > > old pre-vmmagic GCs laying around, we need to support
> > > non-substituting WBs for a little while longer.
> > >
> > > One thing we need to build are regression tests that demonstrate with
> > > (hopefully) high accuracy that the JIT is correctly emitting all the WB
> > > corner cases. The hope is that it is possible to build these regression
> > > tests entirely in app Java.
> >
> > that is hardly believable. In general, number of pointer updates may
> > vary depending on JIT optimization level (unless we mark all updated
> > fields as 'volatile'.. and we have a free 'volatile'-related test,
> > heh?)
>
>
> hmm... I am not sure what is being said. In any case, we need some sort of
> rigorous WB regression test because a missing WB can cause all sorts of very
> hard to diagnose problems. Assuming the existing JIT code base has zero WB
> bugs, it is still important to have some way of discovering if future mods
> to the source base cause a WB regression. Ideally a non-intrusive test
> written in Java would be best. Of course this may simply not be feasible.
In other words: a Java test is not easy to write so that it checks all
corner cases and FAILs if some small WB does not happen (effect of a
WB very much depends on GC, but we want the test to be JIT-oriented as
much as possible and do not depand on GC, and be non-intruisive, etc.)
Suppose in a Java test JIT does NOT insert a required WB which would
have made no effect in a current GC. So, the test does NOT fail.
The alternative way we can think about is to implement an option in
JIT to dump the number of WBs inserted (in a specific method) and
check it by Java code. My comment was against this approach. The
problem is that in general we cannot count the "right" number of WBs
(the number much depends on the optimization level)
> > This would make these tests non-intrusive which is very desirable.
> > > The other approach is to instrument the JVM snap all the WB writes.
> > > The idea is to write some simple Java code, then manuallly count all
> > > the ref ptr assignment locations. Then verify that wbCount == the
> > > manually counted writes.
> >
> > Best corner cases can probably be implemented in JIT IR-level test
> > suite (that we were discussing recently). It is currently in JIRA, but
> > can be integrated pretty fast. wbCount verification is natural to
> > implement with the infrastructure.
>
>
> Perfect. Can the above infrastructure be extended to handle all the corner
> cases of WB?
sure. The infrastructure allows to write an IR sample for JIT input
and then verify the correctness of transformations performed by JIT.
--
Egor Pasko
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Weldon Washburn <we...@gmail.com>.
On 09 Jan 2007 16:47:52 +0600, Egor Pasko <eg...@gmail.com> wrote:
>
> On the 0x258 day of Apache Harmony Weldon Washburn wrote:
> > On 1/7/07, Robin Garner <ro...@anu.edu.au> wrote:
> > >
> > > Xiao-Feng Li wrote:
> > > > On 1/8/07, Weldon Washburn <we...@gmail.com> wrote:
> > > >> > I'd
> > > >> > suggest to introduce an object remember write barrier which will
> be
> > > >> > invoked after the object is copied. So the JIT doesn't need to
> insert
> > > >> > barrier for each field store.
> > > >>
> > > >> hmm.... what happens if some other app thread causes a GC to happen
> in
> > > >> the
> > > >> middle of writing a bunch of fields of a given object? If the
> > > >> gc_heap_wrote_object() is called before JITed code scribbles on
> slots,
> > > >> then
> > > >> the early slots will be scanned and handled properly by the GC.
> But
> > > >> how do
> > > >> we handle the slots written after the GC completes? One approach
> > > >> would be
> > > >> for the JIT to mark such regions of emitted code "Uninterruptable".
> > > >> Another approach would be to emit a WB both before and after a
> region
> > > of
> > > >> multiple ref field scribbles. In any case, it looks like we need
> > > >> patch up
> > > >> the holes in the contract between jit and gc. However, as I said
> > > >> above is
> > > >> there anything wrong with a real simple dumb contract for
> now? That
> > > >> is each
> > > >> ref write has a matching WB with no intervening instructions.
> > > >
> > > > Why can that be an issue? GC can only happen at safepoint, it can't
> > > > happen in the middle of object copy. Object copy exists no matter
> > > > there is write barrier or not.
> > >
> > > I think this is the specification of the contract (if DRLVM persists
> > > with non-substituting write-barriers): no GC safe point can occur
> > > between the write of a field and write-barrier completion. Within a
> > > basic block (or a chunk of @Uninterrubtible code) , the compiler can
> do
> > > whatever instruction scheduling it likes.
> >
> >
> > I like it. Its concise and as far as I know, accurate.
>
> And to the more.. it *is* the current contract in DRLVM
This is good. Thanks for confirming this.
> Moving to substituting write barriers exclusively is very attractive
> > now that vmmagic is supported in drlvm. Given that we still have
> > old pre-vmmagic GCs laying around, we need to support
> > non-substituting WBs for a little while longer.
> >
> > One thing we need to build are regression tests that demonstrate with
> > (hopefully) high accuracy that the JIT is correctly emitting all the WB
> > corner cases. The hope is that it is possible to build these regression
> > tests entirely in app Java.
>
> that is hardly believable. In general, number of pointer updates may
> vary depending on JIT optimization level (unless we mark all updated
> fields as 'volatile'.. and we have a free 'volatile'-related test,
> heh?)
hmm... I am not sure what is being said. In any case, we need some sort of
rigorous WB regression test because a missing WB can cause all sorts of very
hard to diagnose problems. Assuming the existing JIT code base has zero WB
bugs, it is still important to have some way of discovering if future mods
to the source base cause a WB regression. Ideally a non-intrusive test
written in Java would be best. Of course this may simply not be feasible.
> This would make these tests non-intrusive which is very desirable.
> > The other approach is to instrument the JVM snap all the WB writes.
> > The idea is to write some simple Java code, then manuallly count all
> > the ref ptr assignment locations. Then verify that wbCount == the
> > manually counted writes.
>
> Best corner cases can probably be implemented in JIT IR-level test
> suite (that we were discussing recently). It is currently in JIRA, but
> can be integrated pretty fast. wbCount verification is natural to
> implement with the infrastructure.
Perfect. Can the above infrastructure be extended to handle all the corner
cases of WB?
--
> Egor Pasko
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x258 day of Apache Harmony Weldon Washburn wrote:
> On 1/7/07, Robin Garner <ro...@anu.edu.au> wrote:
> >
> > Xiao-Feng Li wrote:
> > > On 1/8/07, Weldon Washburn <we...@gmail.com> wrote:
> > >> > I'd
> > >> > suggest to introduce an object remember write barrier which will be
> > >> > invoked after the object is copied. So the JIT doesn't need to insert
> > >> > barrier for each field store.
> > >>
> > >> hmm.... what happens if some other app thread causes a GC to happen in
> > >> the
> > >> middle of writing a bunch of fields of a given object? If the
> > >> gc_heap_wrote_object() is called before JITed code scribbles on slots,
> > >> then
> > >> the early slots will be scanned and handled properly by the GC. But
> > >> how do
> > >> we handle the slots written after the GC completes? One approach
> > >> would be
> > >> for the JIT to mark such regions of emitted code "Uninterruptable".
> > >> Another approach would be to emit a WB both before and after a region
> > of
> > >> multiple ref field scribbles. In any case, it looks like we need
> > >> patch up
> > >> the holes in the contract between jit and gc. However, as I said
> > >> above is
> > >> there anything wrong with a real simple dumb contract for now? That
> > >> is each
> > >> ref write has a matching WB with no intervening instructions.
> > >
> > > Why can that be an issue? GC can only happen at safepoint, it can't
> > > happen in the middle of object copy. Object copy exists no matter
> > > there is write barrier or not.
> >
> > I think this is the specification of the contract (if DRLVM persists
> > with non-substituting write-barriers): no GC safe point can occur
> > between the write of a field and write-barrier completion. Within a
> > basic block (or a chunk of @Uninterrubtible code) , the compiler can do
> > whatever instruction scheduling it likes.
>
>
> I like it. Its concise and as far as I know, accurate.
And to the more.. it *is* the current contract in DRLVM
> Moving to substituting write barriers exclusively is very attractive
> now that vmmagic is supported in drlvm. Given that we still have
> old pre-vmmagic GCs laying around, we need to support
> non-substituting WBs for a little while longer.
>
> One thing we need to build are regression tests that demonstrate with
> (hopefully) high accuracy that the JIT is correctly emitting all the WB
> corner cases. The hope is that it is possible to build these regression
> tests entirely in app Java.
that is hardly believable. In general, number of pointer updates may
vary depending on JIT optimization level (unless we mark all updated
fields as 'volatile'.. and we have a free 'volatile'-related test,
heh?)
> This would make these tests non-intrusive which is very desirable.
> The other approach is to instrument the JVM snap all the WB writes.
> The idea is to write some simple Java code, then manuallly count all
> the ref ptr assignment locations. Then verify that wbCount == the
> manually counted writes.
Best corner cases can probably be implemented in JIT IR-level test
suite (that we were discussing recently). It is currently in JIRA, but
can be integrated pretty fast. wbCount verification is natural to
implement with the infrastructure.
--
Egor Pasko
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Weldon Washburn <we...@gmail.com>.
On 1/7/07, Robin Garner <ro...@anu.edu.au> wrote:
>
> Xiao-Feng Li wrote:
> > On 1/8/07, Weldon Washburn <we...@gmail.com> wrote:
> >> > I'd
> >> > suggest to introduce an object remember write barrier which will be
> >> > invoked after the object is copied. So the JIT doesn't need to insert
> >> > barrier for each field store.
> >>
> >> hmm.... what happens if some other app thread causes a GC to happen in
> >> the
> >> middle of writing a bunch of fields of a given object? If the
> >> gc_heap_wrote_object() is called before JITed code scribbles on slots,
> >> then
> >> the early slots will be scanned and handled properly by the GC. But
> >> how do
> >> we handle the slots written after the GC completes? One approach
> >> would be
> >> for the JIT to mark such regions of emitted code "Uninterruptable".
> >> Another approach would be to emit a WB both before and after a region
> of
> >> multiple ref field scribbles. In any case, it looks like we need
> >> patch up
> >> the holes in the contract between jit and gc. However, as I said
> >> above is
> >> there anything wrong with a real simple dumb contract for now? That
> >> is each
> >> ref write has a matching WB with no intervening instructions.
> >
> > Why can that be an issue? GC can only happen at safepoint, it can't
> > happen in the middle of object copy. Object copy exists no matter
> > there is write barrier or not.
>
> I think this is the specification of the contract (if DRLVM persists
> with non-substituting write-barriers): no GC safe point can occur
> between the write of a field and write-barrier completion. Within a
> basic block (or a chunk of @Uninterrubtible code) , the compiler can do
> whatever instruction scheduling it likes.
I like it. Its concise and as far as I know, accurate. Moving to
substituting write barriers exclusively is very attractive now that vmmagic
is supported in drlvm. Given that we still have old pre-vmmagic GCs laying
around, we need to support non-substituting WBs for a little while longer.
One thing we need to build are regression tests that demonstrate with
(hopefully) high accuracy that the JIT is correctly emitting all the WB
corner cases. The hope is that it is possible to build these regression
tests entirely in app Java. This would make these tests non-intrusive which
is very desirable. The other approach is to instrument the JVM snap all the
WB writes. The idea is to write some simple Java code, then manuallly count
all the ref ptr assignment locations. Then verify that wbCount == the
manually counted writes.
> Thanks,
> > xiaofeng
> >
> >> >GC has an interface
> >> > gc_heap_wrote_object(p_obj) for this case. I think it's ok to insert
> >> > only the runtime native call at first. Then later we can consider to
> >> > inline the object remembering barrier as well as the slot remembering
> >> > barrier.
> >> >
> >> > Thanks,
> >> > xiaofeng
> >> >
>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Weldon Washburn
> >> Intel Enterprise Solutions Software Division
> >>
> >>
>
>
> --
> Robin Garner
> Dept. of Computer Science
> Australian National University
> http://cs.anu.edu.au/people/Robin.Garner/
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Robin Garner <ro...@anu.edu.au>.
Xiao-Feng Li wrote:
> On 1/8/07, Weldon Washburn <we...@gmail.com> wrote:
>> > I'd
>> > suggest to introduce an object remember write barrier which will be
>> > invoked after the object is copied. So the JIT doesn't need to insert
>> > barrier for each field store.
>>
>> hmm.... what happens if some other app thread causes a GC to happen in
>> the
>> middle of writing a bunch of fields of a given object? If the
>> gc_heap_wrote_object() is called before JITed code scribbles on slots,
>> then
>> the early slots will be scanned and handled properly by the GC. But
>> how do
>> we handle the slots written after the GC completes? One approach
>> would be
>> for the JIT to mark such regions of emitted code "Uninterruptable".
>> Another approach would be to emit a WB both before and after a region of
>> multiple ref field scribbles. In any case, it looks like we need
>> patch up
>> the holes in the contract between jit and gc. However, as I said
>> above is
>> there anything wrong with a real simple dumb contract for now? That
>> is each
>> ref write has a matching WB with no intervening instructions.
>
> Why can that be an issue? GC can only happen at safepoint, it can't
> happen in the middle of object copy. Object copy exists no matter
> there is write barrier or not.
I think this is the specification of the contract (if DRLVM persists
with non-substituting write-barriers): no GC safe point can occur
between the write of a field and write-barrier completion. Within a
basic block (or a chunk of @Uninterrubtible code) , the compiler can do
whatever instruction scheduling it likes.
> Thanks,
> xiaofeng
>
>> >GC has an interface
>> > gc_heap_wrote_object(p_obj) for this case. I think it's ok to insert
>> > only the runtime native call at first. Then later we can consider to
>> > inline the object remembering barrier as well as the slot remembering
>> > barrier.
>> >
>> > Thanks,
>> > xiaofeng
>> >
>>
>>
>>
>>
>>
>> --
>> Weldon Washburn
>> Intel Enterprise Solutions Software Division
>>
>>
--
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 1/8/07, Weldon Washburn <we...@gmail.com> wrote:
> > I'd
> > suggest to introduce an object remember write barrier which will be
> > invoked after the object is copied. So the JIT doesn't need to insert
> > barrier for each field store.
>
> hmm.... what happens if some other app thread causes a GC to happen in the
> middle of writing a bunch of fields of a given object? If the
> gc_heap_wrote_object() is called before JITed code scribbles on slots, then
> the early slots will be scanned and handled properly by the GC. But how do
> we handle the slots written after the GC completes? One approach would be
> for the JIT to mark such regions of emitted code "Uninterruptable".
> Another approach would be to emit a WB both before and after a region of
> multiple ref field scribbles. In any case, it looks like we need patch up
> the holes in the contract between jit and gc. However, as I said above is
> there anything wrong with a real simple dumb contract for now? That is each
> ref write has a matching WB with no intervening instructions.
Why can that be an issue? GC can only happen at safepoint, it can't
happen in the middle of object copy. Object copy exists no matter
there is write barrier or not.
Thanks,
xiaofeng
> >GC has an interface
> > gc_heap_wrote_object(p_obj) for this case. I think it's ok to insert
> > only the runtime native call at first. Then later we can consider to
> > inline the object remembering barrier as well as the slot remembering
> > barrier.
> >
> > Thanks,
> > xiaofeng
> >
>
>
>
>
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
>
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Weldon Washburn <we...@gmail.com>.
It looks like multiple interesting design topics. My comments inlined
below.
On 1/6/07, Robin Garner <ro...@anu.edu.au> wrote:
>
> I disagree. Partly from the point of view of eventual support for MMTk,
> but also on more general grounds, in terms of support for future GC
> algorithms.
>
> If the memory manager requires that the compiler invoke the write barrier
> for each pointer store, then it should honour the contract and do so.
Good point. I don't recall the contract specifically stating each write to
an object slot requires a call to the write barrier. It must have fallen
through the cracks. It seems we should create a clearer contract. On a
related note, should DRLVM gc/vm contract say that only substituting write
barriers are allowed? The reason I mention this is because if the JIT is
allowed to call the write barrier as a seperate operation from doing the
actual writes, then we probably have to specifiy if the write barrier has to
happen before/after the actual write. A real messy one would be specifying
the distance between a write and its write barrier. Is it OK for the JIT to
lazily generate a WB as late as the next object write? What is the contract
for volatile variables? During optimizations, can WB "x" be lazily delayed
until after a later write to object "z"? I am beginning to see new value
in using substituting write barriers -- it eliminates creating some very
ugly and inflexible contracts between JIT, VM and GC.
I understand the performance potential of optimizing out a write barrier if
the app code is linearly writing many fields of a given object. I don't
understand if this happens often enough in workloads we care about. At this
stage of Harmony VM development, perhaps it makes sense to always match a
ref write w/ a WB. Then let the workloads users care about actually drive
better design if needed. Isn't arraycopy already a special case? In
otherwords, it might just be that part the performance potential is already
captured in the special case code for arraycopy of type reference.
If you want to provide an object remembering barrier that the compiler can
call as an optimization, then by all means do so, but the GC should not be
forced to work around compiler 'optimizations' that break fundamental
interface contracts.
While object remembering barriers may be adequate for GCV5 there are a
large family of GC algorithms that they are inadequate for, including
reference counting and concurrent/incremental GCs.
regards,
Robin
> Hi, I found write barrier in DRLVM can't catch all reference fields
> updates, and the problem is identified to be caused by new jit opts
> that do not observe the write barrier invariant for fields updates.
> For example, JIT may generate code to copy consecutive fields of an
> object without invoking write barrier. In order to revive the write
> barrier functionality while not sacrificing the opt performance,
Yes. But first how much performance is being sacrificed? .2%? 8%??
> I'd
> suggest to introduce an object remember write barrier which will be
> invoked after the object is copied. So the JIT doesn't need to insert
> barrier for each field store.
hmm.... what happens if some other app thread causes a GC to happen in the
middle of writing a bunch of fields of a given object? If the
gc_heap_wrote_object() is called before JITed code scribbles on slots, then
the early slots will be scanned and handled properly by the GC. But how do
we handle the slots written after the GC completes? One approach would be
for the JIT to mark such regions of emitted code "Uninterruptable".
Another approach would be to emit a WB both before and after a region of
multiple ref field scribbles. In any case, it looks like we need patch up
the holes in the contract between jit and gc. However, as I said above is
there anything wrong with a real simple dumb contract for now? That is each
ref write has a matching WB with no intervening instructions.
>GC has an interface
> gc_heap_wrote_object(p_obj) for this case. I think it's ok to insert
> only the runtime native call at first. Then later we can consider to
> inline the object remembering barrier as well as the slot remembering
> barrier.
>
> Thanks,
> xiaofeng
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Xiao-Feng Li <xi...@gmail.com>.
Egor, thanks for the great help! GCv5 has already object remembering
barrier support. The interface is gc_heap_wrote_object(). Only thing
remaining is to add a query of gc_supports_object_remembering(). You
can safely assume it returns true before the code is in SVN.
Thanks,
xiaofeng
On 10 Jan 2007 12:08:32 +0600, Egor Pasko <eg...@gmail.com> wrote:
> On the 0x259 day of Apache Harmony Robin Garner wrote:
> > > On the 0x257 day of Apache Harmony Robin Garner wrote:
> > >> I disagree. Partly from the point of view of eventual support for MMTk,
> > >> but also on more general grounds, in terms of support for future GC
> > >> algorithms.
> > >>
> > >> If the memory manager requires that the compiler invoke the write
> > >> barrier
> > >> for each pointer store, then it should honour the contract and do so.
> > >>
> > >> If you want to provide an object remembering barrier that the compiler
> > >> can
> > >> call as an optimization, then by all means do so, but the GC should not
> > >> be
> > >> forced to work around compiler 'optimizations' that break fundamental
> > >> interface contracts.
> > >
> > > That's what I think we should do. I see it like this:
> > >
> > > * JIT asks GC if it has_object_update_wb_feature()
> > >
> > > * JIT checks CompilationInterface.insertWriteBarriers()
> > >
> > > * if both true, JIT inserts code that update whole objects with a
> > > single "object/array update barrier". If only second is true,
> > > generate an ordinary code.
> > >
> > > * "object update barrier" should NOT be a GC safe point
> > >
> > > The scheme is not complicated and easy to implement in JIT. Just need
> > > to put the right checks in right places. It should not be difficult to
> > > implement the feature in GCv5, isn't it?
> > >
> > > In spite of introducng more state-dependant code, I think, the feature
> > > is worth it from performance point of view.
> >
> > This is what JikesRVM does, and yes, for some (macro) benchmarks it pays off.
>
> Xiao-Feng, how about implementing it for GCv5? I can help with the JIT
> part.
>
> P.S: As a temporary workaround, we can disable arraycopy via an option.
>
> --
> Egor Pasko
>
>
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x259 day of Apache Harmony Robin Garner wrote:
> > On the 0x257 day of Apache Harmony Robin Garner wrote:
> >> I disagree. Partly from the point of view of eventual support for MMTk,
> >> but also on more general grounds, in terms of support for future GC
> >> algorithms.
> >>
> >> If the memory manager requires that the compiler invoke the write
> >> barrier
> >> for each pointer store, then it should honour the contract and do so.
> >>
> >> If you want to provide an object remembering barrier that the compiler
> >> can
> >> call as an optimization, then by all means do so, but the GC should not
> >> be
> >> forced to work around compiler 'optimizations' that break fundamental
> >> interface contracts.
> >
> > That's what I think we should do. I see it like this:
> >
> > * JIT asks GC if it has_object_update_wb_feature()
> >
> > * JIT checks CompilationInterface.insertWriteBarriers()
> >
> > * if both true, JIT inserts code that update whole objects with a
> > single "object/array update barrier". If only second is true,
> > generate an ordinary code.
> >
> > * "object update barrier" should NOT be a GC safe point
> >
> > The scheme is not complicated and easy to implement in JIT. Just need
> > to put the right checks in right places. It should not be difficult to
> > implement the feature in GCv5, isn't it?
> >
> > In spite of introducng more state-dependant code, I think, the feature
> > is worth it from performance point of view.
>
> This is what JikesRVM does, and yes, for some (macro) benchmarks it pays off.
Xiao-Feng, how about implementing it for GCv5? I can help with the JIT
part.
P.S: As a temporary workaround, we can disable arraycopy via an option.
--
Egor Pasko
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Robin Garner <ro...@anu.edu.au>.
> On the 0x257 day of Apache Harmony Robin Garner wrote:
>> I disagree. Partly from the point of view of eventual support for MMTk,
>> but also on more general grounds, in terms of support for future GC
>> algorithms.
>>
>> If the memory manager requires that the compiler invoke the write
>> barrier
>> for each pointer store, then it should honour the contract and do so.
>>
>> If you want to provide an object remembering barrier that the compiler
>> can
>> call as an optimization, then by all means do so, but the GC should not
>> be
>> forced to work around compiler 'optimizations' that break fundamental
>> interface contracts.
>
> That's what I think we should do. I see it like this:
>
> * JIT asks GC if it has_object_update_wb_feature()
>
> * JIT checks CompilationInterface.insertWriteBarriers()
>
> * if both true, JIT inserts code that update whole objects with a
> single "object/array update barrier". If only second is true,
> generate an ordinary code.
>
> * "object update barrier" should NOT be a GC safe point
>
> The scheme is not complicated and easy to implement in JIT. Just need
> to put the right checks in right places. It should not be difficult to
> implement the feature in GCv5, isn't it?
>
> In spite of introducng more state-dependant code, I think, the feature
> is worth it from performance point of view.
This is what JikesRVM does, and yes, for some (macro) benchmarks it pays off.
>> While object remembering barriers may be adequate for GCV5 there are a
>> large family of GC algorithms that they are inadequate for, including
>> reference counting and concurrent/incremental GCs.
>>
>> regards,
>> Robin
>>
>> > Hi, I found write barrier in DRLVM can't catch all reference fields
>> > updates, and the problem is identified to be caused by new jit opts
>> > that do not observe the write barrier invariant for fields updates.
>> > For example, JIT may generate code to copy consecutive fields of an
>> > object without invoking write barrier. In order to revive the write
>> > barrier functionality while not sacrificing the opt performance, I'd
>> > suggest to introduce an object remember write barrier which will be
>> > invoked after the object is copied. So the JIT doesn't need to insert
>> > barrier for each field store. GC has an interface
>> > gc_heap_wrote_object(p_obj) for this case. I think it's ok to insert
>> > only the runtime native call at first. Then later we can consider to
>> > inline the object remembering barrier as well as the slot remembering
>> > barrier.
>> >
>> > Thanks,
>> > xiaofeng
>> >
>>
>>
>>
>
> --
> Egor Pasko
>
>
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x257 day of Apache Harmony Robin Garner wrote:
> I disagree. Partly from the point of view of eventual support for MMTk,
> but also on more general grounds, in terms of support for future GC
> algorithms.
>
> If the memory manager requires that the compiler invoke the write barrier
> for each pointer store, then it should honour the contract and do so.
>
> If you want to provide an object remembering barrier that the compiler can
> call as an optimization, then by all means do so, but the GC should not be
> forced to work around compiler 'optimizations' that break fundamental
> interface contracts.
That's what I think we should do. I see it like this:
* JIT asks GC if it has_object_update_wb_feature()
* JIT checks CompilationInterface.insertWriteBarriers()
* if both true, JIT inserts code that update whole objects with a
single "object/array update barrier". If only second is true,
generate an ordinary code.
* "object update barrier" should NOT be a GC safe point
The scheme is not complicated and easy to implement in JIT. Just need
to put the right checks in right places. It should not be difficult to
implement the feature in GCv5, isn't it?
In spite of introducng more state-dependant code, I think, the feature
is worth it from performance point of view.
> While object remembering barriers may be adequate for GCV5 there are a
> large family of GC algorithms that they are inadequate for, including
> reference counting and concurrent/incremental GCs.
>
> regards,
> Robin
>
> > Hi, I found write barrier in DRLVM can't catch all reference fields
> > updates, and the problem is identified to be caused by new jit opts
> > that do not observe the write barrier invariant for fields updates.
> > For example, JIT may generate code to copy consecutive fields of an
> > object without invoking write barrier. In order to revive the write
> > barrier functionality while not sacrificing the opt performance, I'd
> > suggest to introduce an object remember write barrier which will be
> > invoked after the object is copied. So the JIT doesn't need to insert
> > barrier for each field store. GC has an interface
> > gc_heap_wrote_object(p_obj) for this case. I think it's ok to insert
> > only the runtime native call at first. Then later we can consider to
> > inline the object remembering barrier as well as the slot remembering
> > barrier.
> >
> > Thanks,
> > xiaofeng
> >
>
>
>
--
Egor Pasko
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 1/8/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> What's an object remembering barrier?
It is to remeber an object whose reference fields are written.
Usually, the JIT inserts code for every reference field write, which
is called slot remembering. Recently, some jit opts generate code for
object copy in bulk, i.e., multiple fields are copied once together,
which doesn't insert slot barrier for individual field. In this case,
a straightforward solution is to remember the object after the copy.
GC will scan the object to find the reference fields of its interests.
Thanks,
xiaofeng
> On Jan 7, 2007, at 1:59 AM, Robin Garner wrote:
>
> > I disagree. Partly from the point of view of eventual support for
> > MMTk,
> > but also on more general grounds, in terms of support for future GC
> > algorithms.
> >
> > If the memory manager requires that the compiler invoke the write
> > barrier
> > for each pointer store, then it should honour the contract and do so.
> >
> > If you want to provide an object remembering barrier that the
> > compiler can
> > call as an optimization, then by all means do so, but the GC should
> > not be
> > forced to work around compiler 'optimizations' that break fundamental
> > interface contracts.
> >
> > While object remembering barriers may be adequate for GCV5 there are a
> > large family of GC algorithms that they are inadequate for, including
> > reference counting and concurrent/incremental GCs.
> >
> > regards,
> > Robin
> >
> >> Hi, I found write barrier in DRLVM can't catch all reference fields
> >> updates, and the problem is identified to be caused by new jit opts
> >> that do not observe the write barrier invariant for fields updates.
> >> For example, JIT may generate code to copy consecutive fields of an
> >> object without invoking write barrier. In order to revive the write
> >> barrier functionality while not sacrificing the opt performance, I'd
> >> suggest to introduce an object remember write barrier which will be
> >> invoked after the object is copied. So the JIT doesn't need to insert
> >> barrier for each field store. GC has an interface
> >> gc_heap_wrote_object(p_obj) for this case. I think it's ok to insert
> >> only the runtime native call at first. Then later we can consider to
> >> inline the object remembering barrier as well as the slot remembering
> >> barrier.
> >>
> >> Thanks,
> >> xiaofeng
> >>
> >
> >
>
>
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
What's an object remembering barrier?
On Jan 7, 2007, at 1:59 AM, Robin Garner wrote:
> I disagree. Partly from the point of view of eventual support for
> MMTk,
> but also on more general grounds, in terms of support for future GC
> algorithms.
>
> If the memory manager requires that the compiler invoke the write
> barrier
> for each pointer store, then it should honour the contract and do so.
>
> If you want to provide an object remembering barrier that the
> compiler can
> call as an optimization, then by all means do so, but the GC should
> not be
> forced to work around compiler 'optimizations' that break fundamental
> interface contracts.
>
> While object remembering barriers may be adequate for GCV5 there are a
> large family of GC algorithms that they are inadequate for, including
> reference counting and concurrent/incremental GCs.
>
> regards,
> Robin
>
>> Hi, I found write barrier in DRLVM can't catch all reference fields
>> updates, and the problem is identified to be caused by new jit opts
>> that do not observe the write barrier invariant for fields updates.
>> For example, JIT may generate code to copy consecutive fields of an
>> object without invoking write barrier. In order to revive the write
>> barrier functionality while not sacrificing the opt performance, I'd
>> suggest to introduce an object remember write barrier which will be
>> invoked after the object is copied. So the JIT doesn't need to insert
>> barrier for each field store. GC has an interface
>> gc_heap_wrote_object(p_obj) for this case. I think it's ok to insert
>> only the runtime native call at first. Then later we can consider to
>> inline the object remembering barrier as well as the slot remembering
>> barrier.
>>
>> Thanks,
>> xiaofeng
>>
>
>
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Rana Dasgupta <rd...@gmail.com>.
+1
Whether we wrote it in the contract, I think the assumption was barrier
invocation for each cross-generational reference field update.
The barrier specs come from the memory manager( considering all
issues...scanning cost at collection, size of remembered set, etc. ). The
cost of store checking and JIT opts to mitigate it are secondary issues
IMHO.
On 1/7/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> On 1/7/07, Robin Garner <ro...@anu.edu.au> wrote:
>
> > If the memory manager requires that the compiler invoke the write
> barrier
> > for each pointer store, then it should honour the contract and do so.
>
> If JIT people agree, I am happy to see that. :-)
>
> Thanks,
> xiaofeng
>
> > If you want to provide an object remembering barrier that the compiler
> can
> > call as an optimization, then by all means do so, but the GC should not
> be
> > forced to work around compiler 'optimizations' that break fundamental
> > interface contracts.
> >
> > While object remembering barriers may be adequate for GCV5 there are a
> > large family of GC algorithms that they are inadequate for, including
> > reference counting and concurrent/incremental GCs.
> >
> > regards,
> > Robin
> >
> > > Hi, I found write barrier in DRLVM can't catch all reference fields
> > > updates, and the problem is identified to be caused by new jit opts
> > > that do not observe the write barrier invariant for fields updates.
> > > For example, JIT may generate code to copy consecutive fields of an
> > > object without invoking write barrier. In order to revive the write
> > > barrier functionality while not sacrificing the opt performance, I'd
> > > suggest to introduce an object remember write barrier which will be
> > > invoked after the object is copied. So the JIT doesn't need to insert
> > > barrier for each field store. GC has an interface
> > > gc_heap_wrote_object(p_obj) for this case. I think it's ok to insert
> > > only the runtime native call at first. Then later we can consider to
> > > inline the object remembering barrier as well as the slot remembering
> > > barrier.
> > >
> > > Thanks,
> > > xiaofeng
> > >
> >
> >
> >
>
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 1/7/07, Robin Garner <ro...@anu.edu.au> wrote:
> If the memory manager requires that the compiler invoke the write barrier
> for each pointer store, then it should honour the contract and do so.
If JIT people agree, I am happy to see that. :-)
Thanks,
xiaofeng
> If you want to provide an object remembering barrier that the compiler can
> call as an optimization, then by all means do so, but the GC should not be
> forced to work around compiler 'optimizations' that break fundamental
> interface contracts.
>
> While object remembering barriers may be adequate for GCV5 there are a
> large family of GC algorithms that they are inadequate for, including
> reference counting and concurrent/incremental GCs.
>
> regards,
> Robin
>
> > Hi, I found write barrier in DRLVM can't catch all reference fields
> > updates, and the problem is identified to be caused by new jit opts
> > that do not observe the write barrier invariant for fields updates.
> > For example, JIT may generate code to copy consecutive fields of an
> > object without invoking write barrier. In order to revive the write
> > barrier functionality while not sacrificing the opt performance, I'd
> > suggest to introduce an object remember write barrier which will be
> > invoked after the object is copied. So the JIT doesn't need to insert
> > barrier for each field store. GC has an interface
> > gc_heap_wrote_object(p_obj) for this case. I think it's ok to insert
> > only the runtime native call at first. Then later we can consider to
> > inline the object remembering barrier as well as the slot remembering
> > barrier.
> >
> > Thanks,
> > xiaofeng
> >
>
>
>
Re: [DRLVM][JIT] write barrier broken by new jit opts?
Posted by Robin Garner <ro...@anu.edu.au>.
I disagree. Partly from the point of view of eventual support for MMTk,
but also on more general grounds, in terms of support for future GC
algorithms.
If the memory manager requires that the compiler invoke the write barrier
for each pointer store, then it should honour the contract and do so.
If you want to provide an object remembering barrier that the compiler can
call as an optimization, then by all means do so, but the GC should not be
forced to work around compiler 'optimizations' that break fundamental
interface contracts.
While object remembering barriers may be adequate for GCV5 there are a
large family of GC algorithms that they are inadequate for, including
reference counting and concurrent/incremental GCs.
regards,
Robin
> Hi, I found write barrier in DRLVM can't catch all reference fields
> updates, and the problem is identified to be caused by new jit opts
> that do not observe the write barrier invariant for fields updates.
> For example, JIT may generate code to copy consecutive fields of an
> object without invoking write barrier. In order to revive the write
> barrier functionality while not sacrificing the opt performance, I'd
> suggest to introduce an object remember write barrier which will be
> invoked after the object is copied. So the JIT doesn't need to insert
> barrier for each field store. GC has an interface
> gc_heap_wrote_object(p_obj) for this case. I think it's ok to insert
> only the runtime native call at first. Then later we can consider to
> inline the object remembering barrier as well as the slot remembering
> barrier.
>
> Thanks,
> xiaofeng
>