P2
From: ###@###.###
I am looking at a different scenario:
A threadGroup is created and made daemon using setDaemon()
and created few threads without starting them.
And at a later time threads were started ...But due to it beeing a
daemon threadgroup..it could have been destroyed automatically (as no
threads are associated with this threadgroup )by the time we tried to
add threads.
Date: Wed, 05 Nov 2003 22:42:15 -0800
> From: ###@###.###
> The spec of list() just states "information about the thread group
> is printed to stdout". So there is nothing in the spec that
> specifies a specific format (or associated semantics) of the
> output. That said the incompatibility might hurt someone
> who has come to depend on the format (and the expectation
> as in the email below that the unstarted threads be present
> in the listing.
Agreed.
> The spec of enumerate()/activeCount() explicitly states that it
> enumerates / counts only "active threads". That has not changed
> due to madbot's putback. Moreover there is no API through which
> anyone may access unstarted threads "in a thread group" (if you will)
> programattically or do anything with those threads. Thus, the
> change does not affect that (in)ability either in any way.
Good, I hadn't realized this.
> That leaves Madhava's concern about daemon groups, which I
> think is a legitimate one, since it illustrates a source of
> genuine incompatibility in behaviour wrt older JDK's. One can
> easily conceive of applications failing because of the change
> in behaviour. On the other hand, not being familiar with any
> actual Java code, I do not know how often people actually write
> code that would expose this incompatibility. (What do you T&L
> folks think? What does Doug Lea think? What would a quick
> survey of the J2EE/S1AS/Portal Server and other such groups
> yield?).
I suspect this is fairly rare, but that's only a hunch -- for all I know one of
our big apps could depend on this (I've seen stranger things).
We don't have time to re-engineer this today, so we need to make a choice in
order to finish up this integration:
(1) We document this bug (4949677) as a "minor failure", or
(2) We undo this change (yet again, sigh).
What do you think?
> One alternative is to use weak references from ThreadGroups to their
> Threads, but that would mean more change in the libraries to
> deal with the extra indirection through the weak reference
> as well as scrubbing stale weak references. It would also add
> a little bit to heap footprint (but probably not enough to lose
> sleep over, even for thread-intensive applications such as Volano).
Yes, weak references would do the trick. The weak ref would actually only be
needed until the thread is started, at which time it could replaced with a
strong reference. This would, in most cases, make the weak ref relatively
short-lived and thereby reduce the performance impact.
From: ###@###.###
(1) I've never heard of anyone using a daemon ThreadGroup. To be honest, I'd forgotten that such a thing existed. Unfortunately it does. ThreadGroup is a total piece of crap.
(2) Based on a quick read of the code, I don't think the weak refs that you describe would have any effect on the situation. The "destruction" of a thread group is triggered by the ThreadGroup.remove(thread) method, which is called by the thread when it exits. This call decrements a "ref count" field called ThreadGroup.nthreads (which is also used to compute the return value for activeCount()). I suspect that we could increment nthreads when a thread is created (rather than when it is started) to prevent the daemon thread group from being destroyed. (We may already be doing this.) Given that activeGroupCount is specified to return *an estimate* of the the number of active threads in this thread group, and active is never defined anywhere, I think this would be fine. Alternatively we could keep two separate counts: the number of active threads in this thread group and the number of unstarted threads in this thread group. This would allow us to precisely emulate the current behavior. I'm not sure it's worth it.
I am looking at a different scenario:
A threadGroup is created and made daemon using setDaemon()
and created few threads without starting them.
And at a later time threads were started ...But due to it beeing a
daemon threadgroup..it could have been destroyed automatically (as no
threads are associated with this threadgroup )by the time we tried to
add threads.
Date: Wed, 05 Nov 2003 22:42:15 -0800
> From: ###@###.###
> The spec of list() just states "information about the thread group
> is printed to stdout". So there is nothing in the spec that
> specifies a specific format (or associated semantics) of the
> output. That said the incompatibility might hurt someone
> who has come to depend on the format (and the expectation
> as in the email below that the unstarted threads be present
> in the listing.
Agreed.
> The spec of enumerate()/activeCount() explicitly states that it
> enumerates / counts only "active threads". That has not changed
> due to madbot's putback. Moreover there is no API through which
> anyone may access unstarted threads "in a thread group" (if you will)
> programattically or do anything with those threads. Thus, the
> change does not affect that (in)ability either in any way.
Good, I hadn't realized this.
> That leaves Madhava's concern about daemon groups, which I
> think is a legitimate one, since it illustrates a source of
> genuine incompatibility in behaviour wrt older JDK's. One can
> easily conceive of applications failing because of the change
> in behaviour. On the other hand, not being familiar with any
> actual Java code, I do not know how often people actually write
> code that would expose this incompatibility. (What do you T&L
> folks think? What does Doug Lea think? What would a quick
> survey of the J2EE/S1AS/Portal Server and other such groups
> yield?).
I suspect this is fairly rare, but that's only a hunch -- for all I know one of
our big apps could depend on this (I've seen stranger things).
We don't have time to re-engineer this today, so we need to make a choice in
order to finish up this integration:
(1) We document this bug (4949677) as a "minor failure", or
(2) We undo this change (yet again, sigh).
What do you think?
> One alternative is to use weak references from ThreadGroups to their
> Threads, but that would mean more change in the libraries to
> deal with the extra indirection through the weak reference
> as well as scrubbing stale weak references. It would also add
> a little bit to heap footprint (but probably not enough to lose
> sleep over, even for thread-intensive applications such as Volano).
Yes, weak references would do the trick. The weak ref would actually only be
needed until the thread is started, at which time it could replaced with a
strong reference. This would, in most cases, make the weak ref relatively
short-lived and thereby reduce the performance impact.
From: ###@###.###
(1) I've never heard of anyone using a daemon ThreadGroup. To be honest, I'd forgotten that such a thing existed. Unfortunately it does. ThreadGroup is a total piece of crap.
(2) Based on a quick read of the code, I don't think the weak refs that you describe would have any effect on the situation. The "destruction" of a thread group is triggered by the ThreadGroup.remove(thread) method, which is called by the thread when it exits. This call decrements a "ref count" field called ThreadGroup.nthreads (which is also used to compute the return value for activeCount()). I suspect that we could increment nthreads when a thread is created (rather than when it is started) to prevent the daemon thread group from being destroyed. (We may already be doing this.) Given that activeGroupCount is specified to return *an estimate* of the the number of active threads in this thread group, and active is never defined anywhere, I think this would be fine. Alternatively we could keep two separate counts: the number of active threads in this thread group and the number of unstarted threads in this thread group. This would allow us to precisely emulate the current behavior. I'm not sure it's worth it.
- duplicates
-
JDK-4950229 ThreadGroup().list() output
-
- Closed
-