Name: gm110360 Date: 09/16/2002


FULL PRODUCT VERSION :
java version "1.4.1-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-rc-b19)
Java HotSpot(TM) Client VM (build 1.4.1-rc-b19, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :

Installing a SecurityManager destroys performance of java
because of one permission class in particular. Creating a
FilePermission has too much overhead associated with it as
it is used in the Java libraries. Lots of place in Sun's
Java library the FilePermission is used like so:

SecurityManager manager = System.getSecurityManager();
if( manager != null ) {
   manager.checkPermission( new FilePermission(...) );
}

The construction of the FilePermission is its highest
cost. The performance of the actual check itself does not
seem to be the worst part.

Furthermore, classes like java.io.File will check
FilePermission several times on the same file, and it is
not obvious to the programmer that the check will be
performed. Usages of methods like File.isFile(),
File.isDirectory(), File.canRead(), File.canWrite(), and
File.exists() all check that permission in the same manner
as discussed above. Quite often these checks are performed
multiple times on the same file.

I tried to supply a simple example of this, but
unfortunately, it did not highlight the terrible
performance of this class as best as real world examples
do. It seems this has been the problem from the beginning
of Java, and so many of Java's technologies rest on
installing a SecurityManager like RMI, JAAS, Jini, and
Applets. It seems this would be a quite serious block to
accepting these technologies. This could be why Java
earned it's poor performance label because so many
developers tried using applets. I have three stories to
provide ancidotal evidence of this problem. (I will try to
gather more metrics on these three stories and attach them
here).

I encountered this first while writing a program that used
Jini. Jini requires that you install a SecurityManager. I
was working on optimizing some code that formated a web
page with the contents of a directory. It was taking
serveral seconds just to format and display the page. I
profiled it, and bingo the hostspot was newing the
FilePerimission class. I removed the SecurityManager, and
not only did my webpage display faster than I excepted,
several areas of my application sprung to life with
lightening fast execution. I was so pleased, but I
ultimately, had to remove the use of Jini because of this
bottleneck.

A group of programmers at work were writing a Java
replacement to an older editor that our company was
revamping. It was originally Win32 C++. Naturally,
performance was a big area of debate, and the C++ team was
comparing the Java application's startup performance with
its own. The startup time of the Java app was very very
slow (>8s), and the Java programmers were forced optimize
the performance. They had a SecurityManager installed
because there was the possibility of loading code remotely,
and they wanted to check and make sure their code was
signed properly with the proper certificate. The single
biggest boost in performance, over a 1/3 of startup time,
was achieved by removing the SecurityManager. Startup time
of client side apps is mainly wrapped up in reading the
classes from the disk. SecurityManager was adding serious
overhead to this.

Finally, at work we are developing a server application
where we use RMI and JAAS. We have to install a
SecurityManager in order to take advantage of JAAS. I
decided to further prove my point by profiling it in
OptimizeIt. The number one hotspot, more than socket IO!,
is the newing of the FilePermission. Further it looks like
the permission is even newed up when you open a socket for
god's sake! In addition we used to use a SecurityManager
for our client side, customers were quite unhappy with the
performance of the application. We removed the
SecurityManager in an effort to rid ourselves of policy
file management, and fragile setups, and it was a
significant boost many of our QA engineers commented on
that. I can't say the same for our app server.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Pick a java program.
2. Add -Djava.security.manager to the command line startup
3. Watch all your hard work really suck.

EXPECTED VERSUS ACTUAL BEHAVIOR :
This must perform!!! The whole cool thing of java was the
fact that it could control security. No buffer overflows,
no malicious code being sent through webpages, email, or
over the net to a naive users. Fix this or else it's more
FUD for M$.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER WORKAROUND :
Don't use SecurityManager's if you can help it.
(Review ID: 164493)
======================================================================