While reading Xamarin docs under section "Performance", I've noticed the following chapter:
The following diagram illustrates a problem that can occur with strong references:
Object A has a strong reference to object B, and object B has a strong reference to object A. Such objects are known as immortal objects due to the presence of the circular strong references. This parent-child relationship is not unusual, and as a result, neither object can be reclaimed by the garbage collector, even if the objects are no longer in use by the application.
That's the first time I've heard of "immortal objects" in C#/.NET/Mono context.
The page then continues with a suggestion to use a WeakReference in one of the objects, which will remove the strong circular reference and fix this "issue".
At the same time, Xamarin docs on garbage collection claim that:
Xamarin.Android uses Mono's Simple Generational garbage collector. This is a mark-and-sweep garbage collector [...]
Aren't mark and sweep GCs unaffected by circular references?
The memory leaks due to circular references apply only for Xamarin.iOS, wich use reference counting for native objects.
The page about immortal objects also says:
Boehm – This is a conservative, non-generational garbage collector. It
is the default garbage collector used for Xamarin.iOS applications
that use the Classic API.
The second quote specifically talks about Xamarin.Android.
Related
In my application I'm creating some JS objects, and also on C++ side some objects for running some handling.
I would like to delete C++ objects when they are not needed anymore: the corresponding JS object is Garbage Collected.
I'm trying to find that in Cobalt source code/documentation but I cannot find that. I do see ScriptValue::Reference but this seems to be the opposite:
Prevent a JS object from being garbage collected by declaring a relation between a JS value and C++ object.
Could someone give some hints how this can be achieved? (getting some callback called in C++ when an object is garbage collected).
Any C++ class exposed to JavaScript must inherit (directly or indirectly) script::Wrappable which has a virtual destructor. This destructor will be called when a corresponding JavaScript object is destroyed, either as a result of garbage collection or JS VM teardown.
Usual caveats apply: GC order and timing are non-deterministic. If you need to free critical resources as soon as possible, expose explicit cleanup methods to JavaScript.
See cobalt::dom::Node::~Node() for example of a cleanup performed upon destruction.
I have started programming in Go and I was wondering when new(Object) is used it allocates memory to the size of that object right? If this is the case how do I free this memory once I have finished using the object?
I ask this because in C++ when new is used on an object you can delete the object once there is no longer any need for the object to be stored.
I have been searching to see if Go does have delete or something similar to C++ but I have been unable to find anything.
Any help is much appreciated.
As you see here:
Go is fully garbage-collected and provides fundamental support for concurrent execution and communication.
So you don't have to care about memory allocation.
Go has garbage collection. This means the Go runtime checks in the background if an object or any other variable is not used anymore and if this is the case, frees the memory.
Also see the Go FAQ: Why is the syntax so different from C? - Why do garbage collection? Won't it be too expensive?
In Go, unlike in C and C++, but like in Java, memory is managed automatically by a garbage collector.
There is no delete to call.
Off-topic:
in C++ when new is used on an object you can delete the object once there is no longer any need for the object to be stored.
You must delete, otherwise you have memory leak.
Suppose there is simple object like:
object = Object.new
As I know this creates Object in memory (RAM).
Is there a way to delete this object from RAM?
Other than hacking the underlying C code, no. Garbage collection is managed by the runtime so you don't have to worry about it. Here is a decent reference on the algorithm in Ruby 2.0.
Once you have no more references to the object in memory, the garbage collector will go to work. You should be fine.
The simple answer is, let the GC (garbage collector) do its job.
When you are ready to get rid of that reference, just do object = nil. And don't make reference to the object.
The garbage collector will eventually collect that and clear the reference.
(from ruby site)
=== Implementation from GC
------------------------------------------------------------------------------
GC.start -> nil
GC.start(full_mark: true, immediate_sweep: true) -> nil
------------------------------------------------------------------------------
Initiates garbage collection, unless manually disabled.
This method is defined with keyword arguments that default to true:
def GC.start(full_mark: true, immediate_sweep: true); end
Use full_mark: false to perform a minor GC. Use immediate_sweep: false to
defer sweeping (use lazy sweep).
Note: These keyword arguments are implementation and version dependent. They
are not guaranteed to be future-compatible, and may be ignored if the
underlying implementation does not support them.
Ruby Manages Garbage Collection Automatically
For the most part, Ruby handles garbage collection automatically. There are some edge cases, of course, but in the general case you should never have to worry about garbage collection in a typical Ruby application.
Implementation details of garbage collection vary between versions of Ruby, but it exposes very few knobs to twiddle and for most purposes you don't need them. If you find yourself under memory pressure, you may want to re-evaluate your design decisions rather than trying to manage the symptom of excess memory consumption.
Manually Trigger Garbage Collection
In general terms, Ruby marks objects for garbage collection when they go out of scope or are no longer referenced. However, some objects such as Symbols never get collected, and persist for the entire run-time of your program.
You can manually trigger garbage collection with GC#start, but can't really free blocks of memory the way you can with C programs from within Ruby. If you find yourself needing to do this, you may want to solve the underlying X/Y problem rather than trying to manage memory directly.
You can't explicitly destroy object. Ruby has automatic memory management. Objects no longer referenced from anywhere are automatically collected by the garbage collector built in the interpreter.
Good article to read on how to do allocation wisely, and a few tools you can use to fine tune.
http://merbist.com/2010/07/29/object-allocation-why-you-should-care/
I am working with mono droid, using the mvvmcross framework provided by slodge. However I am having some memory issues. I am disposing bitmaps in the activities ondestroy methods and I am wondering if it is possible to help the GC collecting unused objects of viewmodels. If you try setting the viewmodel in the activity to null it all goes to hell and it is clearly not the right way to go.
Do you guys have any suggestions to an approach?
Regards
The mvx framework tries to ensure that the activity owns the viewmodel.
So in theory, after your activity has being destroyed, then the gc should be able to collect all of your c# objects - the activity, the views it owns, the view model and the objects it owns.
Where i've seen this this go wrong is where any 'global' or singleton object owns a reference to a view or viewmodel object. For example:
if a view registers itself with a singleton - eg an http image loader - and then that singleton keeps a reference to the view, preventing it from being garbage collected.
if a viewmodel subscribes to an event on a central service (often a singleton) and doesn't unsubscribe from it - then in this situation, the viewmodel can't be garbage collected (and often this also prevents other objects being collected too)
Generally both these types of errors can be solved by performing cleanup actions on activity destroy. However, other approaches are also available - eg for event subscriptions you can try using weak references (this is an approach taken on other platforms too - eg mvvm light's messenger)
From experience, the areas where leaks are most noticeable are around 'big objects' like images - their size helps them become noticeable. However, the real challenge on monodroid is identifying where the leaks are - fixing them is generally comparatively easy.
Sadly, there isn't currently a memory profiler available for droid. If you are cross-compiling to wp7, then certainly for viewmodel objects/leaks you can use its memory profiler. If not, then the way I generally try to solve memory leaks is to amplify them - try writing a sample that rapidly reproduces them - eg by adding large byte[] members to data elements or by rapidly repeating actions. Once you have the leak easily reproduced, then you can try to find the leaks by placing trace statements in finalizers, in event remove handlers, etc.
Here's my situation:
I have .NET wrapper-objects in a C++/CLI layer that hold pointers to unmanaged C++ objects. I've implemented the finalizer so that it deletes the unmanaged memory pointed to by the wrapper-object on garbage-collection and sets the pointer to null.
Here's the problem:
I'm watching the finalizer for the .NET wrapper-object and it gets called twice and tries to delete the same memory twice, indicating that I have somehow created 2 .NET wrapper objects that go out-of-scope, and are garbage collected while I'm still expecting the wrapper object to be in scope (these wrapper objects are getting passed to a VB.NET application).
Here's my question:
Is there anyway for me to check the handle value so that I can confirm where the wrapper objects are getting created (copied or whatever)? Currently I'm looking at the handle values (EG - 0x0014fe80), but I see 3 different values for when the object is created, added to a collection, and deleted. So I'm not sure if the GC is just moving stuff around and this is the same object, or if I'm actually seeing 3 different objects that reference the same unmanaged memory. I would like to resolve the duplicate object copies if possible, but I understand that I will probably want to implement some sort of smart pointer so that this doesn't happen.
Thanks,
Ian
Take a look at this question
Here is an implementation of a scoped_ptr that is noncopyable and has an auto-release mechanism for unmanaged objects, by #Ben Voigt
Yeah, I ended up modifying an auto_ptr class to be a shared pointer to ensure that the unmanaged memory is only deleted once through the smart pointer finalizer. I'm assuming I did something similar to all the other implementations; I created a static dictionary in the auto_ptr template class, using the native pointer value as the key, that is checked every time the finalizer is called to update the count of each item, or delete the memory.