See my comments inline...
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
| From: "Daniel Moth" <
[email protected]>
| References: <
[email protected]>
<
[email protected]>
| Subject: Re: REPOST: [mscoree.stat] More info please
| Date: Thu, 28 Aug 2003 18:09:41 +0100
||
| Hi thanks for your informative reply...
|
| You are correct we are using an ARM cpu (PXA255) on our own CE 4.2-based
| device... The app is never moved to the background; the app is the raison
| d'etre of the device (there is no visible shell or anything else
installed)
| and should stay up 24x7...
|
| I now understand the "pitched" term... Is there any more info on the jit
| code buffer (size etc)?
|
| You explanation on the various garbage collection types is also useful...
Is
| it normal/expected then that:
| 1. It is *extremely* rare to observe a simple collection
No, it really depends on the allocation pattern of the app. Compaction is
run based on fragmentation--the more fragmented the heap after the mark and
sweep the more likely a compaction will run. If you're churning through
lots of memory, ie lots of short lived objects are being allocated, then
there's a good chance the heap will fragment and need to be compacted.
| 2. More often than not there is no compact collection either
Again, it's really app dependent. Your data shows 290 compaction GC's, 0
simple and 20 full.
| 3. I have *never* run an app (even a simple one) that did not include at
| least one Full collection. (I did not find this strange until your
| explanation that this should only occur when the app is moved to the
| background (not applicable in our case) or when the system is running on
low
| memory)
|
| Regarding time in full collection, apart from the 4 second instance I have
| had one where it took 3 seconds and in all other observations it is under
| 500ms... If I manage to narrow it down to a simple reproducible test case
| I'll post it... BTW, when a collection occurs would the unit/app "freeze"
or
| would it be collecting in the background?
All managed threads are suspended during a garbage collection.
| Finally, I think the date/time of collections would be very useful; a few
| examples spring to mind: We could for example timestamp the core
activities
| of the app (based on user interaction etc) and then compare with the
| timestamp of garbage collection(s) to see which activity "pushed the
memory
| over the edge"... or if for example the app becomes non-responsive/slow at
| certain times, the tester could note the time of the occurrence and we
could
| match it with a garbage collection taking place at that time (or discard
the
| GC as the culprit...)... We could leave the unit in an idle state (e.g.
when
| it runs over night) and if we observe a number of collections during that
| period it could help point to a leak somewhere/the unit not being as idle
as
| we thought... We could use the timestamp feature to distinguish between
| application induced collections and the normal ones... etc
Those are good observations. We are considering adding some performance
analysis tools to the next version of the compact framework which I think
would help address some of the issues you raise.
If you can run your app on the desktop .Net, you could try out the
allocation profiler tool. It can give you a great deal of visibility on
the memory allocation and GC behavior of your app. Of course the results
will be for the desktop and not your device, but it may be helpful anyway.
The tool can be downloaded from:
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=36a3e
666-6877-4c26-b62d-bfd7cb3154ac
| Thanks again for your helpful answers...
|
| Cheers
| Daniel
|
| | > Daniel,
| >
| > "Pitched" refers to discarded jit'ed code (just-in-time compiled).
| Although
| > the actual mechanism varies depending on the device cpu type (it looks
| like
| > you are using an ARM cpu), jit'ed code is sometimes discarded to free up
| > memory for other uses. On ARM, this happens when the jit code buffer is
| > full, and additional code needs to be jit'ed. So from your earlier post
it
| > looks like there were 30 methods pitched containing a total of 441
bytes.
| > That's not much relative to the toal amount jit'ed.
| >
| > Regarding the different types of garbage collections, the compact
| framework
| > uses a mark and sweep algorithm with occasional compaction. A simple
| > collection is one where only a mark and sweep occurs, and a compact
| > collection is one that includes a compaction phase in addition to mark
and
| > sweep. A full collection adds code pitching after the compaction. Full
| > collections are performed only when the system is running low on memory
or
| > when the app is moved to the background. So they should be relatively
| rare.
| >
| > I can't explain the 4 second time that you saw for the full collection.
| > Does it happen repeatedly? If you have a simple reproducible test case
| I'd
| > be happy to take a closer look.
| >
| > Your remaining questions:
| > > 3. Do the values produced wrap? I.e. Total Program Runtime does not
| report
| > > correct value if app has been running for more than a few days...
| > Yes.
| > > 4. I think the statistical info does not include the last garbage
| > collection
| > > (when the app terminates); is that correct? It would be useful if it
| > did...
| > You're correct, termination time data is not included. That's because
| > there is no garbage collection run at that time (by definition,
everything
| > is garbage so the entire GC heap is simply freed).
| > > 5. I think that if an app terminates abnormally no data is generated;
is
| > > that correct? It would be useful if there were...
| > I agree. That's something we are working on.
| > > 6. What would be most useful is the actual date/time a GC occurred...
| > Can you explain why?
| > > 7. What happens if 2 CF apps are running at the same time? I.e. does
the
| > > stat file show data for the app that run first or would the data in
that
| > > case be unreliable?
| > The data is not reliable in that case.
| >
| > Scott Corbin
| >
| > This posting is provided "AS IS" with no warranties, and confers no
| rights.
| > --------------------
| > | From: "Daniel Moth" <
[email protected]>
| > | Subject: REPOST: [mscoree.stat] More info please
| > | Date: Fri, 22 Aug 2003 11:59:49 +0100
| > | Lines: 60
| > | X-Priority: 3
| > | X-MSMail-Priority: Normal
| > | X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| > | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| > | Message-ID: <
[email protected]>
| > | Newsgroups: microsoft.public.dotnet.framework.compactframework
| > | NNTP-Posting-Host: 194.242.149.254
| > | Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP10.phx.gbl
| > | Xref: cpmsftngxa06.phx.gbl
| > microsoft.public.dotnet.framework.compactframework:31717
| > | X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework
| > |
| > | Hi
| > |
| > | There is no profiling capabilites in the CF and one of the crude ways
we
| > can
| > | get some info on memory consumption etc is through the registry key
| > | described by Scott Corbin in a previous post... The use of this
approach
| > is
| > | mentioned in an MSDN article by Maarten Struys.
| > |
| > | Would someone from MS (or someone that knows) be kind enough to
| enlighten
| > us
| > | on the meaning of values in the mscoree.stat file?
| > |
| > | In particular
| > | 1. What does bytes/methods pitched mean?
| > | 2. What is the difference between a simple, compact and full garbage
| > | collection?
| > |
| > | Cheers
| > | Daniel
| > |
| > |
| > | ----- Original Message -----
| > | From: "Daniel Moth" <
[email protected]>
| > | Newsgroups: microsoft.public.dotnet.framework.compactframework
| > | Sent: Sunday, August 17, 2003 12:36 PM
| > | Subject: [mscoree.stat] More info please
| > |
| > |
| > | > Hi
| > | >
| > | > Following the article on MSDN and the instructions from a post to
this
| > ng,
| > | I
| > | > have setup the registry to produce a mscoree.stat file after my CF
app
| > | > terminates. Based on that and given the complete lack of
documentation
| > on
| > | > the topic I now have the following questions/requests:
| > | >
| > | > 1. What does bytes/methods pitched mean?
| > | > 2. What is the difference between a simple, compact and full garbage
| > | > collection? Is it somehow related to the generations??
| > | > 3. Do the values produced wrap? I.e. Total Program Runtime does not
| > report
| > | > correct value if app has been running for more than a few days...
| > | > 4. I think the statistical info does not include the last garbage
| > | collection
| > | > (when the app terminates); is that correct? It would be useful if it
| > | did...
| > | > 5. I think that if an app terminates abnormally no data is
generated;
| is
| > | > that correct? It would be useful if there were...
| > | > 6. What would be most useful is the actual date/time a GC
occurred...
| > | > 7. What happens if 2 CF apps are running at the same time? I.e. does
| the
| > | > stat file show data for the app that run first or would the data in
| that
| > | > case be unreliable?
| > | >
| > | > Cheers
| > | > Daniel
| > | >
| > | > PS <SNIP>
| > | > I am particularly
| > | > worried about a GC collection taking 4 seconds to complete...
| > |
| > |
| > |
| > |
| > |
| >
|
|
|
|
|
