WM5 - Dll memory limits

  • Thread starter Thread starter Empi
  • Start date Start date
E

Empi

Hi,

How can I check just how much furhter I can push the memory used for dll's?

I know that an application can be larger than 32Mb (stored on "slot 0").
I read somewhere that the dll's are stored on "slot" 1 (additional 32Mb).

Is it true?

Where can I read more about it?

How can I check programaticaly the amount of memory my app still has for
both slots ?


Thanks,


Empi.
 
1. You can't load into slot 1 - that's stuff in ROM.
2. Managed DLLs don't load into slot 0, they're loaded as memory-mapped
files from shared memory space, so they don't affect the 32MB process space
limit.

If you're having memory pressure problems, it's better to describe the
problem and then ask for advice.
 
First - Thaks for all helpers.

My problem is I'm developing a big application (contains lots of screen size
bitmaps that change occcasinally),
and it looks as if I've run out of some memory space, because I can't
p/invoke functions from additional dll's.
Checking lasterror informs me that the dll could not be loaded.

I managed to overcome this problem by developing a helper application that
recieves requests and answer using tcp/ip listener.
It worked great, but it is not so nice ...

Now the project is changes, and some bitmaps removed.
I rechecked and found that the dll can now be loaded, but I'm afraid that if
I'll add dome code / picture or two I won't have enough memory again...

So, my dilema is wether or not move the external app into the main one, or
not.
More knoledge about what's going on in my memory will give me a clue how
much "spare" do I have.

Thanks,


Empi
 
Is there a reason why all these large bitmaps need to be in the DLL?

Can't they be loaded from the filesystem when needed and then the
footprint would only be one or two of them rather than all of them?

If there is an issue with speed then you could pre load a batch of
them rather than one at a time...

Just my initial thoughts anyway.

Matt

First - Thaks for all helpers.

My problem is I'm developing a big application (contains lots of screen size
bitmaps that change occcasinally),
and it looks as if I've run out of some memory space, because I can't
p/invoke functions from additional dll's.
Checking lasterror informs me that the dll could not be loaded.

I managed to overcome this problem by developing a helper application that
recieves requests and answer using tcp/ip listener.
It worked great, but it is not so nice ...

Now the project is changes, and some bitmaps removed.
I rechecked and found that the dll can now be loaded, but I'm afraid that if
I'll add dome code / picture or two I won't have enough memory again...

So, my dilema is wether or not move the external app into the main one, or
not.
More knoledge about what's going on in my memory will give me a clue how
much "spare" do I have.

Thanks,

Empi

"<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote in message

2. Managed DLLs don't load into slot 0, they're loaded as memory-mapped
files from shared memory space, so they don't affect the 32MB process
space limit.
Click to expand...
If you're having memory pressure problems, it's better to describe the
problem and then ask for advice.

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com
Click to expand...
Click to expand...
 
It wouldn't matter. Again, the DLL isn't loaded into the process address
space, it's loaded as a memory-mapped file.


--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com




DJMatty said:
Is there a reason why all these large bitmaps need to be in the DLL?

Can't they be loaded from the filesystem when needed and then the
footprint would only be one or two of them rather than all of them?

If there is an issue with speed then you could pre load a batch of
them rather than one at a time...

Just my initial thoughts anyway.

Matt

First - Thaks for all helpers.

My problem is I'm developing a big application (contains lots of screen
size
bitmaps that change occcasinally),
and it looks as if I've run out of some memory space, because I can't
p/invoke functions from additional dll's.
Checking lasterror informs me that the dll could not be loaded.

I managed to overcome this problem by developing a helper application
that
recieves requests and answer using tcp/ip listener.
It worked great, but it is not so nice ...

Now the project is changes, and some bitmaps removed.
I rechecked and found that the dll can now be loaded, but I'm afraid that
if
I'll add dome code / picture or two I won't have enough memory again...

So, my dilema is wether or not move the external app into the main one,
or
not.
More knoledge about what's going on in my memory will give me a clue how
much "spare" do I have.

Thanks,

Empi

"<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote in message

1. You can't load into
slot 1 - that's stuff in ROM.
2. Managed DLLs don't load into slot 0, they're loaded as memory-mapped
files from shared memory space, so they don't affect the 32MB process
space limit.
Click to expand...
If you're having memory pressure problems, it's better to describe the
problem and then ask for advice.

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com
Click to expand...
Hi,
Click to expand...
How can I check just how much furhter I can push the memory used for
dll's?
Click to expand...
I know that an application can be larger than 32Mb (stored on "slot
0").
I read somewhere that the dll's are stored on "slot" 1 (additional
32Mb).
Click to expand...
Is it true?
Click to expand...
Where can I read more about it?
Click to expand...
How can I check programaticaly the amount of memory my app still has
for
both slots ?

Empi.
Click to expand...
Click to expand...
Click to expand...
 
The problem is that when you *load* the bitmap, it creates a Bitmap object,
which uses both managed and native resources, so it's loading stuff into the
GC Heap, and probably from a native heap that *is* in the process space .
It's likely that this is what's running you out of memory - having too many
Bitmaps created and in use at any given time. Try to limit the number of
active Bitmap objects you have created and make absolutely certain that when
you're done with your Bitmaps, you call Dispose on them.


--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com
 
