-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
It's hard to tell how the MPS is performing #261
Comments
A few pointers. You can retrieve some statistics from mps_message_type_gc(). You can gain a very large amount of information via Telemetry. The MPS can collect a lot of statistics in a cool build. We are currently investigating ways to improve the availability of statistics with our commercial clients.
There is no resurrection in the MPS. Dead objects are recycled. Objects registered for finalization do not die until their finalization messages are deleted. I think we could improve the wording of Finalization. Finalization happens before death, not after it. |
An object can be resurrected during finalization tho, right? Eg the finalizer could store the reference in a static root or something , thus "ressurrecting" it |
Objects registered for finalization cannot die until their finalization message is deleted. You can copy a reference to those objects out of the finalization message before deleting the message, if you like. You can think of this as "resurrection" if you like, but it's important to realize that as far as the MPS is concerned, the object is alive. It will be counted as alive for all purposes, including statistics. |
yea |
so, how can we know when an object is truly dead as far as MPS is concerned? |
You could create a weak reference to the object. When that reference gets zeroed, the MPS has determined that it is not reachable from any root (except via weak references). What happens next depends on the pool class, but in the case of AMC the memory block that contains the object will be recycled, and may even be unmapped and returned to the OS for use by other processes, depending on memory pressure. |
We do not currently have a system whereby you can receive a message when a weak reference is zeroed. In theory you could modify the Manual Rank Guardian pool class to have a weak variant, but you'd need to register some sort of ID with each reference so you could work out which one had gone away. It's not clear to me what the use case for that is though. Do you have one? |
this would be related to #262 |
Tho this would be called when ANY weak reference is zeroed Eg, if two weak references to the same reference get zeroed, then said message would be posted 2 times, once for each weak reference |
The text you quoted from me does not mention calling anything or any messages. Are you talking about something you have implemented on top of your weak tables? |
Do you have a specific use case for wanting to know after an object has died? An example? |
never mind |
how would i go about obtaining GC statistics (eg, for profiling GC)
additionally how would we handle object resurrection ?
(eg, an object is assumed to have been collected, but is infact still live due to resurrection, leading to incorrect statistics related to live/dead objects)
at the moment i have the following
allocated_bytes
freed_bytes
allocated_obj_bytes/allocated_aligned_obj_bytes
freed_obj_bytes/freed_aligned_obj_bytes
The text was updated successfully, but these errors were encountered: