[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