On 11/03/2016 15:30, David M. Lloyd wrote:
What are the limiting factors? In my analysis the only problem that
seemed close to insurmountable was the special natives that are used
in the JDK but these only seem to be used from java.base. Does it all
boil down to getClassLoader()==null security checks on the Java side,
or is there a JVM component that I haven't discovered?
I have no doubt that it would be a big effort.
One of the most difficult issues when de-privileging is identifying the
minimum permissions. It gets complicated in areas with callbacks where
intermediate frames reduce the effective permissions. For several of
these modules then it may be that they end up needing AllPermission so
the benefits of moving them out are significantly reduced.
Related is performance when running with a security manager. A long
standing optimization is that code in the boot loader has AllPermission.
At things stand then we can't move any modules that export java.* APIs.
If getPlatformClassLoader() and the related spec change to allow java.*
classes be loaded by the platform class loader and its ancestors goes in
then it removes this hurdle.
I'm sure there will be lots of other issues once you get into it. Some
of the modules (like java.management) are tightly coupled to the VM. On
getClassLoader() returning null then such uses would need to be
examined. I don't expect there are too many as we replaced a lot of them
in the JDK 8 time frame as part of JEP 162.
-Alan
