From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118571 invoked by alias); 10 Nov 2015 17:26:41 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 118074 invoked by uid 89); 10 Nov 2015 17:26:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (207.82.80.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Nov 2015 17:26:39 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-20-9FQbMaPqQgu33txdBvL9iw-1; Tue, 10 Nov 2015 17:26:33 +0000 Received: from [10.2.206.40] ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2015 17:26:33 +0000 Message-ID: <564228C5.4000203@arm.com> Date: Tue, 10 Nov 2015 17:26:00 -0000 From: Szabolcs Nagy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Torvald Riegel , libstdc++ CC: GCC Patches , Jonathan Wakely , Jason Merrill Subject: Re: State of support for the ISO C++ Transactional Memory TS and remanining work References: <1447028347.7192.118.camel@localhost.localdomain> In-Reply-To: <1447028347.7192.118.camel@localhost.localdomain> X-MC-Unique: 9FQbMaPqQgu33txdBvL9iw-1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg01250.txt.bz2 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 =3D 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.