[MUD-Dev] New Beginings

[Kwon Ekstrom]

From: "David B. Held" <dheld at codelogicconsulting.com>
> From: "Bruce Mitchener" <bruce at cubik.org>

> optimization detail when it comes to programming.  The problem of
> properly handling finalization in all cases just highlights this.
> GC allows coders to write code without explicitly thinking about
> object lifetime, and I don't think this is necessarily a good
> thing.

It seems that you're following the practice you were complaining
about earlier... comparing good c++ practices to poor java
practices.  Assuming your developer knows what he/she is doing,
thought on object life is always there.

Which does bring up a subtle Java GC problem... you have to remove
all references to an object in order for it to be collected, which
"may" under poor coding circumstances cause a "memory leak" it's not
really a leak since the memory is still viable, but it's still a
problem.

> intrinsic GC, you do not.  You can cheat the GC by caching your
> objects, but then you are doing extra work to circumvent the
> memory manager.  In C++, you need not do any such "cheating".  So
> when

Allocation and deallocation eats time even in c++, I don't see a
cache's primary purpose as cheating the GC, I see a cache's primary
purpose to make the best use of objects you've already spent the
allocation time on.  I've used (and seen other programmers use)
caches in c/c++.  You can hardly call it bypassing the GC there.
It's a programming tool.  One which is designed for performance,
irregardless of the language.

>> Incremental collectors can have a time limit imposed on them to
>> prevent them from exceeding a given amount of time to avoid
>> halting your process.  Generational collectors are another good
>> thing.

> And if that's what you prefer to use, go right ahead.  Even do so
> in C++ if you like.  But don't tell anyone to avoid C++ because
> it's not a GC language.

You seem to be telling people to avoid java because it's a GC
language, which is my major problem.  There's a hell of alot more to
Java than just it's GC.  In fact... except in extremely rare
circumstances the GC doesn't interfere with normal operation at all,
it rarely effects performance...  except when dealing with object
churn (allocating and deallocating hundreds of small objects), or
when extremely tight performance is required (the threads don't
sleep).  JVM's will only run the GC in 2 circumstances.

  A.  The threads are sleeping and it determines a need to free
  memory

  B.  The amount of memory needed to be freed demands immediate use
  of the GC.

The java Garbage Collector will try to run when it's unobtrusive.
You can also call the GC manually with System.gc()

-- Kwon J. Ekstrom

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev