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

Groups > comp.arch > #6284 > unrolled thread

Malloc and transactional memory (TM)

Back to article view | Back to comp.arch

Contents

  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

#6284 — Malloc and transactional memory (TM)

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.

(This interference might take several forms.
E.g. if the transactions are first performed totally independently, they 
may allocate the same memory.
E.g. or if the transactions malloc separate areas, but sequentially 
dependent, rollback of one might require rollback of the other.
(Although even this is an advanced TM topic, if the footprints overlap.))

Certainly, there can be malloc algorithms that minimize this - e.g. 
multiple areas, increasing the chance that different transactions might 
not interfere.

Or... the topic of this page:  permit malloc to exit the transaction
- so the [[parallel or concurrent]] mallocs may be properly 
synchronized, and receive independent memory addresses.

Q: what happens when a transaction aborts?
* Possibly could free the memory in the abort handler.  But this becomes 
less hardware, and more software TM.  Or at least a hybrid.
* Let garbage collection recover the memory speculative allocated within 
an aborted transaction.

(Q: what about [[deterministic finalization and aborted transactions]]?)


= Related Topics =

* [[speculative multithreading and memory allocation]]:
** [[malloc and speculative multithreading]]
** [[stack allocation and speculative multithreading]]

[toc] | [next] | [standalone]

#6290

On Tuesday, March 6, 2012 11:06:52 PM UTC-6, Andy (Super) Glew 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.

I would use the term: access memory without transactional overhead. <or similar>

This was one of the key reason that ASF makes the SW define those lines that are participating in an atomic event explicitly, so the rest of the memory references could be assumed to be not participating.

Mitch

[toc] | [prev] | [next] | [standalone]

#6319

On Mar 7, 12:54 pm, MitchAlsup <MitchAl...@aol.com> wrote:
> On Tuesday, March 6, 2012 11:06:52 PM UTC-6, Andy (Super) Glew 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.
>
> I would use the term: access memory without transactional overhead. <or similar>

Perhaps "that can bypass a transaction" might be better,
but I think "non-transactional memory accesses within a
transaction" might be even better.

> This was one of the key reason that ASF makes the SW
> define those lines that are participating in an atomic
> event explicitly, so the rest of the memory references
> could be assumed to be not participating.

