Peter, > I guess it is all about what you find more important: running bad code on > a politically correct VM, or killing that bad code asap on a > not-so-politically correct VM ... :-)
I don't think it is just a matter of "political" correctness, by invalidating references we could cause correctly written code to behave incorrectly or cause a JIT compiler to emit incorrect code. In a production system that could be a nightmare, but ... > Just for debugging this kind of behavior would already be great ... That's an excellent point - if this behaviour could be enabled or disabled by a command-line switch then one could e.g. enable it in CI and disable it in production. Back in the Acunia days we built a similar flag into Wonka to provide early detection of certain design faults. OK, you've convinced me. Now I just have to find the time to build this feature into Mika. :-) Br Chris > Kind regards, > > Peter Kriens > > > > > > > On 21 feb 2011, at 22:29, [email protected] wrote: > >> Peter> >>> A very cheap way to do what I want is to let the VM just throw some >>> runtime exception on any object that is from a stale class loader. >> >> You make it all sound so easy. :-) >> If you mean "throw some runtime exception on any *access to* object that >> is from a stale class loader" then you are asking for some kind of read >> barrier which is going to penalise all accesses, or else you have to >> screw >> with the *references to* those objects in such a way as to cause an >> runtime exception. For example you could simply set them to null, or to >> some out-of-range value which would be caught by a hardware trap. (The >> latter is expensive when it happens, but actual violations should be >> rather rare.) >> >>> I think the java semantics is a red-herring, OSGi is a framework >>> running >>> on Java, we can add our own semantics when you run as a bundle. The >>> choice >>> is between two evils: or you have people using stale objects, which >>> they >>> were notified about or the bad guys get an exception ... And any code >>> can >>> get an exception at any time, that is part of the Java semantics. >> >> "Any code can get an exception at any time" is true at the source code >> level, but at the execution level it doesn't hold any more (which is a >> Good Thing). For example the execution engine may legitimately conclude >> that if a reference was valid at instruction p then it will remain valid >> at instruction p+1, etc. until q where another code path joins this one, >> so >> it doesn't need to perform any more checks. Then you come along and >> invalidate that reference, the execution engine uses it to calculate a >> path to something else and hey-ho, la-la-land. I'm thinking >> particularly >> of local variables here, not just fields. >> >>> It is all about putting the burden on the culprit and in this case the >>> culprit is the user of the stale object. >> >> The culprit gets the exception but the overhead is also borne by others. >> And these now-invalid references may already have been passed to other >> components which might be completely unaware that they were loaded by a >> "stale" bundle class loader, yet they get punished too. >> >> Best regards >> >> Chris >> >>> On 20 feb 2011, at 09:34, [email protected] wrote: >>> >>>> >>>> NJB> Given that there is no way to take an object away from someone >>>> who >>>> has a >>>>> reference to the object, the service contract should state the >>>>> behavior >>>>> of >>>>> the object outside of its defined life time. >>>> >>>> I remember a conversation with Peter a few years ago where Peter was >>>> wondering whether it would be possible to tell a Java runtime to >>>> forcibly >>>> clean up a class loader, which would imply nulling out all references >>>> to >>>> instances of classes which it had loaded. I think that at the time I >>>> said >>>> it was simply impossible; nowadays I would say it is technically >>>> possible >>>> but violates Java semantics in a way which is probably unacceptable >>>> (and >>>> the runtime overhead could be significant). >>>> >>>> A service could send a very strong signal to its users by only >>>> returning >>>> WeakReference's to the objects it creates instead of direct references >>>> to >>>> the object itself. Of course the service user can sabotage this by >>>> cacheing a strong reference to the object. >>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> [email protected] >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
