The problem is that is a choice between two evils: continuing with stale
objects or stopping the abuse immediately. The read barrier is a performance
issue I agree with. However, this is not a black and white situation, it is
about recovering from an erroneous state asap. So not synchronizing the read
(accepting some stale data) is already a great improvement in finding the
culprits.
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 ... :-)
Just for debugging this kind of behavior would already be great ...
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
