[5815] in Release_7.7_team
Re: JDK 1.6 slowness on Suns
daemon@ATHENA.MIT.EDU (Robert Basch)
Tue Aug 21 13:27:13 2007
In-Reply-To: <7E01F947-AECE-40FD-B62E-E5A760F35D66@MIT.EDU>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <ABFC186D-8065-4BBA-A804-30F938459350@mit.edu>
Cc: Alex T Prengel <alexp@mit.edu>, release-team@mit.edu
Content-Transfer-Encoding: 7bit
From: Robert Basch <rbasch@MIT.EDU>
Date: Tue, 21 Aug 2007 13:25:57 -0400
To: William Cattey <wdc@mit.edu>
X-Spam-Flag: NO
X-Spam-Score: 0.00
Hi.
I was the one who encountered the problem testing JDK 1.6 on
Solaris, a couple of months ago. Here is a description of the
problem:
> I encountered a problem in testing JDK 1.6 on Solaris, which leads me
> to think we should not update to 1.6 at this time. The problem seems
> to occur the first time an applet is executed in a Firefox session
> when there is a $HOME/.java directory which has been previously
> initialized by Java 6, where $HOME is in AFS. In this scenario,
> the Java VM (and thus Firefox itself) hangs for several minutes,
> until finally the applet is executed. From running truss on the
> process, it appears that a VM thread trying to initialize things
> from the .java directory, which tries to mkdir() all of the cache
> directories in $HOME/.java/deployment/cache/6.0 (which already
> exist), is getting preempted, and then doesn't resume for 3 seconds,
> after which each subsequent mkdir() is followed by another delay.
> I have not seen the problem with JDK 1.6 on Linux, or with using
> a local .java directory, or when the .java directory does not yet
> exist.
I believe the problem would always be exhibited the first time
an applet is executed in a Firefox session. I did not test whether
other Java apps were affected.
Hope this helps; please let me know if you want more information,
or if you learn more about the problem.
Bob