These are all great and valued answers,
but,
- I never said the bitmaps are loded from the dll.
- The software has several bitmap screens and the user can move between
them fast, I can't afford loading them on the fly.
(tried it).
- So, if we assume that I'm almost out of memory, can you please help me
find out how can I know how much space do I still have for additional dll(s)
?


Thanks,


Empi
 
Doh! Thanks Chris, yes I forgot we are talking about a managed dll!

Matt

It wouldn't matter. Again, the DLL isn't loaded into the process address
space, it's loaded as a memory-mapped file.

--

Chris Tacke, eMVP
Join the Embedded Developer Communityhttp://community.opennetcf.com


Is there a reason why all these large bitmaps need to be in the DLL?
Can't they be loaded from the filesystem when needed and then the
footprint would only be one or two of them rather than all of them?
Click to expand...
If there is an issue with speed then you could pre load a batch of
them rather than one at a time...
Click to expand...
Just my initial thoughts anyway.
Matt
Click to expand...

First - Thaks for all helpers.
My problem is I'm developing a big application (contains lots of screen
size
bitmaps that change occcasinally),
and it looks as if I've run out of some memory space, because I can't
p/invoke functions from additional dll's.
Checking lasterror informs me that the dll could not be loaded.
I managed to overcome this problem by developing a helper application
that
recieves requests and answer using tcp/ip listener.
It worked great, but it is not so nice ...
Now the project is changes, and some bitmaps removed.
I rechecked and found that the dll can now be loaded, but I'm afraid that
if
I'll add dome code / picture or two I won't have enough memory again...
So, my dilema is wether or not move the external app into the main one,
or
not.
More knoledge about what's going on in my memory will give me a clue how
much "spare" do I have.
Thanks,
Empi
"<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote in message
1. You can't load into
slot 1 - that's stuff in ROM.
2. Managed DLLs don't load into slot 0, they're loaded as memory-mapped
files from shared memory space, so they don't affect the 32MB process
space limit.
If you're having memory pressure problems, it's better to describe the
problem and then ask for advice.
--
Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com
Hi,
How can I check just how much furhter I can push the memory used for
dll's?
I know that an application can be larger than 32Mb (stored on "slot
0").
I read somewhere that the dll's are stored on "slot" 1 (additional
32Mb).
Is it true?
Where can I read more about it?
How can I check programaticaly the amount of memory my app still has
for
both slots ?
Thanks,
Empi.
Click to expand...
Click to expand...
Click to expand...
 
- I never said the bitmaps are loded from the dll.

It doesn't matter where they're loaded from (file, DLL, stream or whatever).
They're loaded into a manage Bitmap of Image class instance, and that takes
memory resources.
- The software has several bitmap screens and the user can move between
them fast, I can't afford loading them on the fly.
(tried it).
Click to expand...

If it's possible to reduce color depth, it's probably worth doing so. Also,
how it's stored (color depth) can be affected by how it's loaded.
Minimizing the memory footprint of the bitmaps would be something to look
at.
- So, if we assume that I'm almost out of memory, can you please help me
find out how can I know how much space do I still have for additional
dll(s) ?
Click to expand...

We've not given an answer, becasue it's not something that's simple to find
out. There is no "GetAvailableDllLoadingSpace" API. FIrst you need to
fully understand how native DLLs are loaded. They are top-down, on 64k
boundaries, requiring contiguous space and they can't be loaded into the
same address that a DLL is loaded in another process.

Application heap allocations come up from the bottom. They're reserved in
64k blocks but committed in 4k pages. Of course the GC heap work even
separately from that. You can have a lot of free GC Heap space, but that
space is still allocated fromt he system and not available for loading DLLs.

So sure, you can call GLobalMemoryStatus and get a rough idea of the virtual
space you have left in the process, but it won't tell you how much of that
space is not contiguous, in an address that another process already loaded a
DLL, not 64k aligned, etc. etc.

Getting that number is possible, but it's a *lot* of work and will be pretty
slow. Not somethig that you can realistically do at run time.

And of course the results will always be changing, especially across
different target platforms, with different stuff loaded by the OS at boot.
 
Thank you very much for all the support.

Empi

It doesn't matter where they're loaded from (file, DLL, stream or
whatever). They're loaded into a manage Bitmap of Image class instance,
and that takes memory resources.


If it's possible to reduce color depth, it's probably worth doing so.
Also, how it's stored (color depth) can be affected by how it's loaded.
Minimizing the memory footprint of the bitmaps would be something to look
at.


We've not given an answer, becasue it's not something that's simple to
find out. There is no "GetAvailableDllLoadingSpace" API. FIrst you need
to fully understand how native DLLs are loaded. They are top-down, on 64k
boundaries, requiring contiguous space and they can't be loaded into the
same address that a DLL is loaded in another process.

Application heap allocations come up from the bottom. They're reserved in
64k blocks but committed in 4k pages. Of course the GC heap work even
separately from that. You can have a lot of free GC Heap space, but that
space is still allocated fromt he system and not available for loading
DLLs.

So sure, you can call GLobalMemoryStatus and get a rough idea of the
virtual space you have left in the process, but it won't tell you how much
of that space is not contiguous, in an address that another process
already loaded a DLL, not 64k aligned, etc. etc.

Getting that number is possible, but it's a *lot* of work and will be
pretty slow. Not somethig that you can realistically do at run time.

And of course the results will always be changing, especially across
different target platforms, with different stuff loaded by the OS at boot.


--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com
Click to expand...
 
Back
Top