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
