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

Groups > comp.unix.programmer > #303

Re: Tracing garbage collectors are broken

Show all headers | View raw

Richard Kettlewell <rjk@greenend.org.uk> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>> because the rely on the assumption that the set of 'spaces' they can
>> inspect in order to find pointers/ references to objects is identical
>> to the set of all spaces where such pointers/ references could
>> possibly be stored. This assumption is false for systems connected to
>> networks or employing any kind of internal memory protection.
>
> It's only false for languages in which hiding references is
> possible.

This should be 'environment' and not 'languages': It is only 'not
false' in environments with a single, shared address space which are
isolated from each other. Also, 'hiding' is not the proper verb
here. In the two cases I mentioned, the reference is not 'hidden' to
malevolently fool a garbage collector but it is temporarily stored in
kernel memory in order to use features the kernel already provides
(such as 'ordered message queues' in the case of connected sockets or
a datastructure which can be used to find a datum associated with some
file descriptor fastly). Another obvious possibility would to expect
the client of some network server to maintain the address of some kind
of server-side 'state object' associated with this client.

> If it's not possible to reconstitute a pointer from some bytes in (e.g.)
> a disk file then the GC does not have the problem.

If the technically wrong notion that 'a pointer' is not 'ordinarily
data' is emulated in software to a sufficient degree that said
features cannot be used, other software based on this wrong notion
appears to function properly. But that's IMO not inherently different from
'working around code bugs with other code'. Also, as soon as the
possibility of interfacing with code running 'outside' of the emulated
'Lisp Machine' exists, the usefulness of the workaround evaporates and
the state reverts to 'provided code writers voluntarily abstain from
using certain features ...'. Lastly, all of this can be easily
provided despite a sufficiently catankerous (should this be
'McCarthy'-istic?) execution environment by using arrays of objects
and array indicies instead of pointers.

Back to comp.unix.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Tracing garbage collectors are broken Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-03 12:28 +0100
  Re: Tracing garbage collectors are broken Michael Press <rubrum@pacbell.net> - 2011-05-03 20:58 -0700
  Re: Tracing garbage collectors are broken gordonb.nw5lc@burditt.org (Gordon Burditt) - 2011-05-04 01:58 -0500
  Re: Tracing garbage collectors are broken Richard Kettlewell <rjk@greenend.org.uk> - 2011-05-04 09:33 +0100
    Re: Tracing garbage collectors are broken Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-04 15:09 +0100
  Re: Tracing garbage collectors are broken Nobody <nobody@nowhere.com> - 2011-05-05 08:42 +0100
    Re: Tracing garbage collectors are broken Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-05 11:52 +0100
      Re: Tracing garbage collectors are broken William Ahern <william@wilbur.25thandClement.com> - 2011-05-05 11:46 -0700
        Re: Tracing garbage collectors are broken Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-05 20:41 +0100

csiph-web