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...
Understood. > 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
pgpxgoWK2qEHI.pgp
Description: OpenPGP digital signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
