Question about SATB barrier

[Nilsen, Kelvin]

Thanks for this explanation.  It sounds like I'm mostly on the right path still (or at least on a legitimate path).

I'm in the midst of crafting an intergenerational write-barrier implementation that builds on the existing SATB logging code.  I'm adding to the existing log each address that is overwritten in addition to the overwritten pointer values.  I tag the new values so they won't be confused by the GC when it processes the content of the SATB log.  (I've got a prototype working but have not yet covered all of the different code generation models.  I'm currently working on those.)

I probably do not yet fully appreciate all of the subtle nuances associated with the pre-val passed in scenarios.  It looks like some of these situations are going to require some special handling that is not covered by my existing approach.  But I believe those will be relatively rare operations and initial performance measurements to characterize the "cost" of this approach can ignore the special cases.

Please let me know if you anticipate any problems with my general approach.



On 7/19/20, 4:15 AM, "Roman Kennke" <rkennke at redhat.com> wrote:
    Hi Kelvin,

    The form where 'pre-val' is passed as an input instead of loaded from a
    field is used by the cases where the previous-value needs to be
    explicitely kept-alive:

    - Most prominently, in the intrinsics for Reference.get(): we need to
    keep the referent alive because Referent.get() makes it strongly
    reachable, and it may otherwise get lost by SATB
    - Stuff like xchg and cmpxchg, where the previous value is loaded
    anyway, and we only need to enqueue it.
    - a few other cases, especially in the runtime impl

    It is not meant for the compiler-optimization. I believe the compiler
    would figure it out if it can deduce the previously-stored-value in a
    safe way.

    There is also the scenario of the I-U mode. This is basically the
    inverse of SATB, and we always enqueue the update-value of a store.
    There we only ever need the simpler form of the enqueueing barrier. As
    a bonus we don't need to keep-alive Referent.get() there, which means
    we can even reclaim weakrefs that are accessed during conc-mark. Some
    users love that feature ;-)

    Cheers,
    Roman

    On Sat, 2020-07-18 at 23:09 +0000, Nilsen, Kelvin wrote:
    > I've observed that the various SATB barrier implementations have two
    > different forms.
    >
    > In one form, the address to be overwritten is supplied as an argument
    > and the previous content held at that address is fetched and stored
    > into a SATB buffer.  In the other form, the address to be overwritten
    > is not supplied and the "keep-alive" value is supplied as the pre-
    > initialized content of the pre-val register.  In this second form,
    > the content of the pre-val register is stored into the SATB buffer.
    >
    > My question is whether the second form is used with write operations
    > for which the "compiler" is able to determine through static analysis
    > the previous content of the value to be overwritten, or is it used
    > only for other situations that require the logging of a keep-alive
    > pointer value?
    >
    > I have been assuming the latter, but I need to make sure I understand
    > how these two forms are used.
    >
    > Thanks.
    >
    >
    >
    > 
    >