How can I output information regarding object allocations in the JVM? Specifically, I wanted to output the thread ID, object ID, object size, and the number of object references in that object, each time there's an allocation and save it to a textfile. Thanks!
You can profile the application with VisualVM. You can save snapshots at any arbitrary time. Im not sure if its exactly what you want, but it seems pretty close.
Related
I have N threads querying a webservice and generating a file, then waiting 30 seconds, then doing it all over again.
I have another N threads opening and reading those files, inserting into a database, removing the files, waiting 100 milliseconds, then doing it all over again.
In all those objects there are a lot of methods with a lot of local variables: integers, strings, arrays, and other framework-specific objects.
Recently we are increasing the number of threads to read those files, because the webservice is returning a lot more data.
What gains can I expect by turning all the local variables into object attributes (instance variables)?
I presume it's not going to be so many instantiations, since that will be done once when the object itself is instantiated.
I'm using Delphi, but I believe it can be answered to any programming language or framework.
I don't think that there will be a remarkable performance increase if you turn the local variables into object attributes. However, generating a file from one thread, reading it from another one, and then deleting the file, sounds like the real bottleneck. If there is no really good reason to use a file as temporary storage, use a single thread instead of two for querying the webservice and then writing the data to the database.
Is is possible to garbage collect a certain object in Pharo?
E.g. I know that certain object is not (should be not) referenced by any other object. And it takes a lot of space. Does it make sense to just run general garbage collect on system? Or it is possible to remove from heap just specific object/tree
Smalltalk garbage collectors can't garbage-collect just a single object.
There are two basic techniques used - generation scavenging and mark and sweep. Generation scavenging works on new and relatively new objects by copying the used objects into another unused space and ignoring all the garbage. Objects that get copied a lot of times are moved to "old space". Old space is garbage collected by a mark and sweep algorithm. This algorithm loops through all Smalltalk objects and marks them as "unmarked". It then traverses through all accessible objects and marks them as "marked". In the final sweep, anything that's still marked as "unmarked" is freed.
There's no way to run either algorithm on a single object.
No, it does not makes sense, and is not possible.
Also it does not make sense to manually run the garbage collector (which you can do, of course)... system should run gc when needed and you will get that space back.
The whole purpose of a gc is that you do not have to take care about that.
I think you're looking for a reference list.
(i.e. which object is keeping your object not garbage collected).
Might be a Global variable somewhere. Something in a class variable....
I has a question that.
I need a runtime attribute in MyEntity, it is changed very offen.
And there are many MyEntity in core data.(such as 1000,0000);
I know that the transient attribute wont be saved in the disk, so these 1000,0000 MyEntities must be in memory all the time? but there are so many MyEntites,
the memory is large enough to keep 1000,0000 MyEntities?
If you need to change values on a large number of objects, those objects must exist. This is true whether or not you're using Core Data.
With Core Data there are various options for keeping memory under control-- getting rid of individual objects by re-faulting them, or getting rid of all managed objects by resetting the managed object context, for example. But it's hard to tell what you're really trying to do here and why any of this is needed. If this attribute is transient, why would you want to change it on an object that you're not using, that's not even loaded into memory? You could load the object, change the transient value, and then get rid of the object to keep memory use under control. But since the transient attribute doesn't get saved, what's the point? When you're done, nothing has changed. Why not just skip the update completely?
I just want someone explain it to me that how does GC discover that those memory blocks (pictured in red area) are garbage when their reference count is more that 0 but they are practically inaccessible?
There's set of "root objects" which are considered always accessible: e.g., Thread references, static variables, class references. If some object can not be reached via link of references from these root objects, it considered to be available for GC, even if there are some references to that object.
GarbageCollector works based on Java Memory Model. In java available application memory is divided in two parts: Heap and Stack. A object is stored in heap memory and can be accessed by 2 ways :-
1) Object can have reference variable which is stored in stack memory. In this case object can be directly accessed by using it's reference variable.
2) Object can be contained by any other object and would not have any reference in stack memory. In this case this object can be accessed only by using that container object. So if container object is garbage collected then this object must be eligible for garbage collection.
While doing GarbageCollection GarbageCollector checks whether a object is accessible directly or indirectly by any reference available in stack if it is then it won't collect this object else it do collect it.
The details of the GC algorithm are implementation dependent in Java, so it depends on your VM. But most VMs do not use reference counting. The official VM even has several configurable algorithms available. So it is hard to generalize about this.
i know GC release the memory of obj which is not used in any further but i know one thing that GC release memory in which form of like object or refrence or value....
please help me.
thanks in advance...
As a response to the comments to the question, it seems that you need clarification of a few concepts:
In .NET, objects live somewhere in the memory. A reference is kind of like a pointer to such an object/memory location. A value is some integral value (a number like 123).
For example, say you have an object of type MyClass, and you have created a new instance. This object contains a string. That string is another object, and your instance of MyClass holds a reference to the string object.
The garbage collector operates only on objects. It keeps track of the references to an object, if nobody is referencing the object any more the garbage collector can free that object up. In our example, if the garbage collector notices there's nobody holding a reference to the instance of MyClass, then it makes sure that object is freed. That in turn makes the reference to the string disappear, and the garbage collector can then also free the string (if nobody else is holding a reference, of course). Values don't need to be treated in any special way as they are part of the memory that belongs to an object (and thus cannot be freed "independently").
The same is true with Java, BTW.
An object of a reference type (a class) becomes garbage when no references to it exist anymore. It will be collected some time after that, whenever the GC runs next. The reason why these objects can be garbage is because they can be referenced from multiple places in the program, so no individual part of the program can release the object because other parts might still need it. The GC's responsibility is to discover when no part of the program needs the object anymore.
An object of a value type (a struct, or a built-in type like an integer) is simply copied to each place that needs to use it, so there's no problem of one value being used from multiple parts of the program. No GC is needed for value types, because they're always part of something else that ensures they're released. A value stored on the stack (e.g. a local variable within a method) is released when the method returns. A value stored in a class object is released when that class object becomes garbage.