"Joshua Scholar" <jscholar at access4less.net> wrote:

> You keep talking about the performance hit of locking the array...
> I don't know what Slang support for garbage collection has been written but
> all you need is something that should be free!  All you want is to make sure
> that the array you're iterating over doesn't go away until after the
> iteration is done.

I think we're getting seriously at cross-purpose here.

I'm not at all talking about locking the object in any form of garbage
collection related manner. That's a completely orthogonal issue utterly
unrelated to my points.

One suggestion (from several emails back) of a way to prevent an
iteration from messing up if the code in the iterated block affects
array contents (say the old classic mistake of trying to use a do: loop
with a Set to empty it) was to copy the original contents (costing a
non-trivial amount of time and memory) and actually iterate over that
copy but in some way affecting the original. The _only_ GC relationship
here is cleaning up afterwards.  I don't think this is a sensible way
to prevent the problems in the first place so I've no interest in
defending it or explaining how it might work.

Basically the problem is that a block being used in the iteration can
do anything at all that is possible in the system, including
fundamentally changing the collection being iterated upon. If you
haven't yet done so, do actually run that code snippet I offered since I
bet it doesn't do what you expect.

A secondary problem is that with multiple processes having unfettered
access to the whole system it is entirely possible for some other code
to change the collection somewhat under the covers. You coudl liely
prevent this issue with judicious use of critical blocks but they have
their own delights.

As for Slang support for GC, well the gc is written in Slang as is most
of the interpreter. There's nothing very clever about Slang at all -
it's merely a dialect of Smalltalk that pidgins C. Badly, mostly.

> 
> One of these two things (some form of this is NECESSARY if you ever want run
> bytecodes in parallel with Slang code or call bytecodes from Slang code):
> 
> 1.  The ability to register some Slang/C variables with the garbage
> collector so that what they point at will not be collected and so that those
> variables will be updated if the object moves.
See ObjectMemory>push/popRemappableOop: We use it quite a bit.
> 
> or
> 
> 2. The ability to register some variables Slang/C variables with the garbage
> collector so that what they point at will not be collected and to lock the
> object so that it will not be moved.  This could be more expensive.
Whilst you're in a prim objects will not move unless there is a function
used that triggers a GC - that's what the pushRemappable... above is
for. We could simplify so that the idiom becomes more along the lines of
"don't create object in prims except for deliberate creation prims".
That would avoid in-prim GC at the cost of some rewriting ofa few areas
of the system.

> 
> Also, because of the become: problems you either want a restriction so that
> Slang/C variables are never replaced on become: (that might be good enough).
> Or you want to make become replacement optional on a per/varible basis.

I think you're projecting far too much cleverness and importance onto
Slang.  It's just pidgin C with most of the (small number of) useful
bits of C dropped.

> ....
> 
> Why should keeping an object from being collected be expensive at all?

Oh boy, you need to read up on some GC literature :-) There's huge
amounts written on the subject and some of it is even correct and
understandable. (Some people have been nice enough to say that my
meagre scribbles on the subject are clear and intelligable - see the
nuBlue book aka 'Squeak: Open Personal computing for Multimedia, Mark
Guzdial & Kim Rose, editors, 2001, Prentice-Hall')

If you have a moving compactor, any object that is locked in place for
some reason is a Problem, capital P. It represents a sandbar you have
to record, work around, keep out of the way and in general it's a pain
in the bum. It might prevent you moving a largish object that you want
to compact (no room below the sandbar) and then you have to do
something to find smaller obejcts to fill the gap, handle a probable
empty space left over, keep track that you have a different sort of
sandbar... I tried this for the Active Book version of Smalltalk some
fifteen or so years ago and it was _horrible_.

What you _can_ do that helps for some cases (as Andreas mentioned, for
non-pointer objects is one good case) is to have a separate memory area
for objects that are likely to be wanted to be fixed address. This gets
them out of the way but leaves you with another classic problem in
memory management to handle. You could simply delegate to the machine's
libraries and use malloc/free in some cases but that is rarely well
enoghu written to be helpful.

Basically none of this is new stuff, it's been hashed over by a lot of
smart people and nothing so far this time round offers anything new. I
bet there's an answer out there and maybe you'll be the one to find it
- but you haven't yet. 

tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: HEM: Hide Evidence of Malfunction