Hi,
Which class loader do you think was being used ? It may be an
artefact of that class loader. For example Tomcat 3.1b will
automatically reload servlets from the web-inf directory if you
recompile it (as long as it was not loaded from the class path).
Presumably to do this it can't immediately return the already loaded
class, it has to hit the disk to check the last modification time of the
.class file to see if it is newer than the class already loaded which
may slow the whole process down a lot.
Also, is it possible that OptimizeIt is using its own class loader
to instrument the classes being loaded so it can profile their behaviour
better and the behaviuor you are seeing is a side effect of that ?
Regards,
Padraig
Boysko, Glenn wrote:
> Gary:
>
> Thanks for your response. I will try to quantify the actual cost of
> the current
> implementation. I would think that a more efficient implementation
> would incur
> this class loading cost once per thread...
>
> Thanks,
> Glenn
>
> -----Original Message-----
> From: Gary L Peskin [ mailto:[EMAIL PROTECTED] ]
> Sent: Wednesday, August 29, 2001 12:00 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Contention on Class Loader for Extensions class
>
>
> > "Boysko, Glenn" wrote:
> > I was finding that by just running two threads concurrently, both
> > threads where
> > blocking on the same monitor which was owned by the system class
> > loader.
> >
> > I guess I'm assuming that if two threads are both trying to load the
> > same class at the same
> > time that there will be synchronization, such that thread A will wait
> > for thread B to finish
> > loading the class. Is this not the case?
>
> Glenn --
>
> I'm really not familiar with the internals of particular versions of
> Sun-supplied classloaders. However, I would think that if there was any
> synchronization at all, it would be very, very short or multithreading
> of any sort would never work well. Besides, once the class is loaded,
> it should stay loaded for that classloader. It isn't loaded twice so
> there really should be a very tiny wait.
>
> I understand that you're seeing this in OptimizeIt but it's difficult
> for me to believe that this is the cause of any performance problems.
>
> Gary
>
