State of support for the ISO C++ Transactional Memory TS and remanining work

State of support for the ISO C++ Transactional Memory TS and remanining work

[Torvald Riegel]

[-- Attachment #1: Type: text/plain, Size: 4391 bytes --]

Hi,

I'd like to summarize the current state of support for the TM TS, and
outline the current plan for the work that remains to complete the
support.

I'm aware we're at the end of stage 1, but I'm confident we can still
finish this work and hope to include it in GCC 6 because:
(1) most of the support is already in GCC, and we have a big head start
in the space of TM so it would be unfortunate to not waste that by not
delivering support for the TM TS,
(2) this is a TS and support for it is considered experimental,
(3) most of the affected code is in libitm or the compiler's TM passes,
which has to be enabled explicitly by the user.

Currently, we have complete support for the syntax and all necessary
instrumentation except the exception handling bits listed below.  libitm
has a good set of STM and HTM-based algorithms.


What is missing on the compiler side is essentially a change of how we
support atomic_noexcept and atomic_cancel, in particular exception
handling.  Instead of just using a finally block as done currently, the
compiler need to build a catch clause so that it can actively intercept
exceptions that escape an atomic_noexcept or atomic_cancel.  For
atomic_noexcept, the compiler needs to include a call to abort() in the
catch clause.


For atomic_cancel, it needs to call ITM_commitTransactionEH in the catch
clause, and use NULL as exception argument.  This can then be used by
libitm to look at the currently being handled exception and (a) check
whether the type support transaction cancellation as specified by the TS
and (b) pick out the allocations that belong to this exception and roll
back everything else before rethrowing this exception.

For (a), it's probably best to place this check into libstdc++
(specifically, libsupc++ I suppose) because support for transaction
cancellation is a property that library parts of the standard (or the
TS) require, and that has to match the implementation in libstdc++.
Attached is a patch by Jason that implements this check.  This adds one
symbol, which should be okay we hope.

For (b), our plan is to track the additional allocations that happen
when during construction of the exception types that support
cancellation (eg, creating the what() string for logic_error).  There
are several ways to do that, one of that being that we create custom
transactional clones of those constructors that tell libitm that either
such a constructor is currently running or explicitly list the
allocations that have been made by the constructor; eventually, we would
always (copy) construct into memory returned by cxa_allocate_exception,
which then makes available the necessary undo information when such an
exception is handled in libitm.


The other big piece of missing support is making sure that the functions
that are specified in the TS as transaction_safe are indeed that.  I
believe we do not need to actually add such annotations to any libstdc++
functions that are already transaction-safe and completely defined in
headers -- those functions are implicitly transaction-safe, and we can
thus let the compiler isntrument them at the point of use inside of a
transaction.

If a supposedly transaction-safe function is not defined in a header,
we'd need a transaction_safe annotation at the declaration.  Jason has
implemented the TM TS feature test macro, so we can only add the
annotation if the user has enabled support for the TM TS in the
respective compilation process.
We also need ensure that there is a transaction clode of the function.
This will add symbols to libstdc++, but these all have their own special
prefix in the mangled name.  I'd like to get feedback on how to best
trigger the insturmentation and make it a part of a libstdc++ build.
(If that would show to be too problematic, we could still fall back to
writing transacitonal clones manually.)
For the clones of the constructors of the types that support
cancellation, I suppose manually written clones might be easier than
automatic instrumentation.

I've not yet created tests for the full list of functions specified as
transaction-safe in the TS, but my understanding is that this list was
created after someone from the ISO C++ TM study group looked at libstdc
++'s implementation and investigated which functions might be feasible
to be declared transaction-safe in it.

I'm looking forward to your feedback.

Thanks,

Torvald

[-- Attachment #2: eh_tx_cancel.cc --]
[-- Type: text/x-c++src, Size: 2362 bytes --]

// -*- C++ -*- GNU C++ atomic_cancel support.
// Copyright (C) 2015 Free Software Foundation, Inc.
//
// This file is part of GCC.
//
// GCC is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation; either version 3, or (at your option)
// any later version.
//
// GCC is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.
//
// Under Section 7 of GPL version 3, you are granted additional
// permissions described in the GCC Runtime Library Exception, version
// 3.1, as published by the Free Software Foundation.

// You should have received a copy of the GNU General Public License and
// a copy of the GCC Runtime Library Exception along with this program;
// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
// <http://www.gnu.org/licenses/>.

#include <bits/c++config.h>
#include <cstdlib>
#include <cxxabi.h>
#include <exception>
#include <stdexcept>
#include <new>
#include <typeinfo>
#include <string.h>

bool
__cxxabiv1::__cxa_exception_supports_tx_cancel()
{
  const std::type_info *tinfo = __cxa_current_exception_type();
  if (!dynamic_cast <const __class_type_info*>(tinfo))
    // All scalar types support transaction cancellation.
    return true;

  // But only specific classes support tx cancel.
  const char *name = tinfo->name();

  // First check for std::
  if (name[0] != 'S' || name[1] != 't')
    return false;
  name += 2;

  const char txe[] = "12tx_exceptionI";
  if (!strncmp (name, txe, strlen(txe))
      || !strcmp (name, "8bad_cast")
      || !strcmp (name, "9bad_alloc")
      || !strcmp (name, "10bad_typeid")
      || !strcmp (name, "11logic_error")
      || !strcmp (name, "11range_error")
      || !strcmp (name, "12domain_error")
      || !strcmp (name, "12length_error")
      || !strcmp (name, "12out_of_range")
      || !strcmp (name, "13bad_exception")
      || !strcmp (name, "13runtime_error")
      || !strcmp (name, "14overflow_error")
      || !strcmp (name, "15underflow_error")
      || !strcmp (name, "16invalid_argument")
      || !strcmp (name, "20bad_array_new_length"))
    return true;

  return false;
}

Re: State of support for the ISO C++ Transactional Memory TS and remanining work

[Szabolcs Nagy]

On 09/11/15 00:19, Torvald Riegel wrote:
> Hi,
>
> I'd like to summarize the current state of support for the TM TS, and
> outline the current plan for the work that remains to complete the
> support.
>
> I'm aware we're at the end of stage 1, but I'm confident we can still
> finish this work and hope to include it in GCC 6 because:
> (1) most of the support is already in GCC, and we have a big head start
> in the space of TM so it would be unfortunate to not waste that by not
> delivering support for the TM TS,
> (2) this is a TS and support for it is considered experimental,
> (3) most of the affected code is in libitm or the compiler's TM passes,
> which has to be enabled explicitly by the user.
>
> Currently, we have complete support for the syntax and all necessary
> instrumentation except the exception handling bits listed below.  libitm
> has a good set of STM and HTM-based algorithms.
>
>
> What is missing on the compiler side is essentially a change of how we
> support atomic_noexcept and atomic_cancel, in particular exception
> handling.  Instead of just using a finally block as done currently, the
> compiler need to build a catch clause so that it can actively intercept
> exceptions that escape an atomic_noexcept or atomic_cancel.  For
> atomic_noexcept, the compiler needs to include a call to abort() in the
> catch clause.
>
>
> For atomic_cancel, it needs to call ITM_commitTransactionEH in the catch
> clause, and use NULL as exception argument.  This can then be used by
> libitm to look at the currently being handled exception and (a) check
> whether the type support transaction cancellation as specified by the TS
> and (b) pick out the allocations that belong to this exception and roll
> back everything else before rethrowing this exception.
>
> For (a), it's probably best to place this check into libstdc++
> (specifically, libsupc++ I suppose) because support for transaction
> cancellation is a property that library parts of the standard (or the
> TS) require, and that has to match the implementation in libstdc++.
> Attached is a patch by Jason that implements this check.  This adds one
> symbol, which should be okay we hope.
>

does that mean libitm will depend on libstdc++?

i think the tm runtime should not depend on c++,
so it is usable from c code.

> For (b), our plan is to track the additional allocations that happen
> when during construction of the exception types that support
> cancellation (eg, creating the what() string for logic_error).  There
> are several ways to do that, one of that being that we create custom
> transactional clones of those constructors that tell libitm that either
> such a constructor is currently running or explicitly list the
> allocations that have been made by the constructor; eventually, we would
> always (copy) construct into memory returned by cxa_allocate_exception,
> which then makes available the necessary undo information when such an
> exception is handled in libitm.
>
>
> The other big piece of missing support is making sure that the functions
> that are specified in the TS as transaction_safe are indeed that.  I
> believe we do not need to actually add such annotations to any libstdc++
> functions that are already transaction-safe and completely defined in
> headers -- those functions are implicitly transaction-safe, and we can
> thus let the compiler isntrument them at the point of use inside of a
> transaction.
>
> If a supposedly transaction-safe function is not defined in a header,
> we'd need a transaction_safe annotation at the declaration.  Jason has
> implemented the TM TS feature test macro, so we can only add the
> annotation if the user has enabled support for the TM TS in the
> respective compilation process.

sounds ugly: the function type (transaction-safety)
depends on the visibility of the definition..

> We also need ensure that there is a transaction clode of the function.
> This will add symbols to libstdc++, but these all have their own special
> prefix in the mangled name.  I'd like to get feedback on how to best
> trigger the insturmentation and make it a part of a libstdc++ build.
> (If that would show to be too problematic, we could still fall back to
> writing transacitonal clones manually.)
> For the clones of the constructors of the types that support
> cancellation, I suppose manually written clones might be easier than
> automatic instrumentation.
>
> I've not yet created tests for the full list of functions specified as
> transaction-safe in the TS, but my understanding is that this list was
> created after someone from the ISO C++ TM study group looked at libstdc
> ++'s implementation and investigated which functions might be feasible
> to be declared transaction-safe in it.
>

is that list available somewhere?

libitm seems to try to allow allocating functions in
transactions, but syscalls are not supposed to be
transaction safe.

are allocating functions prohibited?

> I'm looking forward to your feedback.
>
> Thanks,
>
> Torvald
>

i'm not familiar with libitm, but i see several implementation
issues:

xmalloc
   the runtime exits on memory allocation failure,
   so it is not possible to use it safely.
   (i think it should be possible to roll back the
   transaction in case of internal allocation failure
   and retry with a strategy that does not need dynamic
   allocation).

GTM_error, GTM_fatal
   the runtime may print error messages to stderr.
   stderr is owned by the application.

hw details
   i'm not sure if cacheline size is just an optimization
   here or if the hw tm implementations depend on it.
   detecting such details correctly at runtime can be ugly..
   (the ppc/s390 code call getauxval, that is not in the
   iso c/c++ implementation reserved namespace.)

uint64_t GTM::gtm_spin_count_var = 1000;
   i guess this was supposed to be tunable.
   it seems libitm needs some knobs (strategy, retries,
   spin counts), but there is no easy way to adapt these
   for a target/runtime environment.

memory footprint
   there is large amount of global data, e.g.
   #define LOCK_ARRAY_SIZE  (1024 * 1024)
   extern gtm_stmlock gtm_stmlock_array[LOCK_ARRAY_SIZE];
   ..and per thread data in gtm_thread with unbounded undolog
   and nested transaction checkpoints.

stack_top/bottom
   when filtering out memory operations during rollback
   that would change the stack:

   if there are objects immediately below the stack then sp-256
   is not a valid limit, but i think it makes sense to expect
   at least one guard page there + space for signal delivery
   and then 256 can be bigger (e.g. PAGE_SIZE).

sys_futex0
   i'm not sure why this has arch specific implementations
   for some targets but not others. (syscall is not in the
   implementation reserved namespace).

   gtm_futex_wait/wake are updated in a non-atomic way.

these are the issues i noticed that may matter if this
is going to be a supported compiler runtime.

Re: State of support for the ISO C++ Transactional Memory TS and remanining work

[Torvald Riegel]

On Tue, 2015-11-10 at 17:26 +0000, Szabolcs Nagy wrote:
> On 09/11/15 00:19, Torvald Riegel wrote:
> > Hi,
> >
> > I'd like to summarize the current state of support for the TM TS, and
> > outline the current plan for the work that remains to complete the
> > support.
> >
> > I'm aware we're at the end of stage 1, but I'm confident we can still
> > finish this work and hope to include it in GCC 6 because:
> > (1) most of the support is already in GCC, and we have a big head start
> > in the space of TM so it would be unfortunate to not waste that by not
> > delivering support for the TM TS,
> > (2) this is a TS and support for it is considered experimental,
> > (3) most of the affected code is in libitm or the compiler's TM passes,
> > which has to be enabled explicitly by the user.
> >
> > Currently, we have complete support for the syntax and all necessary
> > instrumentation except the exception handling bits listed below.  libitm
> > has a good set of STM and HTM-based algorithms.
> >
> >
> > What is missing on the compiler side is essentially a change of how we
> > support atomic_noexcept and atomic_cancel, in particular exception
> > handling.  Instead of just using a finally block as done currently, the
> > compiler need to build a catch clause so that it can actively intercept
> > exceptions that escape an atomic_noexcept or atomic_cancel.  For
> > atomic_noexcept, the compiler needs to include a call to abort() in the
> > catch clause.
> >
> >
> > For atomic_cancel, it needs to call ITM_commitTransactionEH in the catch
> > clause, and use NULL as exception argument.  This can then be used by
> > libitm to look at the currently being handled exception and (a) check
> > whether the type support transaction cancellation as specified by the TS
> > and (b) pick out the allocations that belong to this exception and roll
> > back everything else before rethrowing this exception.
> >
> > For (a), it's probably best to place this check into libstdc++
> > (specifically, libsupc++ I suppose) because support for transaction
> > cancellation is a property that library parts of the standard (or the
> > TS) require, and that has to match the implementation in libstdc++.
> > Attached is a patch by Jason that implements this check.  This adds one
> > symbol, which should be okay we hope.
> >
> 
> does that mean libitm will depend on libstdc++?

No, weak references are used to avoid that.  See libitm/eh_cpp.cc for
example.

> i think the tm runtime should not depend on c++,
> so it is usable from c code.
> 
> > For (b), our plan is to track the additional allocations that happen
> > when during construction of the exception types that support
> > cancellation (eg, creating the what() string for logic_error).  There
> > are several ways to do that, one of that being that we create custom
> > transactional clones of those constructors that tell libitm that either
> > such a constructor is currently running or explicitly list the
> > allocations that have been made by the constructor; eventually, we would
> > always (copy) construct into memory returned by cxa_allocate_exception,
> > which then makes available the necessary undo information when such an
> > exception is handled in libitm.
> >
> >
> > The other big piece of missing support is making sure that the functions
> > that are specified in the TS as transaction_safe are indeed that.  I
> > believe we do not need to actually add such annotations to any libstdc++
> > functions that are already transaction-safe and completely defined in
> > headers -- those functions are implicitly transaction-safe, and we can
> > thus let the compiler isntrument them at the point of use inside of a
> > transaction.
> >
> > If a supposedly transaction-safe function is not defined in a header,
> > we'd need a transaction_safe annotation at the declaration.  Jason has
> > implemented the TM TS feature test macro, so we can only add the
> > annotation if the user has enabled support for the TM TS in the
> > respective compilation process.
> 
> sounds ugly: the function type (transaction-safety)
> depends on the visibility of the definition..

I don't understand why that would be the case.  The TS specifies whether
a function has to be safe or not.  We strive to implement that to
support the TS.  Nonetheless, the TS also has the notion of a function
being implicitly transaction-safe (ie, if the compiler can check that it
is, it can be used as-if annotated as transacton-safe even if it
actually isn't).
Also note that you can't overload based on transaction-safe or not, so
it's not something you can check without compilation failures or your
program aborting.

> > We also need ensure that there is a transaction clode of the function.
> > This will add symbols to libstdc++, but these all have their own special
> > prefix in the mangled name.  I'd like to get feedback on how to best
> > trigger the insturmentation and make it a part of a libstdc++ build.
> > (If that would show to be too problematic, we could still fall back to
> > writing transacitonal clones manually.)
> > For the clones of the constructors of the types that support
> > cancellation, I suppose manually written clones might be easier than
> > automatic instrumentation.
> >
> > I've not yet created tests for the full list of functions specified as
> > transaction-safe in the TS, but my understanding is that this list was
> > created after someone from the ISO C++ TM study group looked at libstdc
> > ++'s implementation and investigated which functions might be feasible
> > to be declared transaction-safe in it.
> >
> 
> is that list available somewhere?

See the TM TS, N4514.

> libitm seems to try to allow allocating functions in
> transactions, but syscalls are not supposed to be
> transaction safe.
> 
> are allocating functions prohibited?

No, and it also doesn't mean that syscalls need to be transaction-safe.
libitm has wrappers for allocation functions that make allocation and
deallocation transaction-safe, effectively.

> i'm not familiar with libitm, but i see several implementation
> issues:
> 
> xmalloc
>    the runtime exits on memory allocation failure,
>    so it is not possible to use it safely.
>    (i think it should be possible to roll back the
>    transaction in case of internal allocation failure
>    and retry with a strategy that does not need dynamic
>    allocation).

Not sure what you mean by "safely".  Hardening against out-of-memory
situations hasn't been considered to be of high priority so far, but I'd
accept patches for that that don't increase complexity signifantly and
don't hamper performance.

> GTM_error, GTM_fatal
>    the runtime may print error messages to stderr.
>    stderr is owned by the application.

We need to report errors in some way, especially with something that's
still experimental such as TM.  Alternatives are using C++ exceptions to
report errors, but we'd still need something else for C, such as
handlers that the program can control.

> hw details
>    i'm not sure if cacheline size is just an optimization
>    here or if the hw tm implementations depend on it.
>    detecting such details correctly at runtime can be ugly..
>    (the ppc/s390 code call getauxval, that is not in the
>    iso c/c++ implementation reserved namespace.)

Just an optimization, of cause.

> uint64_t GTM::gtm_spin_count_var = 1000;
>    i guess this was supposed to be tunable.
>    it seems libitm needs some knobs (strategy, retries,
>    spin counts), but there is no easy way to adapt these
>    for a target/runtime environment.

Sure, more performance tuning knobs would be nice.

> memory footprint
>    there is large amount of global data, e.g.
>    #define LOCK_ARRAY_SIZE  (1024 * 1024)

That's just there for some TM methods.  There are ways to reduce that by
using different hash functions (see my PhD thesis, FWIW), but I haven't
implemented this yet.

>    extern gtm_stmlock gtm_stmlock_array[LOCK_ARRAY_SIZE];
>    ..and per thread data in gtm_thread with unbounded undolog
>    and nested transaction checkpoints.

You can't avoid that.  The program is asking for transactions that can
be rolled back (either because it wants to roll them back explicitly, or
for performance reasons) -- so it gets what it asked for when it tries
to run huge transactions.  Sure there could be a tuning know for
swithcing to a TM method that goes serial after a certian space
overhead; but I haven't seen requests for that, and transactions are
supposed to be rather small than large anyway.

> stack_top/bottom
>    when filtering out memory operations during rollback
>    that would change the stack:
> 
>    if there are objects immediately below the stack then sp-256
>    is not a valid limit, but i think it makes sense to expect
>    at least one guard page there + space for signal delivery
>    and then 256 can be bigger (e.g. PAGE_SIZE).

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51855

> sys_futex0
>    i'm not sure why this has arch specific implementations
>    for some targets but not others. (syscall is not in the
>    implementation reserved namespace).

Are there archs that support libitm but don't have a definition of this
one?

>    gtm_futex_wait/wake are updated in a non-atomic way.

Agreed.  Shouldn't trigger an error, but are data races nonetheless.

> these are the issues i noticed that may matter if this
> is going to be a supported compiler runtime.

What do you mean by that precisely?  For it to become non-experimental?


Patches welcome! :)

Re: State of support for the ISO C++ Transactional Memory TS and remanining work

[Szabolcs Nagy]

On 10/11/15 18:29, Torvald Riegel wrote:
> On Tue, 2015-11-10 at 17:26 +0000, Szabolcs Nagy wrote:
>> On 09/11/15 00:19, Torvald Riegel wrote:
>>> Hi,
>>>
>>> I'd like to summarize the current state of support for the TM TS, and
>>> outline the current plan for the work that remains to complete the
>>> support.
>>>
...
>>> Attached is a patch by Jason that implements this check.  This adds one
>>> symbol, which should be okay we hope.
>>>
>>
>> does that mean libitm will depend on libstdc++?
>
> No, weak references are used to avoid that.  See libitm/eh_cpp.cc for
> example.
>

i see.

>>> I've not yet created tests for the full list of functions specified as
>>> transaction-safe in the TS, but my understanding is that this list was
>>> created after someone from the ISO C++ TM study group looked at libstdc
>>> ++'s implementation and investigated which functions might be feasible
>>> to be declared transaction-safe in it.
>>>
>>
>> is that list available somewhere?
>
> See the TM TS, N4514.
>

i was looking at an older version,
things make more sense now.

i think system() should not be transaction safe..

i wonder what's the plan for getting libc functions
instrumented (i assume that is needed unless hw
support is used).

>> xmalloc
>>     the runtime exits on memory allocation failure,
>>     so it is not possible to use it safely.
>>     (i think it should be possible to roll back the
>>     transaction in case of internal allocation failure
>>     and retry with a strategy that does not need dynamic
>>     allocation).
>
> Not sure what you mean by "safely".  Hardening against out-of-memory
> situations hasn't been considered to be of high priority so far, but I'd
> accept patches for that that don't increase complexity signifantly and
> don't hamper performance.
>

i consider this a library safety issue.

(a library or runtime is not safe to use if it may terminate
the process in case of internal failures.)

>> GTM_error, GTM_fatal
>>     the runtime may print error messages to stderr.
>>     stderr is owned by the application.
>
> We need to report errors in some way, especially with something that's
> still experimental such as TM.  Alternatives are using C++ exceptions to
> report errors, but we'd still need something else for C, such as
> handlers that the program can control.
>

ok, i thought the plan was to move this out of the
experimental state now.

>> uint64_t GTM::gtm_spin_count_var = 1000;
>>     i guess this was supposed to be tunable.
>>     it seems libitm needs some knobs (strategy, retries,
>>     spin counts), but there is no easy way to adapt these
>>     for a target/runtime environment.
>
> Sure, more performance tuning knobs would be nice.
>

my problem was with getting the knobs right at runtime.

(i think this will need a solution to make tm practically
useful, there are settings that seem to be sensitive to
the properties of the underlying hw.. this also seems
to be a problem for glibc lock elision retry policies.)

>> sys_futex0
>>     i'm not sure why this has arch specific implementations
>>     for some targets but not others. (syscall is not in the
>>     implementation reserved namespace).
>
> Are there archs that support libitm but don't have a definition of this
> one?
>

i thought all targets were supported on linux
(the global lock based strategies should work)
i can prepare a sys_futex0 for arm and aarch64.

>> these are the issues i noticed that may matter if this
>> is going to be a supported compiler runtime.
>
> What do you mean by that precisely?  For it to become non-experimental?
>

yes, non-experimental
(since you were talking about libstdc++ changes to
complete the support for the TS).

Re: State of support for the ISO C++ Transactional Memory TS and remanining work

[Jonathan Wakely]

On 11/11/15 15:04 +0000, Szabolcs Nagy wrote:
>yes, non-experimental
>(since you were talking about libstdc++ changes to
>complete the support for the TS).

The TS is experimental. That's the nature of all C++ TSs.

Completing the TS support does not mean anything is non-experimental.

Re: State of support for the ISO C++ Transactional Memory TS and remanining work

[Torvald Riegel]

On Wed, 2015-11-11 at 15:04 +0000, Szabolcs Nagy wrote:
> On 10/11/15 18:29, Torvald Riegel wrote:
> > On Tue, 2015-11-10 at 17:26 +0000, Szabolcs Nagy wrote:
> >> On 09/11/15 00:19, Torvald Riegel wrote:
> >>> I've not yet created tests for the full list of functions specified as
> >>> transaction-safe in the TS, but my understanding is that this list was
> >>> created after someone from the ISO C++ TM study group looked at libstdc
> >>> ++'s implementation and investigated which functions might be feasible
> >>> to be declared transaction-safe in it.
> >>>
> >>
> >> is that list available somewhere?
> >
> > See the TM TS, N4514.
> >
> 
> i was looking at an older version,
> things make more sense now.
> 
> i think system() should not be transaction safe..
> 
> i wonder what's the plan for getting libc functions
> instrumented (i assume that is needed unless hw
> support is used).

No specific plans so far.  We'll wait and see, I guess.  TM is still in
a chicken-and-egg situation.

> >> xmalloc
> >>     the runtime exits on memory allocation failure,
> >>     so it is not possible to use it safely.
> >>     (i think it should be possible to roll back the
> >>     transaction in case of internal allocation failure
> >>     and retry with a strategy that does not need dynamic
> >>     allocation).
> >
> > Not sure what you mean by "safely".  Hardening against out-of-memory
> > situations hasn't been considered to be of high priority so far, but I'd
> > accept patches for that that don't increase complexity signifantly and
> > don't hamper performance.
> >
> 
> i consider this a library safety issue.
> 
> (a library or runtime is not safe to use if it may terminate
> the process in case of internal failures.)

If it is truly a purely internal failure, then aborting might be the
best thing one can do if there is no sensible way to try to recover from
the error (ie, take a fail-fast approach).
Out-of-memory errors are not purely internal failures.  I agree that it
would be nice to have a fallback, but for some features there simply is
none (eg, the program can't require rollback to be possible and yet not
provide enough memory for this to be achievable).  Given that this
transactions have to be used from C programs too, there's not much
libitm can do except perhaps call user-supplied handlers.

> >> uint64_t GTM::gtm_spin_count_var = 1000;
> >>     i guess this was supposed to be tunable.
> >>     it seems libitm needs some knobs (strategy, retries,
> >>     spin counts), but there is no easy way to adapt these
> >>     for a target/runtime environment.
> >
> > Sure, more performance tuning knobs would be nice.
> >
> 
> my problem was with getting the knobs right at runtime.
> 
> (i think this will need a solution to make tm practically
> useful, there are settings that seem to be sensitive to
> the properties of the underlying hw.. this also seems
> to be a problem for glibc lock elision retry policies.)

Yes, that applies to many tuning settings in lots of places.  And
certainly to TM implementations too :)

> >> sys_futex0
> >>     i'm not sure why this has arch specific implementations
> >>     for some targets but not others. (syscall is not in the
> >>     implementation reserved namespace).
> >
> > Are there archs that support libitm but don't have a definition of this
> > one?
> >
> 
> i thought all targets were supported on linux
> (the global lock based strategies should work)
> i can prepare a sys_futex0 for arm and aarch64.

arm and aarch64 should be supported according to configure.tgt.  Also
see the comment in config/linux/futex_bits.h if you want to change
something there.  I haven't tried arm at all so far.