Re: [cp-patches] RFC: Class Loader patch to record class withinitiating class loader

[Archie Cobbs]

Mark Wielaard wrote:
> But for a larger change like this it is probably good to get a sign-off
> by Robert, Stephen, Archie or any other runtime implementor who you know
> uses pristine Class/ClassLoader classes from GNU Classpath to make sure
> they agree that they will keep on using them. Or hear from people like
> Tom, David or Dalibor that the new interfaces will make it easier for
> them to adopt the GNU Classpath versions.
>
> If you have one or two runtime developers with you that say that the
> change is good and they can/will provide it soon (or at least by the
> time we do a new snapshot release) then I don't really see a problem
> checking changes in. We do have to make breaking changes from time to
> time and people cannot really expect non-released versions to work
> flawlessly all the time (otherwise we would do a release every day!).

For what it's worth, JCVM maintains its own intiated types and
defined types tables internally, so this patch does not make life
better (or worse). I would have to disable this code.

However the larger question of what is the right API is an interesting
one... not sure I could venture an answer without a lot of review/study.

One possibility I've considered is moving a lot more of the code out
of the VM and into Java. This of course would require everyone agreeing
on what that code should look like :-) But probably a bigger problem is
what to do with the bootstrap loader, which must be usable before any
classes are loaded.

So in JCVM, the end result is like this: I have to do all the machinery
in C anyway for the boot loader, so might as well re-use that same code
for user-defined loaders... referring here to the code which e.g. checks
whether the requested type is already in the initiated types tree, grabs
mutexes, checks whether another thread is already loading the type, adds
newly loaded types to the initiated types tree, etc.

The net result is that a simpler API where the VM does most of the work
is better in JCVM's case. In fact, the current code is more than
JCVM needs -- it doesn't need the loadedClasses hash table (so the new
USE_VM_CACHE flag is an improvement), nor most of the synchronization.
But other VMs may be different of course.

So this area is murky and highly VM specific which makes it hard to
imagine what the best answer is.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com