Switching windows causes a 'full' garbage collection at bad time

  • Thread starter Thread starter John Roberts
  • Start date Start date
J

John Roberts

Hi,

Our platform is Windows CE 5.0 and Compact Framework 2.0. The device fully
replaces the Windows CE shell with our own which is completely written in
compact framework, as are all the applications. Right from the start, we
used a single-process solution such that the shell and all the 'applets'
execute within one process thus using one managed heap, etc, the reasoning
being to conserve resources (particularly RAM) and to make cross-application
communication much easier. On the whole, this solution has worked extremely
well.

However, we recently discovered one fly in the ointment and it is to do with
Windows CE performing a full garbage collection whenever the user switches
windows. In our shell, there are multiple threads running each with their
own Form. Of course, only one Form is visible at the same time. The problem
is when the user presses a button to activate or to launch a new
application, a full garbage collection occurs.

Normally, in most Windows CE environments this would be OK because the
garbage collection would be executed in the application losing activation.
The reasoning makes sense - this application is being put into the
background and so it might be a good time to get it to free many of its
resources, including JIT code which is pitched by this operation.
Unfortunately, in our scenario, this is exactly the wrong time to be doing
this because the garbage collection and pitching affects the entire process,
including all the shared code for the GUI, and it also affects the
application that is being brought to the front because it is the same
process. The consequence for the user is they must suffer a 1-2 second delay
when activating a new application (while code is pitched and then probably a
fair chunk of it compiled almost straight away).

My question is twofold, first what is the criteria for performing a full
collection when windows are deactivated. We note that it doesn't happen if
the windows losing/receiving activation belong to the same thread. However,
if they are on different threads, that appears to trigger the garbage
collection. It clearly is not if the windows belong to different processes
because we have only one.

Second, is there a way to surpress or workaround this behavior? For example,
a manifest file, a registry setting, an override or any other way to 'fool'
the compact framework from doing this?

Any pointers gratefully received...
- John
 
My first suggestion would be to discover exactly what is being
processed by the garbage collector and, if you can, reduce the amount
being processed. If the GC is running, it's because you've created
and left something for it to collect.

If you haven't used it already, a good tool is the .net cf remote
performance monitor tools (netcfrpm.exe in the SDK). This will help
you with memory conservation as well.
 
Thanks joker,

We used the aforementioned tool to confirm the code pitching. It doesn't
matter how much garbage is actually in the heap (sometimes there is much,
sometimes nothing) - there is always a full garbage collection and a
noticable pause.

The problem isn't in the performance of the garbage collector itself, which
I guess is actually pretty impressive, it is the fact that the full garbage
collection is being performed at the wrong time. It is unfortunate that the
criteria of deactivating a window does not represent a good time to do a
full collection on our platform.
 
Back
Top