I am not sure the practical value of such a thing, but I am wondering if in for example Java, an object can be instantiated so that if a variable holds a reference to it, no other variable can do so unless the first variable no longer does. The object could only be in a single list. Intuitively, this would correspond more to real life objects that can only be in one place at a time.
Related
So my question is: the "Title" and what are the garbage collection rules for dynamic arrays in SystemVerilog?
Context:
In my program, I found a bug where you can instantiate a dynamic array in a function (locally) and add elements to that array within that function, but if you don't delete the array, the entries remain there (i.e. memory and reference is preserved). So when you call the function again, all the entries that were previously entered can be accessed. The solution is to simply delete the dynamic array before you exit the function. I am assuming the array isn't deleted because the array is instantiated on the Heap instead of the Stack, and the compiler doesn't know when to garbage collect it because it could be a returned reference (please correct me if I am wrong - I am not familiar with the garbage collection rules for dynamic arrays).
However, what happens if the dynamic array is instantiated within a class (as a member variable)? How do you know if the dynamic array is deleted (i.e. reference and memory is removed)? What are the garbage collection rules for that case?
I have example code to demonstrate the issue if it is helpful but I don't think it is necessary to include it (let me know if you'd like an example).
P.S. The same thing happens for associative-arrays as well (because I think it is a form of dynamic array type in SystemVerilog).
Thanks!
SystemVerilog has three different kinds of variable lifetimes:
static -- exists for the entire life of the simulation. Initilized once at time 0. Can be referenced from outside the scope of where it's declared
automatic -- a new instance gets created and initialized for each entry to the scope where it is declared (must be a procedural scope). Its lifetime ends when exiting the scope, and all nested scopes exit (to handle fork/join_none) Can only be referenced from within the scope where it is declared
dynamic -- created by the execution of a procedural statement. It's lifetime can end a number of ways, but normally by executing a procedural statement.
Dynamically sized arrays have a compound concept of lifetimes. Individual elements have dynamic lifetimes, but the array as a whole aggregate can have any of the above lifetimes. For the purposes of your question, I think we can just consider the array as an aggregate. That means whenever the lifetime of an array variable ends, all the dynamically allocated elements are reclaimed
Class objects have dynamic lifetimes, but the class variables that hold handles referencing class objects can any of the above lifetimes. But since more than one class variable can reference the same class object, the lifetime of class object ends when there are no more class variables referencing that object. So if that class object contains dynamic array variables, those variables lifetime end when the objects lifetime ends.
SystemVerilog doesn't specify how garbage collection works. When the lifetime of something ends, you can no longer access it. There is no way to know when the memory actually gets reclaimed.
Your problem seems like you have a statically declared dynamic array inside a function, or a static function argument. In Verilog, all non-class functions have static lifetimes by default. Class methods can only have automatic lifetimes. If this explanation does not answer your question, you'll need to post some code.
BTW, this became the subject of my DVCon 2021 Paper and Presentation
Can React.useMemo second argument array contains an object?
I ask this question because I have an expensive computation based on an object's value.
I don't know should I expand the object, or just simply pass the object into that array.
It is possible to use an object as 2nd argument. But it depends on how the object behaves. If there will be always a new instance of this object each time the affected value(s) has changed, React.useMemo will be able to detect the change. Since React.useMemo will only do an instance compare in case of an object, it will not detect changes within that object if the instance remain the same. If the instance changes more often then the affected properties, it would be better to extract only the required properties and hand them over individually. This will ensure the calculition will only be done if need.
I have a class whose objects are extensively used using shared_pointers. However, I want to track the usage of these objects and when the refcount goes to a particular value I want to delete the object. How can we do this ? I was thinking of overriding the shared_ptr's destructor so that I can decrement the refcount when every shared_ptr reference goes away. However, looks like that is not possible. What are the alternatives ?
You really wouldn't want to do that because if the refcount is greater than zero it means there are still pointers pointing to the object out there, probably intending to access it.
If you really wanted to do something like that, you'd have to make your own shared_ptr class, but I'd also add functionality for checking if the pointer is still valid since it might disappear on people.
Say I wanted to store objects statically inside their own class. Like this:
public class Foo
{
private static int instance_id = 0;
public static List<Foo> instances = new List<Foo>();
public Foo()
{
instances[instance_id++] = this;
}
}
Why?
I don't need to create unique array structures outside the class (one will do).
I want to map each object to a unique id according to their time of birth.
I will only have one thread with the class in use. Foo will only exist as one set in the program.
I did searching, but could find no mention of this data structure. Is this bad practice? If so, why? Thank you.
{please note, this question is not specific to any language}
There are a couple of potential problems I can see with this setup.
First, since you only have a single array of objects, if you need to update the code so that you have lots of different groups of objects in different contexts, you'll need to do a significant rewrite so that each object ends up getting associated with a different context. Depending on your setup this may not be a problem, but I suspect that in the long term this decision may come back to haunt you.
Second, this approach assumes that you never need to dispose of any objects. Imagine that you want to update your code so that you do a number of different simulations and aggregate the results. If you do this, then you'll end up having your giant array storing pointers to objects you're not using. This means that you'll (1) have a memory leak and (2) have to update all your looping code to skip over objects you no longer care about.
Third, this approach makes it the responsibility of the class, rather than the client, to keep track of all the instances. In some sense, if the purpose of what you're doing is to make it easier for clients to have access to a global list of all the objects that exist, you may want to consider just putting a different list somewhere else that's globally accessible so that the objects themselves aren't the ones responsible for keeping track of themselves.
I would recommend using one of a number of alternate approaches:
Just have the client do this. If the client needs to keep track of all the instances, just have them always create the array they need and populate it. That way, if multiple clients need different arrays, they can do so. You also avoid the memory leak issues if you do this properly.
Have each object take, as part of its constructor, a context in which to be constructed. For example, if all of these objects are nodes in a quadtree, have them take a pointer to the quadtree in which they'll live as a constructor parameter, then have the quadtree object store the list of the nodes in it. After all, it seems like it's really the quadtree's responsibility to keep track of everything.
Keep doing what you're doing, but using something with weak references. For example, you might consider using some variation on a WeakHashMap so that you do store everything, but if the objects are no longer needed, you at least don't have a memory leak.
I have a collection(arraylist) of Ref `s ,the objectify documentation says that I need to initialize collections for them to be persisted and hence modified in the future.....
Now , Ref points to an object but when I launch my app for the first time I dont have any objects in the data store...so whats the best way for me to initialize a dummy value......
Is my assumption that a Ref<> needs to point to a real object in the data store?
Two things:
You should just initialize an empty collection. You don't need to add anything to it. eg, field = new ArrayList<Ref<Thing>>();
It's actually not even required that you initialize the collection. It's just a good idea for reasons that will become apparent if you use the system for a while.