Dynamic Class Reloading

Peter B. Kessler Peter.Kessler at Sun.COM
Sat Jul 4 21:51:34 UTC 2009

Robert Marcano wrote:
> On Sat, Jul 4, 2009 at 12:54 PM, Andrew Wiley<debio264 at gmail.com> wrote:
>> I'm looking for something more general than that... let me just describe the
>> functionality I'm trying to achieve.
>> I'm writing a MUD (it's basically a text-based RPG), and I'm trying to come
>> up with some equivalent for the "copyover" or "hot boot" functionality that
>> MUDs written in C and C+ have. Basically, they write the state of the game
>> out to a file, have the MUD execute itself, and then load the game back up.
>> In this way, a MUD can reboot without disconnecting any of the players. The
>> socket descriptors aren't closed during the reboot, which I believe cannot
>> be replicated in Java.
>> In Java, I was hoping I would just be able to reload classes without
>> rebooting the MUD to come close to duplicating this functionality.
> I think that still can be done with an standard JVM, use you own
> classloader, be careful making you class serialization works when the
> classes definitions change, the only problem you will have is that
> released JVMs does not have a way to free the classloader you are
> discarding, something that is being resolved with OpenJDK 7, so each
> time you "reboot" you will not free the memory used by the previous
> classloader (class definitions not instances data)

The ClassLoaders and the Classes they load will be garbage collected when there are no more instances of *any* Classes loaded by that ClassLoader.  Each Object instance has a reference to its Class, and each Class has a reference to its ClassLoader, and each ClassLoader has a list of all the Classes it has loaded.  When there are no more instances of any of the Classes, there are no reachable references to the ClassLoader.  It's sometimes tricky to make sure your application drops all references to the instances.  That's among the reasons you want to write your own ClassLoader, so that Classes you have replaced can be collected.  And among the reasons you want your ClassLoader to load as few classes as possible, so extraneous objects don't end up hanging on to the ClassLoader and all the other Classes it loaded.

			... peter

More information about the discuss mailing list