Can objects be moved by the GC?

A think  I can remember that a read somewhere that Dolphin's GC never moves
objects. It would also match my experience, because otherwise one would have
to allocate objects like ByteArray in a separate memory region or mark them
as "fixed". And I see a lot of external interfacing code without #newFixed:

Surprisingly there is a method #newFixed: in Dolphin. Is this something
started and left behind after moving to the "objects never move" strategy or
does this method really do something different compared to #new?

Regards

Carsten Haerle

Carsten Haerle wrote:

> A think  I can remember that a read somewhere that Dolphin's GC never
> moves objects.

I think that Blair has said that the /current/ GC does not move objects (or was
it just binary objects ?).


> It would also match my experience, because otherwise one
> would have to allocate objects like ByteArray in a separate memory region
> or mark them as "fixed". And I see a lot of external interfacing code
> without #newFixed:

That may be a little misleading.  All the ExternalStructure (and subclasses)
instances use newFixed: to allocate their internal byte buffer, so nearly all
external interfacing is done with fixed objects anyway.  From what I've seen
the remaining cases make the weaker assumption that the GC will not move a byte
object /while an external call is being made/.  E.g. passing an ordinary String
filename to an external call is safe provided that the callee does not retain a
reference to the String itself (and usually they don't).  (There may, of
course, be bugs where unfixed objects are used inappropriately, but they won't
show up until/unless the GC does start to move binary objects).


> Surprisingly there is a method #newFixed: in Dolphin. Is this something
> started and left behind after moving to the "objects never move" strategy
> or does this method really do something different compared to #new?

I suspect that at the moment #newFixed: doesn't do anything different from
#new:, but that may change in the future.  OA have talked before about
replacing the fairly simple GC implementation that they use now with something
more sophisticated. (I, personally, haven't seen much evidence that a
replacement would provide much benefit).

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
...
> #new:, but that may change in the future.  OA have talked before about
> replacing the fairly simple GC implementation that they use now with
something
> more sophisticated. (I, personally, haven't seen much evidence that a
> replacement would provide much benefit).

I _think_ there might be some benefit to an improved GC implementation.
However perhaps someone who knows more about these matters could check my
assumptions.

I can think of two kinds of GC related issues I have experienced.

The first kind is with Oracle running out of handles during periods of heavy
querying.  I am not sure if any kind of generic GC improvements could help
this.  I am willing to accept that this is just part of life, and I can work
around it.

The second kind of issue I ran into recently was with a report on data in
Access, writing out to Excel, and driven from Dolphin Smalltalk.  I happened
to be using the ReStore object to relational mapping tool.  Reports worked
fine with average sized data sets, however the program would come to a very
slow crawl when reporting on a larger dataset.  We added some explicit GC's
in the processing loop, and that resolved the problem.  I _think_ an
improved GC implementation might have avoided the need to add explicit GC's.
Adding explicit GC's makes the code less elegant.  One needs to make sure
they GC often enough, but not too much.  It adds an additional layer of
design complexity.  Additionally if one happens not to test with large
datasets then one may not be aware of the need to do explicit GC's, until a
customer throws an unanticipated large amount of data at it.  I would enjoy
any GC enhancement that would eliminate this issue.

Chris

Chris,

> I _think_ there might be some benefit to an improved GC implementation.
> However perhaps someone who knows more about these matters could check my
> assumptions.

I doubt I know more about it, but I will offer a two-bit opinion just
the same :)

I think much of what you are describing is related to (lack of)
finalization, not garbage collection.  FWIW, when I think of more
efficient GC, I envision the VM spending less time finding and cleaning
up the many short-lived objects that are created and discarded and
"wasting" less time on the long-lived objects, not doing a better job of
managing limited external resources.  At present, I have no sense of
whether the finalizer has room for improvement, or database cursors and
window handles are simply too rare or expensive.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Christopher J. Demers wrote:

