Changeset: 4afe1281c837
Author:jbachorik
Date: 2013-11-28 09:10 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4afe1281c837
6987597: ManagementFactory.getGarbageCollectorMXBeans() returns empty list with
CMS
Reviewed-by: mchung
!
What incantation is required to get Sherman to offer his perspective? :-)
I accept that it may be after Thanksgiving, but I need to know the
situation since we have tests for JRuby that depended on this
character being valid Shift-JIS.
- Charlie
On Mon, Nov 25, 2013 at 4:08 AM, Seán Coffey
On 11/28/2013 08:53 AM, Shi Jun Zhang wrote:
The problem is that we use a logger in CustomerFormatter and this
causes Logger.log call Logger.log itself. As FileHandler.publish and
StreamHandler.publish is synchronized, but the iteration to call
publish method for all handlers in Logger.log is
On 11/27/13 10:34 PM, Peter Levart wrote:
Hi Daniel,
I have started looking at the LogManager change first, and here's the
1st race I found...
Hi Peter,
Thanks a lot for your feedback! see below...
The new method LoggerWeakRef.dispose() can be called from 3 places:
-
Hi Shi Jun Zhang,
I agree with Peter.
It is strange that CustomFormatter calls Logger.log. This looks like
the source of the deadlock.
The Logger API can be customized in many ways - and when you can
plugin custom classes and objects you can introduce new opportunity
for deadlocks.
Concerning
On 27/11/2013 08:33, Thomas Stüfe wrote:
I can see arguments for both sides (linking statically vs using the
system zlib) and I'm leaning toward the former. Errors or
incompatibilities in the zlib could be really harmful, and I rather
use the zlib I ran all my tests with instead of the
Hi,
i finally found some time to have a look at this.
I think it is a problem in MethodHandleNatives.resolve which is called
from MemberName.resolve to figure out
which MemberName is the one that should be resolved.
The wrong behavior of jdk1.7.0_17 was very usefull to find this, because
it has
On 11/28/2013 8:13 PM, Peter Levart wrote:
On 11/28/2013 08:53 AM, Shi Jun Zhang wrote:
The problem is that we use a logger in CustomerFormatter and this
causes Logger.log call Logger.log itself. As FileHandler.publish and
StreamHandler.publish is synchronized, but the iteration to call
So, if I were to recode this fix again to not change the zlib - which is
not so trivial - do you think there is a chance that this fix gets examined
and maybe pulled into the OpenJDK?
I don't see any reason why not. So I would suggest go ahead and see if
this can be fixed without changing
On 11/29/2013 1:21 AM, Daniel Fuchs wrote:
Hi Shi Jun Zhang,
I agree with Peter.
It is strange that CustomFormatter calls Logger.log. This looks like
the source of the deadlock.
Hi Daniel,
I explained why we call Logger.log in CustomerFormatter in another mail
replied to Peter,
10 matches
Mail list logo
