On 2018-04-13T14:59:49 +0100
Neil Bartlett <njbartl...@gmail.com> wrote:
> It's definitely possible that we're talking about different things, but let
> me explain myself a little more...


> Yes I agree that's an additional benefit, but I'm not clear on what those
> optimizations might be.

Nonexistent, currently. I believe some of the suggestions have been
around a more advanced form of escape analysis; supposedly you can
track escaping values over a set of classes rather than over a single
method. The reason you can't do this without module boundaries is
because there's otherwise not a clear point where you can *stop*
analyzing. I've seen rather a lot related to AOTC, but that's not
relevant for OSGi.

> That's an interesting use case, but surely it would only be useful where an
> enum is private to a module? If it's exported then you cannot check switch
> statements in modules that haven't been written yet. And if it's private to
> the module/bundle then we can check all switch statements using existing
> tools.

The discussion in question was about switch statements in the presence
of binary incompatible changes. As in, you knew all of the enum
constants when you compiled the code, but someone added a new one
later and your switch wasn't recompiled. The gist of the discussion was
that you could be more strict if the switch statement was in the same
module as the enum type, because you'd expect the entire module to be
recompiled and therefore the statement couldn't get out-of-sync with
the type declaration. Clearly you could violate this assumption, but
the discussion was about which assumptions would be acceptable for the
compiler to try to enforce (with the understanding that if you violated
them, you're on your own).

> However I think that compile-time optimizations that depend on module
> boundaries are a long way in the future, if they ever come. As long as the
> module system is optional, you will be able to take a module and put it on
> the classpath, invalidating all the assumptions the compiler made about
> accessibility.

I think the optimizations are intended to be just-in-time, driven by
the metadata exposed in the modules. If you put the module on the
classpath, you don't get the optimization (because the assumptions
would be invalidated, as you said).

> I think that JPMS *could* be implemented on top of this as a fundamental
> primitive, but it's very unlikely to happen.
> These are obviously details that require careful consideration. My initial
> thoughts are that the callback could be implemented as a service that is
> configured once in the JVM, probably via a command line switch. In order to
> support things like multiple OSGi frameworks, you could have a composite
> implementation that delegates to child or sibling frameworks.
> At this point I'm happy to wave my hands and say "a solution exists"
> without spending too much time working out that solution. Given the
> improbability of this going anywhere, any such effort feels like it would
> be wasted.

I agree that anything involving reimplementing the JPMS is not going to
happen. That's not the same as saying that we couldn't find a small set
of primitives that could be added to the JPMS (possibly in addition to
rules that could be relaxed, like the recent "run-time graph may be
cyclic" change) that could support the things we're talking about. The
point of me starting this discussion was so that I could get some idea
of what these primitives might be. I was hoping to hear a bit from
Thomas Watson who implemented the osgi-jpms-layer and so might have
some idea as to where the main friction points are.

I could envisage something along the lines of an "opaque" module layer
with a single exposed module. The VM is not permitted to resolve
classes/packages to modules within the layer on behalf of any
modules outside of that layer. Modules inside the layer may add "reads"
edges to modules outside the layer, but this is actually implemented by
the single exposed module re-exporting those packages to modules inside
the layer. Theoretically, the rules such as "no two modules may export
the same package" could then be relaxed inside the layer and wouldn't
require relaxing that rule in general for the entire module system. I
appreciate there may be issues with this I've not considered, but I'm
trying to demonstrate that perhaps redesigning the whole system might
not be necessary.

I appreciate that you were personally involved with the expert group,
and that you may be somewhat burned out on the issue given that the
final result wasn't satisfactory, but I think that saying "it's not
going to happen so let's not bother" is a self-fulfulling prophecy.

Mark Raynsford | http://www.io7m.com

Attachment: pgpxgoWK2qEHI.pgp
Description: OpenPGP digital signature

OSGi Developer Mail List

Reply via email to