[m-rev.] for review: deep profiler redesign
Zoltan Somogyi
zs at cs.mu.OZ.AU
Tue Nov 12 17:15:29 AEDT 2002
On 12-Nov-2002, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> The server(s) carry around state pertaining to their clients.
No, they don't, with one very minor exception I am considering fixing
(the timeout period).
> Some mild cunning would be required to release
> freed virtual memory, since you say that's a problem.
Cunning wouldn't help.
Once malloc or GC_malloc gets VM from the operating system, it doesn't ever
give it back until the process exits. In theory that can be fixed, but I have
no interest *whatsoever* in touching such code.
> Er, I don't follow your reasoning. You've solved the start-of-day race
> condition,
This can be true only if you use "start-of-day" to mean something other
than what I guessed you meant.
> Assuming one can return freed resources to the OS,
Bad assumption.
> However, if as you say a server may consume gigabytes of VM in serving a
> single client, then this is not a sensible approach.
For a large profiling data file, that is possible. I have seen 200-300 Mb
VM consumption for data files derived from compiler runs, which is bad enough.
Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
post: mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------
More information about the reviews
mailing list