Hi Steve
> But this all depends on a lot of practical factors. What do we mean
> by "large" or "significant proportion"? And if the application is
> central to the business it typically doesn't matter.=20
(snip)
> There is a lot of difference between tuning and long pauses, so this
> needs clarification. In my opinion, the real strength of the Poplog
> GC is that it is self-tuning. This makes it very practical.
On a dedicated server machines, the systems admin staff will be looking
at machine performance tuning for the major business applications.
However, the typical end-user (at least of our software) will be running
our client on their desktop machine along with Outlook, Word, =
PowerPoint,
IE (insert your favourite(!) application here) etc. This means the ideal
situation for us is the ability to configure the memory management to =
give
a balance of low memory footprint, little or no latency during user
interaction and the ability to scale up for "power users" who push the
software. We found we were able to do this with Java which was something
we hadn't been able to do with Poplog.
(BTW, I'm not saying that the Poplog GC is not good. What I am saying
is that it currently doesn't provide sufficient control over the
memory management behaviour for certain types of application.)
> There are some interesting gaps here. It isn't stated that the
> documents are large - but presumably that is the problem. What one
> needs to know is whether or not the documents are a complex graph
> of teeny interlinked records or contain lots of non-full data.
> And when the document is closed, is there any particular reason
> why it is difficult to release the non-memory resources?
The "documents" themselves can vary in size from a few hundred K to
many megabytes, depending on what the user is doing and there's no
problem releasing the resources when a document is closed. However
as memory usage increased in the old Poplog implementation, we could
not program our way round the fact that a GC scans the whole heap
which always caused a significant pause. In the Java implementation,
the generational GC and the additional controls over memory management
means the application can have a very large heap without most GCs being
noticable.
> The way Pop-11's design leads to practical performance is a =
fascinating
> topic - but one I won't pursue unless prodded with a pointy stick.
(Prod...prod... :)
> The basic concept is simple: when an application pauses to accept =
input
> there is an opportunity to perform a "speculative" garbage collection. =
> By "speculative", I mean that it must be possible to instantly abandon =
the
> garbage collection without any noticeable cost. This is a pretty =
obvious
> idea but I've never seen it done - although I bet it has.
The JVM doesn't support speculative GC but an interesting article on the
types of GC that are supported is at:
http://java.sun.com/docs/hotspot/gc1.4.2/index.html
Julian
|