[OpenJDK 2D-Dev] <AWT Dev> Review Request for 6879044
son.two at gmail.com
Tue Sep 15 03:04:10 UTC 2009
On Mon, Sep 14, 2009 at 9:19 PM, Mandy Chung <Mandy.Chung at sun.com> wrote:
> Oleg Sukhodolsky wrote:
>> On Mon, Sep 14, 2009 at 5:32 AM, Mandy Chung <Mandy.Chung at sun.com> wrote:
>>> 6879044: Eliminate the dependency of logging from the JRE core/awt/swing
>>> 1. A new sun.util.logging.PlatformLogger class that will handle the log
>>> messages in a similar way as Logger but it will only delegate to
>>> java.util.logging only when it is enabled. LogManager and LogRecord are
>>> modified to support the platform loggers. The users of PlatformLogger
>>> continue to run if java.util.logging classes do not exist.
>> evaluation for 6879044 says:
>> Add a PlatformLogger class that mimics the default logging behavior
>> (output the log message to System.err with simple formatting) and
>> creates a java.util.logging.Logger only when the logging facility is
>> used by the application or a user-defined configuration is supplied.
>> which of two descriptions is correct one?
> Both are correct. Can you elaborate what issue;/confusion you see between
> the descriptions?
I thought that it is possible to log int a file using default logger,
thus I was surprised that
description of PlatformLogger says about System.err. I'd expect
PlatformLogger to be a wrapper around the default logger,
and as far as I can see from provided sources it is.
> The class description of sun.util.logging.PlatformLogger has the details:
>> Also I wonder if it is ok to get possible better modularization by
>> adding dependency to Sun's internal API into public packages.
> This fix is to eliminate the dependency to logging API. This internal
> PlatformLogger class is an implementation class only used by the JRE and
> always be present. Does this answer your question?
internal PlatformLogger is present in Sun's implementation of JRE
only, so such changes will
complicate porting JRE implementation. Also I wonder how big logging
module is, what advantage we do receive
by removing dependency on it? How many Mb we do not need to load in this case?
>>> 2. AWT, 2D, Swing, and a few java.util classes are modified to use
>>> PlatformLogger instead of Logger. Although many files are modified, the
>>> change is mostly replacement with classname.
>> Well, at least in AWTEvent you have changed static initialization of
>> logger to lazy one.
>> Perhaps it is better to keep a static one to minimize your changes.
> This fix shows one way of lazy initializing an AWT logger to be referenced
> when fixing 6880089. The AWTEvent log messages are only output in the error
> conditions. In the normal cases, no message will be logged in this logger
> is not needed. I would expect that the fix for 6880089 may make some AWT
> loggers to be initialized lazily as this one.
I'd suggest to keep all logger's initialization as is to simplify the fix.
> Thanks for the review.
>>> AWT statically creates a number of loggers. Running a simple AWT Framer
>>> application with JDK 7 b71 creates 79 loggers on solaris-i586 and 34
>>> on windows-i586. SwingSet2 creates a total of 85 loggers including a few
>>> non-awt ones on solaris-i586 and 35 on windows-i586).
>>> Although the memory usage might not be very high (especially with this
>>> I don't see the need of having many fine-grained loggers. This fix
>>> address this the number of AWT loggers. I file a separate CR (6880089) to
>>> revisit it.
>>> Startup Performance:
>>> This change does not have significant startup performance improvement, as
>>> expected. However, it does reduce the number of loaded classes (Framer
>>> loads 16 fewer classes and jedit loads 13 fewer classes).
More information about the 2d-dev