<AWT Dev> [OpenJDK 2D-Dev] Review Request for 6879044

Mandy Chung Mandy.Chung at Sun.COM
Thu Sep 17 10:54:10 PDT 2009


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/



More information about the awt-dev mailing list