Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #6297

Re: Malloc and transactional memory (TM)

Show all headers | View raw

On 3/7/2012 11:55 AM, George Neuner wrote:
> On Tue, 06 Mar 2012 21:06:52 -0800, "Andy (Super) Glew"
> <andy@SPAM.comp-arch.net>  wrote:
>
>> http://semipublic.comp-arch.net/wiki/Transactional_memory_and_malloc
>>
>> Dynamic memory allocation such as malloc is a classic example of why one
>> may want memory accesses that can leave a transaxction.
>>
>> Consider a simple mallocator, that allocates from a single queue or arena.
>> This might mean that multiple transactions, otherwise completely independent
>> might appear to interfere with each other through malloc.
>
> Yes.  Which is why I think GC really is necessary to effectively
> support transactional memory allocation.
>
> There have been coprocessor implementations of GC memory, but AFAIK,
> none has ever has been combined with HTM.  Although in thinking about
> it, HTM might not be necessary because hardware GC might, in turn,
> make STM performance acceptable.
>
>> Q: what happens when a transaction aborts?
>
> As you noted, with GC, nothing need be done - the next collection will
> reclaim the memory.
>
>> (Q: what about [[deterministic finalization and aborted transactions]]?)
>
> I believe finalization is - and should be - a scoping issue that is
> separate from memory management.  Finalization should occur
> immediately when the object is discarded regardless of whether the
> memory will be immediately reclaimed.  Unfortunately, there is no good
> way to deterministically handle shared objects other than through
> reference counting.  Of course, reference counting also can be
> hardware assisted.

My brain hiccuped:

One may malloc the memory using outside of transaction memory accesses,
but the memory so allocated is probably accesed inside the transaction. 
  So if the transaction aborts, it reverts to whatever
state it had when allocated. (Which should be zeroed...)

Funny stuff if a dynamically allocated object inside a transaction 
points to non-transactional resources that need finalization, and vice 
versa. Probably not a major concern.

If one only has a single strong pointer, scoped, with other weak 
pointers, finalize on deallocatin of the strng pointer.

Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Malloc and transactional memory (TM) "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-03-06 21:06 -0800
  Re: Malloc and transactional memory (TM) MitchAlsup <MitchAlsup@aol.com> - 2012-03-07 09:54 -0800
    Re: Malloc and transactional memory (TM) "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-03-09 11:20 -0800
  Re: Malloc and transactional memory (TM) George Neuner <gneuner2@comcast.net> - 2012-03-07 14:55 -0500
    Re: Malloc and transactional memory (TM) nmm1@cam.ac.uk - 2012-03-07 21:10 +0000
      Re: Malloc and transactional memory (TM) George Neuner <gneuner2@comcast.net> - 2012-03-08 14:23 -0500
        Re: Malloc and transactional memory (TM) nmm1@cam.ac.uk - 2012-03-08 19:58 +0000
          Re: Malloc and transactional memory (TM) George Neuner <gneuner2@comcast.net> - 2012-03-10 16:05 -0500
            Re: Malloc and transactional memory (TM) nmm1@cam.ac.uk - 2012-03-13 08:39 +0000
    Re: Malloc and transactional memory (TM) "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-03-07 22:49 -0800
      Re: Malloc and transactional memory (TM) nmm1@cam.ac.uk - 2012-03-08 08:02 +0000
        Re: Malloc and transactional memory (TM) "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-03-08 07:20 -0800
          Re: Malloc and transactional memory (TM) nmm1@cam.ac.uk - 2012-03-08 16:25 +0000
            Re: Malloc and transactional memory (TM) MitchAlsup <MitchAlsup@aol.com> - 2012-03-11 09:27 -0700

csiph-web