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


Groups > comp.arch > #6322

Re: Malloc and transactional memory (TM)

From MitchAlsup <MitchAlsup@aol.com>
Newsgroups comp.arch
Subject Re: Malloc and transactional memory (TM)
Date 2012-03-11 09:27 -0700
Organization http://groups.google.com
Message-ID <1435433.487.1331483224411.JavaMail.geo-discussion-forums@ynca15> (permalink)
References <4F56ECEC.8060800@SPAM.comp-arch.net> <4F58567A.3000605@SPAM.comp-arch.net> <jj9p2i$6ao$1@gosset.csi.cam.ac.uk> <4F58CE49.2080108@SPAM.comp-arch.net> <jjamil$ihu$1@gosset.csi.cam.ac.uk>

Show all headers | View raw


On Thursday, March 8, 2012 10:25:57 AM UTC-6, nm...@cam.ac.uk wrote:
> In article <>,
> Andy (Super) Glew <> wrote:
> >>>>
> >>>>> (Q: what about [[deterministic finalization and aborted transactions]]?)
> >
> >>> If one only has a single strong pointer, scoped, with other weak
> >>> pointers, finalize on deallocatin of the strng pointer.
> >>
> >> Yes.  Unfortunately, though it is well hidden, one of the implications
> >> of the modern approach to garbage collection is that most pointers
> >> should NOT be scoped!  I.e. the lifetime is not lexical, but until
> >> the last reference disappears - and, as I said, that is in general
> >> not determinable without a complete, synchronised garbage collection.
> >
> >Which is the whole pointer of having string and weak pointers.
> 
> Well, sort-of.  Unfortunately, that doesn't help, unless you also
> enforce determinable scoping rules on strong pointers, which is
> rarely done.  I agree that it could be.
> 
> But my point was and is that the modern approach to garbage collection
> won't bite that bullet, and so your approach won't work together with
> it.

two thoughts come to mind:

A) the PL/1 Area: where one defines an Area and then mallocs from within that area, and at the end of the transaction the entire area can be deallocated en-massé.

B) fork off a task to perform the transaction and pass back the new data to the master process via a pipe and have the malloced area disappear with the task when it dies.

Neither require GC of the malloced area, both have additionial overheads. Whether the overheads are greater than the GC overhead is unknown.

Mitch

Back to comp.arch | Previous | NextPrevious 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