How to deallocate the memory?

Question

0.00/5 (No votes)

See more:

I am working on an application which is using WCF services. This service will get a call from some other application and will return the output to the caller. The response over here is in the form of concrete object which of type of a class.

When this application gave response back to the caller even then it is holding some memory. So iI tried different ways to deallocate this memory once the operation is done but it still holding the memory. Ways I tried to resolve the issue:

What I have tried:

I created one thread before returning the response and called the sleep function for 1 min. This time it works. The memory is reduced and I receive the desired output. is this the correct way?
I also tried to dispose the response object in finally block but in that case memory is reduced but I don't received the output.

Posted 24-Sep-17 21:28pm

tishi208

Updated 25-Sep-17 16:09pm

Add a Solution

Comments

Tomas Takac 25-Sep-17 3:47am

Why? What's your motivation for tampering with memory management? You do know that memory is managed automatically in C#/.NET right?

tishi208 25-Sep-17 3:55am

@Tomas Takac
I know memory is managed automatically but i want to reduce the size of the memory consumption after the operation is complete which is not happening so i tried to give a explicit call to garbage collection to resolve this. I know its not a good practice. If you have any other solutions please let me know

Tomas Takac 25-Sep-17 5:53am

The memory doesn't need to be released right away. Does the memory usage grow over time? Do you suspect a memory leak? Then you should use a memory profiler to find the source of the problem.

Are you saying the object you are sending over WCF implements IDisposable? I would avoid that and use a POCO message class to exchange data. In any case you should check if you implement the IDisposable pattern correctly, including the call from finalizer.

Last but not least, update your question (via Improve question) and add some code to illustrate your problem.

3 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Dave Kreskowiak · Answer 1 · 2017-09-25T04:49:00

If you're looking at Task Manager to determine the amount of memory your app is using, DON'T! It's lying to you.

What you see in Task Manager is how much memory is RESERVED for your app's execution, NOT how much it's actually using.

The .NET CLR manages the execution of your application and what's called the "managed heap". When your app starts, the CLR requests a chunk of memory and places that in the managed heap. Object instances created by your application are allocated on the managed heap very quickly. If the heap is running low on memory, the CLR will request another block from Windows and, again, add it to the heap. This takes extra time so the CLR tries to "look ahead" by looking at what your app has been allocating and expands the heap as necessary to keep the performance of your app high.

The CLR maintains the size of the managed heap with a comfortable margin so it doesn't have to keep going back to Windows for more and more memory on every allocation since this process takes time and reduces your app performance.

Now, when objects are no longer needed by your application, the memory is freed, but NOT returned to Windows. It's returned to the managed heap.

Task Manager doesn't know anything about the .NET CLR and the memory it has reserved. All it sees is what Windows tells it. Windows is telling the Task Manager, "yeah, I gave that process x amount of memory. I have no idea what it's doing with it."

But, there is also a negotiation going on between Windows and the .NET CLR. If Windows starts running low on memory, it can ask the .NET CLR to return any memory it can spare and the .NET CLR will gladly free any unused memory in the managed heap and return it to Windows.

All of this happens automatically without you messing with it. Task Manager may tell you that "hey, we're running out memory!" when you're not. Windows just hasn't felt the need to go ask for any back from the .NET managed processes.

Kornfeld Eliyahu Peter · Answer 2 · 2017-09-25T01:23:00

There is no acceptable reason behind forcibly freeing the memory GC holds...
(The only possible application when you may know better the state of memory then GC is a single-instance/single-user app... Service is definitely not one of them...)
and... It is a very expensive operation...
and... GC holds the memory because no-one claimed it, because no-one needs it now - so why free it?
Learn about GC: Garbage Collection | Microsoft Docs[^]

Graeme_Grant · Answer 3 · 2017-09-25T16:09:00

Dave's article does a nice job explaining memory management. There is more to how the GC manages memory however is beyond the scope of this forum. A quick google search[^] should turn up lots of detailed articles that cover the finer points.

The only thing that you need to really worry about are memory leaks. These usually only happen when resources are not released. Trying to force the GC to do it won't fix it, only fixing the code will. Memory leaks can usually be seen in the Debugger's Diagnostic tools. Here is a quick introductory video: Debugging Memory Leaks Using New .NET Memory Diagnostic Tools | Visual Studio 2013 Launch | Channel 9[^]

How to deallocate the memory?

3 solutions

Solution 2

Solution 1

Solution 3

Add your solution here

Preview 0