That aspect _is_ nice (and did not require adding yet
another prefix), though using undecorated loads and
stores (as in Intel's TSX) has the advantage of allowing
the same code to be used for a transaction or a locked
sequence without extra overhead.  (The ability to
release cache blocks was also interesting, though I do
not know how practical it would be to use such.)

[toc] | [prev] | [next] | [standalone]

#6293

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.

George

[toc] | [prev] | [next] | [standalone]

#6294

In article <j2dfl7p7h04a7f2vr5n5tg0lhp6mubibvd@4ax.com>,
George Neuner  <gneuner2@comcast.net> 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.  

That doesn't actually solve the problem, but only removes a few
cases.  Garbage collection is rarely a solution to a problem;
at best, it hides problems.  Inter alia, the timing and properties
of the garbage collector still cause interference as soon as the
memory limits become an issue.

>>Q: what happens when a transaction aborts?
>
>As you noted, with GC, nothing need be done - the next collection will
>reclaim the memory.

Again, that doesn't actually solve the problem, because that leaves
a window of vulnerability.  In any case, in general with transactions,
memory is only the simplest of the resources that need attention.

>>(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.

In a C-like language, that isn't determinable without performing
the garbage collection!  Think of a top-level object that points
to a recursive data structure.  Is it the last such one?  Use
counts won't help.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#6308

On Wed, 7 Mar 2012 21:10:09 +0000 (GMT), nmm1@cam.ac.uk wrote:

>In article <j2dfl7p7h04a7f2vr5n5tg0lhp6mubibvd@4ax.com>,
>George Neuner  <gneuner2@comcast.net> wrote:
>>On Tue, 06 Mar 2012 21:06:52 -0800, "Andy (Super) Glew"
>>
>>>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.  
>
>That doesn't actually solve the problem, but only removes a few
>cases.  Garbage collection is rarely a solution to a problem;
>at best, it hides problems.  

GC is misunderstood and abused.  Like a lot of other technology.

GC is a viable solution to two particular problems:
 - reclamation of shared and/or recursive allocations
 - heap fragmentation resulting from intermixed allocations.

Andy's question addressed heap fragmentation.

I have no experience with *hardware* TM systems, but I have graduate
degrees in DBMS/data modeling and in language implementation.
Professionally, I have implemented transaction systems for DBMS, and
separately I have implemented STM and GC for language runtime support.
I haven't combined STM and GC, but I don't see any problem in doing
so.


>Inter alia, the timing and properties
>of the garbage collector still cause interference as soon as the
>memory limits become an issue.

There are parallel/incremental GC algorithms which have deterministic
operation.  In the absence of VMM, these algorithms are suitable for
use in *hard* real time systems (assuming, of course, that the timing
constraints of the application will accommodate the GC overhead.)

There already have been hardware assisted coprocessor GC systems
implemented on top of tagged memory.

No management scheme can guarantee that a finite resource won't be
exhausted, but it is relatively easy to guarantee that GC won't fall
behind processing and fail to provide memory that should be available.


>>>Q: what happens when a transaction aborts?
>>
>>As you noted, with GC, nothing need be done - the next collection will
>>reclaim the memory.
>
>Again, that doesn't actually solve the problem, because that leaves
>a window of vulnerability.  In any case, in general with transactions,
>memory is only the simplest of the resources that need attention.

I didn't say GC was a general resource management solution ... you
inferred that.  In any case, if you won't elaborate your concerns, I
can't possibly address them.  


>>>(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.
>
>In a C-like language, that isn't determinable without performing
>the garbage collection!  Think of a top-level object that points
>to a recursive data structure.  Is it the last such one?  Use
>counts won't help.

Incorrect.  It is possible to associatively track shared use of a
recursive structure through independent references.  It isn't done
because it is far more expensive in complexity, in time and in
auxiliary structures required than is connectivity tracing.

Finalization *is* completely separable from storage reclamation.  It
isn't done simply because it is inconvenient to do so.

>Regards,
>Nick Maclaren.

George

[toc] | [prev] | [next] | [standalone]

#6310

In article <9qphl7psjfso6o02eicnulln5pm9kffv1g@4ax.com>,
George Neuner  <gneuner2@comcast.net> wrote:
>
>>Inter alia, the timing and properties
>>of the garbage collector still cause interference as soon as the
>>memory limits become an issue.
>
>There are parallel/incremental GC algorithms which have deterministic
>operation.  In the absence of VMM, these algorithms are suitable for
>use in *hard* real time systems (assuming, of course, that the timing
>constraints of the application will accommodate the GC overhead.)

Only for deterministic parallel applications, which are a very small
subset of even current parallel applications.  If you can provide a
deterministic solution to a general non-deterministic problem, then
should apply for your promotion to Full Deity immediately.

>>>>(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.
>>
>>In a C-like language, that isn't determinable without performing
>>the garbage collection!  Think of a top-level object that points
>>to a recursive data structure.  Is it the last such one?  Use
>>counts won't help.
>
>Incorrect.  It is possible to associatively track shared use of a
>recursive structure through independent references.  It isn't done
>because it is far more expensive in complexity, in time and in
>auxiliary structures required than is connectivity tracing.

Which is equivalent in effort to performing a full garbage collection!
In any case, it STILL doesn't solve the finalisation problem for
objects that are finalised when they become inaccessible.  A trivial
counter-example is the following:

    Each of N threads creates an object with a finaliser, and puts
a pointer to it on its own stack.
    They then barrier synchronise, and link those objects into a
circle (not removing the stack link).
    They then do their work on the objects, and return past the
stack frame where they created them, NOT synchronising before they
do that.

It is obvious that the objects become inaccessible at a point that
is indeterminate in all threads, and cannot be made determinate
without adding synchronisation or ordering threads.  And it makes
NO difference what form of usage tracking you use, because the
problem is inherent in the model.

>Finalization *is* completely separable from storage reclamation.  It
>isn't done simply because it is inconvenient to do so.

As Andy and I posted, it can be separated ONLY by constraining
languages - in the modern C++/GC approach, it isn't.  If you still
think that it's possible, why not tell WG21 how to do it?


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#6321

On Thu, 8 Mar 2012 19:58:36 +0000 (GMT), nmm1@cam.ac.uk wrote:

>In article <9qphl7psjfso6o02eicnulln5pm9kffv1g@4ax.com>,
>George Neuner  <gneuner2@comcast.net> wrote:
>
>>>>>(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.
>>>
>>>In a C-like language, that isn't determinable without performing
>>>the garbage collection!  Think of a top-level object that points
>>>to a recursive data structure.  Is it the last such one?  Use
>>>counts won't help.
>>
>>Incorrect.  It is possible to associatively track shared use of a
>>recursive structure through independent references.  It isn't done
>>because it is far more expensive in complexity, in time and in
>>auxiliary structures required than is connectivity tracing.
>
>Which is equivalent in effort to performing a full garbage collection!

More effort actually.  Which is why it isn't done.


>In any case, it STILL doesn't solve the finalisation problem for
>objects that are finalised when they become inaccessible.  A trivial
>counter-example is the following:
>
>    Each of N threads creates an object with a finaliser, and puts
>a pointer to it on its own stack.
>    They then barrier synchronise, and link those objects into a
>circle (not removing the stack link).
>    They then do their work on the objects, and return past the
>stack frame where they created them, NOT synchronising before they
>do that.
>
>It is obvious that the objects become inaccessible at a point that
>is indeterminate in all threads, and cannot be made determinate
>without adding synchronisation or ordering threads.  And it makes
>NO difference what form of usage tracking you use, because the
>problem is inherent in the model.

That's an implementation issue.  If smart pointers are used, then
tracking imposes external synchronization points.


>>Finalization *is* completely separable from storage reclamation.  It
>>isn't done simply because it is inconvenient to do so.
>
>As Andy and I posted, it can be separated ONLY by constraining
>languages - in the modern C++/GC approach, it isn't.  If you still
>think that it's possible, why not tell WG21 how to do it?

The imprecise semantics of C++ wrt GC roots are not applicable.

Transactions obey strict stack semantics.  It is not possible for two
transactions to share an allocation unless one or both is nested
within the transaction which owns the allocation.  Therefore it
*always* is safe to finalize an object at the end of its owning
transaction.  If nested transactions belong to separate threads, their
execution still must obey the same stack semantics.

Regardless of nesting, the needs of any single transaction can be
handled by simple stack allocation.  However, allocations from
parallel transactions at the same nest level could be intermixed if
taken from the same heap.

GC is not required to deal with this ... but it does permit allocation
of variably sized blocks without undue fragmentation of the heap.  A
VMM-like implementation that maintains logical addresses would be - in
general - unnoticeable by an application.

>Regards,
>Nick Maclaren.

George

[toc] | [prev] | [next] | [standalone]

#6325

In article <m2cnl7ho036gtgja182svvn36vr2q1ogb4@4ax.com>,
George Neuner  <gneuner2@comcast.net> wrote:
>
>>In any case, it STILL doesn't solve the finalisation problem for
>>objects that are finalised when they become inaccessible.  A trivial
>>counter-example is the following:
>>
>>    Each of N threads creates an object with a finaliser, and puts
>>a pointer to it on its own stack.
>>    They then barrier synchronise, and link those objects into a
>>circle (not removing the stack link).
>>    They then do their work on the objects, and return past the
>>stack frame where they created them, NOT synchronising before they
>>do that.
>>
>>It is obvious that the objects become inaccessible at a point that
>>is indeterminate in all threads, and cannot be made determinate
>>without adding synchronisation or ordering threads.  And it makes
>>NO difference what form of usage tracking you use, because the
>>problem is inherent in the model.
>
>That's an implementation issue.  If smart pointers are used, then
>tracking imposes external synchronization points.

In all sane architectures, an implementation is not allowed to add
major new constraints, unless authorised by the specification.  This
is a model issue, and smart pointers do not and cannot help without
extra semantic constraints.  As I said previously, if you know how
to solve this, why don't you tell WG21 how to do it?

>Transactions obey strict stack semantics.  It is not possible for two
>transactions to share an allocation unless one or both is nested
>within the transaction which owns the allocation.  Therefore it
>*always* is safe to finalize an object at the end of its owning
>transaction.  If nested transactions belong to separate threads, their
>execution still must obey the same stack semantics.

You have a very restricted view of transactions.  Unstacked ones
have been used for half a century, and the only constraint is that
they can be made to appear pseudo-atomic, which means that they must
be independent of each other.  Nesting is not required.  You are
clearly not allowing for asynchronicity or automatic parallelism.

>GC is not required to deal with this ... but it does permit allocation
>of variably sized blocks without undue fragmentation of the heap.  A
>VMM-like implementation that maintains logical addresses would be - in
>general - unnoticeable by an application.

Sigh.  Only compacting garbage collectors, which are very much NOT
currently in favour.  Indeed, WG21 took the decision to forbid them.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#6297

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.

[toc] | [prev] | [next] | [standalone]

#6299

In article <4F58567A.3000605@SPAM.comp-arch.net>,
Andy (Super) Glew <andy@SPAM.comp-arch.net> wrote:
>On 3/7/2012 11:55 AM, George Neuner wrote:
>>
>>> (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...)

Yes.

>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.

Oh, yes, it is!  Not in the majority of cases, true, but it is THE
critical aspect in a significant and very important minority.

>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.

I am a heretic, and regard that as positively the wrong way to go.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#6300

On 3/8/2012 12:02 AM, nmm1@cam.ac.uk wrote:
> In article<4F58567A.3000605@SPAM.comp-arch.net>,
> Andy (Super) Glew<andy@SPAM.comp-arch.net>  wrote:
>> On 3/7/2012 11:55 AM, George Neuner 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.

[toc] | [prev] | [next] | [standalone]

#6303

In article <4F58CE49.2080108@SPAM.comp-arch.net>,
Andy (Super) Glew <andy@SPAM.comp-arch.net> 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.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#6322

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch

csiph-web