[Mono-gc-list] Support for GC.AddMemoryPressure()
goncaloclopes at gmail.com
Fri Jun 8 06:07:23 UTC 2012
Thanks for the feedback David, that's exactly the way how I always thought
about it :-)
Also, I have more observations pertaining to the semantics of
AddMemoryPressure. Rodrigo mentioned the API was obscure and it wasn't
clear how exactly it operates. Well, from the name itself and from having
used it a lot in the past, I think I can offer a couple of guesses.
While operating, a GC has basically to make two decisions: when to collect
and what to collect. I think it's clear to assume AddMemoryPressure only
concerns itself with the former, since it's a static method that receives
no information whatsoever about any object. The decision of when to collect
must be closely tied to the amount of memory allocated by the managed
process at a given moment in time, so it's natural to assume there's some
fast way in the GC to measure how much memory is currently in use and that
variable is used in the decision process. Since AddMemoryPressure receives
as input a number of bytes, I always imagined it was simply directly adding
up to this variable, perhaps in some thread-safe way, but thereby making
the pressure automatically meaningful to the GC decision process.
The only point which for me could raise ambiguity is actually the converse
of the method: RemoveMemoryPressure. Since memory pressure is only applied
externally to the GC, adding it always represents, at the user's
discretion, a meaningful semantics. However, my question relates to what
would happen if the user calls RemoveMemoryPressure when all memory
pressure has already been removed. Can you actually start delaying
collection? I would expect not, although I never tried it. My guess would
be the memory pressure is kept in a separate variable which is always
lower-bounded at 0 to avoid this kind of mischief. However, a couple of
nice unit tests could probably determine this easily...
Is there anything else problematic with the memory pressure methods you
guys are aware of that contradicts this interpretation?
On 7 June 2012 17:05, jeske [via Mono] <
ml-node+s1490590n4649773h73 at n4.nabble.com> wrote:
> On Jun 5, 2012 7:16 AM, "Rodrigo Kumpera" <[hidden email]<http://user/SendEmail.jtp?type=node&node=4649773&i=0>>
> > This is a classic example of what the memory pressure API is not for.
> You're simply not disposing your native resources and the GC has
> > no business in doing it for you. For forcing it to do for you, you're
> trading higher latencies for a mild convenience.
> I either don't understand or don't agree with this. Glopes' use case seems
> to me to be exactly the problem memory pressure was designed to solve.
> The purpose of the memory pressure api is to tell the gc about the real
> memory consumption of managed objects, so references to unmanaged memory
> don't 'break' the geneational colletors behavior. You can read about the
> problems of not having this on some of the java apache projects, such as
> cassandra and hbase.
> There is nothing 'broken' about expecting the gc to handle object
> lifetime. Without this we are degenerated to c-like manual refcounting or
> other fixed lifetime strategies, and should seriously consider authoring in
> c++ instead.
> Memory pressure simply offers a mechanism for managed objects referencing
> native data to operate similarly to managed objects holding large managed
> Mono-gc-list maillist - [hidden email]<http://user/SendEmail.jtp?type=node&node=4649773&i=1>
> If you reply to this email, your message will be added to the discussion
> To unsubscribe from Support for GC.AddMemoryPressure(), click here<http://mono.1490590.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4649713&code=Z29uY2Fsb2Nsb3Blc0BnbWFpbC5jb218NDY0OTcxM3w1Nzg4Mzk1OTY=>
View this message in context: http://mono.1490590.n4.nabble.com/Support-for-GC-AddMemoryPressure-tp4649713p4649780.html
Sent from the Mono - Garbage Collection mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-gc-list