[jvm-l] Re: Ability to force class unloading in JDK 6 Update 4?

2008-01-17 Thread Ted Neward
All of the scenarios you describe below suggest, then, that so long as a strong reference is held to the class, the class is not eligible for unloading. That means, of course, that once all strong references have been dropped, the class is now eligible for unloading. Which is exactly how--in

[jvm-l] Re: Ability to force class unloading in JDK 6 Update 4?

2008-01-17 Thread Yardena
Hi, I'm a bit hesitant to step in the discussion among such knowledgeable gentlemen, so forgive me if the suggestion is too naive :-) The class loader doesn't unload individual classes because they can hold static members or have static initializers, and unloading the class may break the

[jvm-l] Re: Ability to force class unloading in JDK 6 Update 4?

2008-01-17 Thread Attila Szegedi
Your idea wouldn't be bad as such, except for few devils in details: - The code of the java.lang.ClassLoader class (at least in Sun's implementation) is engineered so that you just can't override the behaviour where it strongly references each Class object it creates. - And then there's also

[jvm-l] Re: Ability to force class unloading in JDK 6 Update 4?

2008-01-17 Thread Per Bothner
John Wilson wrote: One thing I have considered is aggregating all these closures/lambda/etc in a compilation unit as static methods on a single class. This means that you amortise the cost of a classloader over several methods. Instances of the function object delegate to the static method.

[jvm-l] Re: Ability to force class unloading in JDK 6 Update 4?

2008-01-17 Thread John Wilson
On Jan 17, 2008 5:48 PM, John Cowan [EMAIL PROTECTED] wrote: On Jan 17, 2008 6:30 AM, John Wilson [EMAIL PROTECTED] wrote: One thing I have considered is aggregating all these closures/lambda/etc in a compilation unit as static methods on a single class. This means that you amortise the

[jvm-l] Re: Ability to force class unloading in JDK 6 Update 4?

2008-01-17 Thread John Wilson
On Jan 17, 2008 4:51 PM, Per Bothner [EMAIL PROTECTED] wrote: John Wilson wrote: One thing I have considered is aggregating all these closures/lambda/etc in a compilation unit as static methods on a single class. This means that you amortise the cost of a classloader over several

[jvm-l] Re: Ability to force class unloading in JDK 6 Update 4?

2008-01-17 Thread Charles Oliver Nutter
Adam Bouhenguel wrote: Why not only allow class unloading only for classes without static fields, static methods, or static initializers? That side-steps the initialization issues and means that you need an instance in order to use it (no static elements + no references = no problem

[jvm-l] Re: Ability to force class unloading in JDK 6 Update 4?

2008-01-17 Thread Charles Oliver Nutter
John Wilson wrote: wasn't there a problem with Singletons getting GCd? Like you I think I once knew and have now forgotten. Getting old If so this would be solved by the no statics requirement. It's certainly a possible reason why the hard reference exists. - Charlie

[jvm-l] Re: Ability to force class unloading in JDK 6 Update 4?

2008-01-17 Thread Charles Oliver Nutter
John Cowan wrote: On Jan 17, 2008 6:30 AM, John Wilson [EMAIL PROTECTED] wrote: One thing I have considered is aggregating all these closures/lambda/etc in a compilation unit as static methods on a single class. This means that you amortise the cost of a classloader over several methods.

[jvm-l] Re: Ability to force class unloading in JDK 6 Update 4?

2008-01-17 Thread John Cowan
On Jan 17, 2008 1:06 PM, Charles Oliver Nutter [EMAIL PROTECTED] wrote: * Then we used a hand-written indexed method handle like you describe. Again, it worked (albeit a bit slower than individual methods), but it was too much effort to implement by hand and wouldn't work for generated code.