does Boo have a garbage collector?
what type?
Yes, as provided by the CLR.
Depends on the implementation of the runtime.
For Microsoft .NET, it is using a 3 Generational GC, see .NET Development (General) Technical Articles: Garbage Collector Basics and Performance Hints.
For Mono, it is using the Boehm conservative GC, but is migrating to a new Generational, Precise GC.
Since it's a .NET/CLR language, it relies on the garbage collector provided by that infrastructure. Although the garbage collector is an implementation detail to the infrastructure.
The two main CLR implementations are the Microsoft .NET Framework and the mono project.
If you're interested, you can read about the implementation of the MS.NET GC or the Mono GC.
Related
Ok, so I have an app with pretty heavy traffic (about 17 requests per second). The app is a REST API built with .Net Core 2.0 (just recently upgraded).
The app is hosted on Azure and we are having a problem that looked like a memory leak in that the servers would very slowly (over a week) eat up all the handlers and resources and eventually crash.
I have spoken a good bit to MS Support and they helped me narrow down the problem. Here is their last email:
"We are seeing a high amount of large objects (strings and arrays over
85000 bytes) can lead to GC Heap fragmentation and thus higher memory
usage in your application. We were investigating how to manage the
destructor and I can provide you the following documentation:
Why does the Finalize/Destructor example not work in .NET Core? Why does the Finalize/Destructor example not work in .NET Core?
(not a Microsoft official documentation but it can be use as reference )
ASP.NET Case Study: Bad perf, high memory usage and high
CPU in GC – Death By ViewState:
https://blogs.msdn.microsoft.com/tess/2006/11/24/asp-net-case-study-bad-perf-high-memory-usage-and-high-cpu-in-gc-death-by-viewstate/
Finalizers (C# Programming Guide):
https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/destructors
I will continue looking for more documentation related with the
destructor in .NET Core."
After this they basically said that Azure was not to blame and I needed to open up a "code" support ticket that costs about $500...
So I am coming here instead. :)
While I have been a .Net developer for over 15 years, this was my first time using .Net Core. I found this great article and used it as the backbone to my API (https://chsakell.com/2016/06/23/rest-apis-using-asp-net-core-and-entity-framework-core/).
When I compared it to other .Net Core examples it seemed to fall in line with those so I am reasonably confident that I am following "best practices", but I could be wrong.
My fear is that there is a fundamental problem with .Net Core (which those articles that MS referred to kinda suggest), but I am not sure how to find the answer. I don't want have to rewrite my code because of this, but aside from occasionally rebooting the servers I am not sure what my options are.
Thoughts?
Ok... for posterity... my eventual solution turned out to be a configuration setup issue... the destructor issue with Core wasn't a factor for me because we weren't sending strings large enough to trigger it.
You can see my approach and the eventual answer (using a singleton) in this question:
ASP.Net Core 2 configuration taking up a lot of memory. How do I get config information differently?
I recently read a blog entry by Jeremy Manson (Google), about how a more accurate and lightweight asynchronous sampling profiler. It relies on the "AsyncGetCallTrace" undocumented method in hotspot JVMs to gather the stack trace of a thread.
http://jeremymanson.blogspot.fr/2013/07/lightweight-asynchronous-sampling.html
My question to the JProfiler community is: can JProfiler in its current 7.2.3 version use AsyncGetCallTrace? Is this feature in the work for say JProfiler 8.0?
The tools interface of the JVM (JVMTI) that is used by profilers has a large test harness that ensures its compatibility and stability for each release. AsyncGetCallTrace is not part of that specification. The overhead of GetStackTrace is so low that it is not advisable for a general purpose profiler to sacrifice the benefits of a supported API for the percieved gains of an unsupported method.
What are Managed objects and unmanaged object in C++/CLI
Managed objects are a feature of the .NET framework and its implementation of a C++-like language, and have their memory managed for you by the .NET garbage collector. C++ itself has no such concept, and a better (in general) way of managing all resources (not just memory) called RAII.
The concept Managed/Unmanaged is not typically C++. It is Microsoft .Net technology speak.
In normal, plain C++ applications, the application itself is responsible for deleting all the memory it has allocated. This requires the developer to be very careful about when to delete memory. If memory is deleted too soon, the application may crash if it still has a pointer to it. If memory is deleted too late, or not deleted at all, the application has a memory leak.
Environments like Java and .Net solve this problem by using garbage collectors. The developer should not delete memory anymore, the garbage collector will do this for him.
In the 'native' .Net languages (like C#), the whole language works with the garbage collector concept. To make the transition from normal, plain C++ applications to .Net easier, Microsoft added some extensions to its C++ compiler, so that C++ developers could already benefit from the advantages of .Net.
Whenever you use normal, plain C++, Microsoft talks about unmanaged, or native C++. If you use the .Net extensions in C++, Microsoft talks about managed C++. If your application contains both, you have a mixed-mode application.
Managed objects do not exist in C++.
They exist in Microsoft's .NET extensions to C++, and a complete explanation would be a bit long, sorry.
We're building a MMO server, highly optimized for latency.
So, with the CLR 4.0 and with introduced new workstation GC, is it now possible to use Background Garbage collection on a Windows Server?
Apparently not. See this article, which specifically states that Microsoft is not offering background GC for server GC in V4.0 (though it looks like this is under consideration).
You might also find this essay (PDF) interesting, given what you're trying to do.
I'm new to C#/Java and plan to prototype it for soft real-time system.
If I wrote C#/Java app just like how I do in C++ in terms of memory management, that is, I explicitly "delete" the objects that I no longer use, then would the app still be affected by garbage collector? If so, how does it affect my app?
Sorry if this sounds like an obvious answer, but being new, I want to be thorough.
Take a look at IBM's Metronome, their garbage collector for hard real-time systems.
Your premise is wrong: you cannot explicitly “delete” objects in either Java or C#, so your application will always be affected by the GC.
You may try to trigger a collection by calling GC.Collect (C#) with an appropriate parameter (e.g. GC.MaxGeneration) but this still doesn’t guarantee that the GC won’t be working at other moments during execution.
By explicitly "delete" if you mean releasing the reference to the object then you are reliant on the garbage collector in C# managed code - see the System.GC class for ways of controlling it.
If you choose to write unmanaged C# code then you will have more control over memory, akin to C++, and will be responsible for deleting your instantiated objects, able to use pointers, etc. For more info see MSDN doc - Unsafe Code and Pointers (C# Programming Guide).
In unmanaged code you will not be at the mercy of the the Garbage Collector and its indeterminate cleanup algorithms.
I don't know if Java has an equivalent unmanaged mode, but this Microsoft info might help provide some direction on C#/.NET to use its available features for your requirement of dealing with the garbage collector.
In Csharp or Java you can't delete object. What you can do is only mark them available for deletion. The memory free up will be done by Garbage Collector.. It might be the case that Garbage Collector may not run during the life time of your application. However it's likely to run. When your system is becoming short of resources it is the most likely time when GC routines are run by the runtime. And when resources are low GC becomes the highest priority thread. So your application do get effected. However you can minimize the effect by calculating the correct load and required resources for your application life time and make sure to buy the right hardware which is good enough for that. But still you can't just bench mark your performance.
Besides just GC the managed application do get a slight overhead over the traditional C++ application due to the extra delegation layer involved. And a slight first time performance panelty since the run time needs to be up and running before your application get started.
Here are some references for developing real-time systems with the .net compact framework:
IEEE - C# and the .NET Framework: Ready for Real Time?
MSDN - Real-Time Behavior of the .NET Compact Framework
They both talk about the memory requirements of using the .net framework.
C# and Java are not for Real-Time development. Soft real-time is attainable however as you note.
For C#, the best you can do is implement the finalize/dispose pattern:
http://msdn.microsoft.com/en-us/library/b1yfkh5e(VS.71).aspx
You can request it to collect, but typically it's much better at determining how to do this.
http://msdn.microsoft.com/en-us/library/system.gc(VS.71).aspx
For Java, there are many options to optimize it:
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
Along with third party solutions like IBM Metronome as noted above.
This is a real science within CS itself.