Hmmm... Yes, some more details would be nice. If I get it right, in case of automagic unloading, GC does all the job without a knowledge whether it collects a class, a classloader or whatever else. Perhaps I'm missing something, but to provide a callback on class unloading, the GC must know the semantic of the object being collected.?
Alex. GC does not need any special knowledge about the semantic of the object being collected. We simply provide weak root to j.l.Classloader inside VM. When VM detects that this weak reference is zeroed (e.g. at the end of GC cycle) it destroys all native sources of appropriate classloader or schedule this destroy on some other time. I hope, I answered your question. Aleksey. On 10/29/06, Alex Astapchuk <[EMAIL PROTECTED]> wrote:
Mikhail Fursov: > On 10/28/06, Alex Astapchuk <[EMAIL PROTECTED]> wrote: >> >> Aleksey, >> >> > 1. Mark and scan based approach. >> > 2. Automatic class unloading approach. >> >> In the #2, is there any chance for other components to be notified about >> unloaded classes? >> > > Alex, > I asked Aleksey about the same feature some time ago. I was interested if > it's possible to deallocate profiler's data in EM for unloaded methods. The > answer was: OK you will get a callback from VM. So, this feature is in the > design. Let's wait Aleksey to give us more details about it. Hmmm... Yes, some more details would be nice. If I get it right, in case of automagic unloading, GC does all the job without a knowledge whether it collects a class, a classloader or whatever else. Perhaps I'm missing something, but to provide a callback on class unloading, the GC must know the semantic of the object being collected. ? -- Thanks, Alex
