harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Astapchuk <alex.astapc...@gmail.com>
Subject Re: [drlvm] Class unloading support
Date Mon, 30 Oct 2006 03:21:14 GMT
Ivan,

Ivan Volosyuk:
> On 10/29/06, Alex Astapchuk <alex.astapchuk@gmail.com> wrote:
>> Mikhail Fursov:
>> > On 10/28/06, Alex Astapchuk <alex.astapchuk@gmail.com> 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.
> 
> The callback will be called by class unloading implementation (for
> #1). It will definetly know everything about classloader being

Sure, I see no problem with #1.

But I'm really curious how the callback can be implemented in the 
*second* approach - with automatic class unloading.


-- 
Thanks,
   Alex


> deallocated. EM just needs to make relation between its data
> structures with corresponding classloader and free them by request.
> 


Mime
View raw message