harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] Class unloading support
Date Sat, 28 Oct 2006 01:25:44 GMT


Xiao-Feng Li wrote:
> On 10/28/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>>
>>
>> Xiao-Feng Li wrote:
>> > All, I think the problem now is mainly about the class unloading
>> > design not about whether class unloading happens in server
>> > environment.
>>
>> I think the problem is if class unloading happens cleanly.  Period.  The
>> fact that it most often happens in a server environment is irrelevant, 
>> IMO.
> 
> Yes. That's also my opinion. The _design_ of class unloading is the
> focus of the discussion.
> 
>> > Class unloading is definitely a feature required in future; but with
>> > the significance of the required modifications in JVM by this class
>> > unloading design 2 (using Java object for Vtable), it is probably
>> > safer to move this work into a branch at the moment until all other
>> > components are ready for it, and after we have thorough evaluation on
>> > it since there are still issues to be resolved or discussed.
>>
>> I don't really agree.  It could be because of my background, but my
>> experience with java is in long-running, server-side processes, and
>> clean class-unloading is important.
> 
> I don't know what you "don't really agree". :-) 

Ah. Sorry - you said "it's required in future".  I think that it's 
required now, but that isn't actually at odds with what you said :)


> My comment was that we
> need thorough study to enable the special design so that the ongoing
> development in other components are not impacted too much, and there
> are still some issues to be discussed and resolved in this design.

Agreed.

> 
>> > Or we can keep it in JIRA and keep the discussion and evaluation going
>> > on before we decide to support the special design (Java Vtable) in
>> > other components.
>>
>> That's a different story :)  I'm not advocating one design over another,
>> but we have to be able to dump classloaders w/o leaking memory.
> 
> Agree again. :-)

So we're in violent agreement :)

geir

> 
>> geir
>>
>> >
>> > How about it?
>> >
>> > Thanks,
>> > xiaofeng
>> >
>> > On 10/27/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>> >>
>> >>
>> >> Rana Dasgupta wrote:
>> >> > My knowledge in this area is limited. But my understanding was 
>> that web
>> >> > servers and other similar hosts recycled processes periodically as
>> >> > standard procedure, thereby tearing down all associated resources.
>> >>
>> >> Yes, but that has nothing to do with what would be happening in the 
>> app
>> >> server the web server talked to, if one had an architecture where a 
>> web
>> >> server "fronted" for the app server.
>> >>
>> >> > So
>> >> > classes loaded, but not used for a while went away anyway;
>> >>
>> >> Nope - they aren't loaded in the context of the webserver (when using
>> >> httpd).
>> >>
>> >> > this level of
>> >> > resource management was not really urgent. I know that IIS does 
>> this, I
>> >> > am not sure about httpd. I am not sure about other host 
>> environments.
>> >>
>> >> But a process fork model (or thread model) of a webserver has 
>> nothing to
>> >> do with what's going on in the VM.
>> >>
>> >> I'm talking about servlet engines and app servers like Tomcat and
>> >> Geronimo which have nothing to do with httpd.  Architecturally, 
>> they are
>> >> separated from the web server (unless you don't use an external
>> >> webserver, and just use the httpd connector in tomcat) and are 
>> separate,
>> >> independent processes.
>> >>
>> >>      httpd  <------>  Tomcat
>> >>
>> >> The java-based app servers are long running processes, running for 
>> weeks
>> >> or months.  We need to do clean class unloading.
>> >>
>> >> geir
>> >>
>> >>
>> >> >
>> >> >
>> >> > On 10/27/06, *Geir Magnusson Jr.* <geir@pobox.com
>> >> > <mailto:geir@pobox.com>> wrote:
>> >> >
>> >> >
>> >> >
>> >> >     Rana Dasgupta wrote:
>> >> >      > Aleksey,
>> >> >      >   I had a couple of questions.
>> >> >      >   You state that DRLVM does not implement the class unloading
>> >> >     optimization,
>> >> >      > and this may create memory pressure on some applications
that
>> >> >     load many
>> >> >      > classes. Do we have a real case / example where an
>> >> application is
>> >> >     stuck for
>> >> >      > insufficient memory because it uses a lot of classes 
>> initially
>> >> >     and then
>> >> >      > stops using them, but these are not unloaded? One can 
>> imagine a
>> >> >     web browser
>> >> >      > doing something like this. Is a web browser a typical use

>> case
>> >> >     for the
>> >> >      > Harmony JVM?
>> >> >      >
>> >> >
>> >> >     If I understand what you're asking correctly, you'll find this
>> >> pattern
>> >> >     in servlet engines or J2EE servers, where deployed apps can be
>> >> dumped
>> >> >     and reloaded repeatedly either during development or during
>> >> production
>> >> >     deployment, w/o taking the server down.
>> >> >
>> >> >     geir
>> >> >
>> >> >
>> >>
>> >
>>
> 

Mime
View raw message