A compromise approach on module isolation
Alan.Bateman at oracle.com
Tue May 16 07:32:55 UTC 2017
On 12/05/2017 21:38, Tony Printezis wrote:
> David, Remi, and all,
> I have a few questions (and a concern),
> - This seems like a straightforward change and I’m sure it must have been
> proposed in the past. And I guess it was rejected for specific reasons.
> What are the gotchas of this approach? I.e. Will it break some code? Will
> it require some code to be changed? And will it bake-in some behavior that
> we might not want in the long term?
> - (With my JVM/GC implementer hat on) I really don’t think launching a
> class loader per module is a great idea. There are overheads in the JVM for
> each class loader you introduce (performance - the GC has to do some extra
> work per class loader, footprint - there are data structures maintained per
> class loader and space could be wasted due to fragmentation in the meta
> space of each class loader). FWIW, at Twitter, most of our services do not
> use custom class loaders and we get a lot of benefit out of that. It’d be a
> step backwards for us if somehow our JVMs got bloated with potentially
> 1,000s of class loaders.
> - Using class loaders is one way to isolate modules. Has anyone considered
> alternatives? For example, doing automatic shading of non-exported packages
> in the JVM (lots of hand-waving here)?
FWIW, we've been encouraging the use of shading on jigsaw-dev for a long
time. When it works then it eliminates a lot of the potential for issues
that otherwise arise when someone takes a copy of a library to include
in their own library.
In any case, and at a high-level, then this topic of isolation or
interference can be viewed as a failure of class loaders. Going there
would be a huge undertaking, esp. when you start to think about
identity. At least in Project Jigsaw, we chose not to go there.
Using class loaders for isolation is of course possible and has always
been possible via the API (there is even a convenience method in
ModuleLayer to do just that). The discussion here is therefore around
the application module path that you specify to the `java` launcher or
to the JNI invocation API. So it's mostly a JDK issue rather than a JSR
376 issue. Alternatives to the current simple implementation have of
course been explored -- this includes spilling when there are
conflicting packages or just assigning the explicit modules on the
module path to their own class loader. As expected, it brings many
issues to the surface, particularly around the interoperability the
class path, upgraded modules, qualified exports, and issues with legacy
APIs (esp. resources) that arise with changes to visibility. These all
seem like issues to look at in the future and what we have in JDK 9
today doesn't preclude this.
More information about the jpms-spec-observers