> > #new:, but that may change in the future.  OA have talked before about
> > replacing the fairly simple GC implementation that they use now with
> > something more sophisticated. (I, personally, haven't seen much
> > evidence that a replacement would provide much benefit).
>
> I _think_ there might be some benefit to an improved GC implementation.

I think there certainly would be benefits -- I meant only that my own
experience and what I'd read in this newsgroup suggested that the GC (and
problems caused by it) seemed not to be a major issue compared with (just for
instance) the ability to create DLLs.

I'm no expert on GC (though it has long been an interest of mine -- sad, I
know), but my impression is that unless you either have the resources of Sun
(the GC in recent Sun JVMs is impressive), /or/ need to need to push the
envelope beyond what a modern desktop app is likely to need (e.g. using more
memory than will fit in real RAM), then a simple implementation performs at
least as well as a "classic" complex implementation.  I view the absence of
"tweakable" parameters like generation size, perm-space size, etc, as an
advantage in Dolphin.


> The first kind is with Oracle running out of handles during periods of
> heavy querying.  I am not sure if any kind of generic GC improvements
> could help this.  I am willing to accept that this is just part of life,
> and I can work around it.

Interesting.  This sounds like a finalisation issue to me.  Presumably because
you can run out of handles rather fast in relation to the "aggressiveness" of
the GC/finaliser.   It's a bit odd because my own experience is the opposite.
In JNIPort I use finalisation to release references to Java objects, and I've
noticed that the GC/finalisation is almost spookily efficient at reclaiming
them -- even in tight loops creating 10K or 100K objects per second I can see
that references are being cleaned up almost immediately (in < 1 second).  It's
/so/ effective that I spent some time trying to find the bug in my
monitoring/reporting...  (and eventually started to speculate that the Dolphin
GC may have an element of ref-counting in it in addition to the fundamental
mark-and-sweep).

I think the /real/ culprit (in the DB case) is using finalisation to manage
resources that are significantly more scarce than memory.  GC is naturally tied
to memory (if the machine had infinite memory then there'd be no need for GC at
all), so finalisation is really not appropriate (except as a fallback) for
cleaning up more limited resources.  Arguably it's /your/ job to ensure that
you clean up database handles and that if you are churning lots of them without
doing so, then scattering a for GC calls around is a very small price to pay.
(I have no idea if that's actually what you are doing, I'm just making a
general point).

Come to think of, in this specific case, I suspect it would make sense for the
DB package to force a GC before creating new handles -- presumably the cost of
a GC is small compared to the cost of a DB query.


> The second kind of issue I ran into recently was with a report on data in
> Access, writing out to Excel, and driven from Dolphin Smalltalk.  I
> happened to be using the ReStore object to relational mapping tool.
> Reports worked fine with average sized data sets, however the program
> would come to a very slow crawl when reporting on a larger dataset.  We
> added some explicit GC's in the processing loop, and that resolved the
> problem.

It would be interesting to know /why/.  I presume the machine wasn't thrashing
?  Otherwise it sounds rather like another finalisation issue, but I can't
imagine why that would make it slow down rather than fail -- maybe there is
some sort of slow-but-better-than-failing-altogether emergency fallback code in
ReStore which makes the execution time non-linear in the size of the actual
(i.e. before GC) dataset.


> I _think_ an improved GC implementation might have avoided the
> need to add explicit GC's. Adding explicit GC's makes the code less
> elegant.  One needs to make sure they GC often enough, but not too much.
> It adds an additional layer of design complexity.  Additionally if one
> happens not to test with large datasets then one may not be aware of the
> need to do explicit GC's, until a customer throws an unanticipated large
> amount of data at it.

I agree, although with the reservations about finalisation I described above.

Maybe a simple approach would be to force a GC after a certain number of
"managed" objects had been created.  Where "managed" would be functionally the
same as "finalisable" but also have this implication for GC.  E.g. GDI objects
woudn't need to be managed, but DB connections would. Clunky, but I don't think
that any other /automatic/ scheme could resolve the relying-on-finalisation
issue.  (And it wouldn't require changes to the VM/GC)

    -- chris