I'll give you exposure on my blog if you make this work for me :-)
Kind regards,
Peter Kriens
On 24 feb 2011, at 00:18, chris.g...@k-embedded-java.com wrote:
> 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, chris.g...@k-embedded-java.com 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, chris.g...@k-embedded-java.com 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
>>>>> osgi-dev@mail.osgi.org
>>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> osgi-dev@mail.osgi.org
>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
