Oleg, Anthony,
You all raise good questions and we shall focus on the problem we want
to fix by 6879044 and 6882376. It's important to separate the
discussion for this fix vs the startup performance improvement. I hope
below clears up some confusion and this review request is for addressing
problem described in (1).
(1) The problem is to decouple the dependency on logging from some JRE
components.
FYI. The jigsaw project page [1] provides links to the good background
why we're doing that. Mark gave a very good overview and demo of
Project jigsaw at JavaOne General Technical Session[2].
Logging is one candidate module if the libraries are broken up into a
set of fine grained modules. The fix for 6882376 provides the internal
support for JRE implementation to eliminate their dependency on logging.
Alan and Naoto reviewed the fix.
As for the AWT/2D/Swing changes,
6879044: Eliminate the dependency on logging from the AWT/2D/Swing
classes,
When the libraries are broken into modules, are you saying that the
client module should require the logging module to exist? On the other
hand, as Alan explained, why would a user need to have a logging module
installed to run a simple client application?
Artem and Dmitri reviewed the fix. If you have another proposal of
decoupling the dependency, I would be interested too.
(2) Startup performance improvement
The suggested change does not have a signifcant startup performance as
expected (as I mentioned in the bug report). It does load fewer classes
(~16 classes) which isn't bad. My apology if I confuse you when we
mixed it in this review request.
I have done some performance analysis [3] [4] to determine what
opportunity the jigsaw module system could implement and the estimate of
the startup time improvement we could possibly get. Decoupling
dependency is an important step to modularize the JDK while the startup
gain may not be materialized until the module system is in place.
(3) AWT loggers
The AWT loggers are for debugging purpose. I understand the advantage
of fine-grained loggers to have a fine-grained control of the debugging
output. It's a tradeoff between performance (time and memory) and such
debugging ability. I would argue that this fine-grained debugging
ability is nice to have but isn't necessary to be available in the
production environment. You should consider some way to enable such
debuggability but disabled by default to minimize the performance
overhead such as lazily creating these logger. sun.font only enables
logging when -Dsun.java2d.debugfonts=true system property is set to
true. This should be revisited - see 6880089 [5].
(4) Performance and design of java.util.logging
I totally agree with that the performance and design of j.u.logging
should be improved. If you have any idea and solution, your
contribution would be appreciated. In fact, I would hope that we could
have something like DTrace [6] that tracing code can be added in the
implementation but no overhead is paid if the probes are not enabled [7].
Thanks
Mandy
[1] http://openjdk.java.net/projects/jigsaw/
[2]
http://java.sun.com/javaone/2009/playlist.jsp?pid=24494811001&autoStart=on
[3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2009-July/000181.html
[4]
http://cr.openjdk.java.net/~mchung/startup_measurement/perfdata.summary.b64
[5] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6880089
[6] http://www.sun.com/bigadmin/content/dtrace/index.jsp
[7] https://btrace.dev.java.net/
