Stephan Bergmann wrote:
Joerg Budischewski wrote:
[...]
The java uno bridge need to create also a fresh thread for each
release (or at least for each concurrent release). It can't be a
single thread doing the releases, because this would end in the same
problem.
A single additonal thread is enough to avoid the deadlock (thread A
needs more memory, and thus the finalizer thread, but the finalizer
thread waits for a mutex locked by thread A).
That's what I said :-).
On top of that, since the amount of memory available to a JVM is finite,
it is important to keep the number of reachable objects within a JVM
small at every point in time. Whether adding a single thread or
multiple threads in the given case helps achieve this goal better is not
a matter of correctness, but a matter of fine tuning.
Don't understand, what would be the difference between one or multiple
release threads?
IMO, the simplest approach should be tried first. Only if it is known
to behave badly (i.e., lead to OutOfMemoryError) often enough a more
complex approach should be tried.
Like always :-)
The simplest approach (call release synchronously from the finalizer
thread) is known to deadlock. It is arguable whether that deadlock is
due to an error in the bridge, or due to an error in the involved UNO
object implementations. However, if we agree on the former, the next
approach in terms of simplicity would be to have exactly one extra thread.
Anyway:
The problem basically is caused by current Java implementations only
supporting asynchronous finalization!
Solutions are:
-A- Implement synchronous finalization for Java => possible for some
kind of objects, unlikely to happen, reliability would rely on specific
behavior. => not viable
-B- Don't use the finalizer for releasing mapped objects. That would
mean, that one had to program release/acquire or dispose explicitly,
which would be quite error prone. => not viable
-C- Don't acquire any mutexes in (c++) d'tors on the office side.
Theoretically possible. In practice that would mean that for every kind
of object which is not only holding memory but other external resources
(device contexts, file handles, sockets, etc.), one would need to call
dispose. Hard to program and again error prone (at the end one would
have to offer/use dispose for all objects, because not wanting to
rely/show implementation details (e.g. holding a file handle may very
well be an implementation detail)) . => IMHO not viable again (I know,
others have other opinions ;-).
-D- Defer the problem, e.g. delegate the release calls out of the
finalizer thread into another thread. But, because of this other thread
waiting for the mutex, this eventually leads to the same problems we see
currently. => IMHO also not viable.
So, it seems no final solution at the horizon? I think we should
approach this differently. IMO, the main questions is, what is the
reason that some many objects become created while doing a long living
call into the office? Martin, could you give some hints?
Kay
It is IMHO not arguable, the problem is clearly office related! Otherwise
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
