On 10/27/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>Yes. That's also my opinion. The _design_ of class unloading is >the >focus of the discussion.
I think that before doing an optimization, it is a good idea to understand why and where it is needed, and if the usage scenario fits what the software is intending to do. So this discussion is not misplaced. I am not very comfortable with adding a solution before we have understood the problem. Probably the first step is to create a use case that can be used to see if class unloading is the solution.
> 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". :-) 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.
I have the same question. At this point, solution 2 looks more sensible than solution 1. But that's about all. The design is quite invasive. If we want to prototype this, my suggestion would be to do this in a branch, create a use case, demonstrate its value, run stability tests, and then merge it.
> 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.
