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 00:20:30 GMT


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.

> 
> 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.

> 
> 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.

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