<AWT Dev> [OpenJDK 2D-Dev] Review Request for 6879044
Mandy.Chung at Sun.COM
Tue Sep 22 10:19:29 PDT 2009
(I took the core-libs-dev off as this is about awt/2d/swing discussion).
The main question is whether the client stack wants to require the
dependency on logging when the JDK is broken down into fine-grained
module. It is fine to wait until the jigsaw module system is ready to
provide the performance numbers for you to evaluate.
Some clarification inlined below.
Andrei Dmitriev wrote:
> Hi Mandy, Oleg,
> I'm going to summarize pros and cons of this change just to make judge
> (basically for myself).
> 1) we can't expect a significant memory gain (the numbers are ~90Kb).
> That's a minus.
I would not say it's a minus as it doesn't have negative impact.
> 2) we decouple awt/swing/2d with logging package which is a Plus in a
> view of jigsaw. See 6) for more.
> 3) we don't have time measures for this change. That's a minus.
This statement isn't true. This should be "no significant perf
improvement" for this fix and the perf improvment is not the goal for
I did run the refworkload startup benchmark. But the numbers confirm
that there is no significant improvement as expected.
Benchmark Samples Mean Stdev Geomean
startup3 30 2.33 0.05
Framer 30 0.30 0.01 0.03
JEdit 30 1.71 0.11 0.30
LimeWire 30 2.21 0.06 0.30
NetBeans 30 7.38 0.14 0.30
Noop 30 0.11 0.00 0.03
XFramer 30 0.30 0.00 0.04
Benchmark Samples Mean Stdev %Diff P
startup3 30 2.34 0.05 -0.22 0.684
Framer 30 0.30 0.00 0.33 0.326
JEdit 30 1.70 0.09 0.99 0.522
LimeWire 30 2.24 0.05 -1.56 0.025
NetBeans 30 7.37 0.06 0.08 0.833
Noop 30 0.11 0.02 -3.94 0.326
XFramer 30 0.30 0.00 0.22 0.310
* - Not Significant: A non-zero %Diff for the mean could be noise. If the
%Diff is 0, an actual difference may still exist. In either case,
samples would be needed to detect an actual difference in sample
> 4) nobody measured anything else than Framer and SwingSet. That's a minus.
As I said, the fix is to eliminate the dependency on logging. I'm not
sure what measurement you want to do.
> 5) we lose flexibility on debugging. That's a minus.
This statement isn't true. AWT debugging ability is unchanged.
> 6) this fix don't decouple anything else awt/swing/2d.
> I made a grep on "Logger.getLogger" and there are entries from xml, jmx,
> etc. That means we have to deal with them as well too (as it causes the
> class to be loaded anyway), if we aware of jigsaw.
> 7) In most cases AWT initiates classes statically but basically may want
> to do that lazily. That's minus. I'd consider initialization in CTOR at
> first and see the impact. Believe SwingSet would show enough here. If
> not, that's the reason to go further to... well to check if the Java
> property set.
> Now, I don't see the evaluation is completed to make the decision. And
> if we could modify client code in the way that Framer will never
> initialize or/and load Logger (et al) classes so we achieved the goal.
> Oleg Sukhodolsky wrote:
>> HI Mandy,
>> On Sat, Sep 19, 2009 at 12:19 AM, Mandy Chung <Mandy.Chung at sun.com>
>>> Hi Oleg,
>>> A better question to ask is who and how the logging information AWT
>>> is used
>>> for. The AWT team confirms that the AWT loggers are for debugging
>>> used by the awt developers. As specified in the Requirements chapter
>>> the Java Logging Spec (JSR-47) , the central goal of the logging
>>> API is
>>> to support maintaining and servicing software at customer sites.
>>> debugging code in the awt implementation using logging API is
>>> reasonable but
>>> it's not the requirement for the logging API. If there were a better
>>> to add debugging code, I believe you have no problem changing the awt
>>> debugging code not to use the logging API.
>>> Server-type applications are typical use cases that logging
>>> information is
>>> very important and useful for diagnosis in the field - long running
>>> hard to reproduce problems until running for many days/months. It is
>>> to imagine how the logging information is important in client
>> as ex-AWT developer I can confirm that there were number of cases when
>> logging had helped us to diagnose problem on client's site. Even
>> though you usually
>> do not need to run an application for a long time to reproduce a problem
>> it can be very hard to reproduce it because the problem depends on
>> window manager
>> and other environment which is hard to re-create.
>>> But you seem to know many client applications use the logging API
>>> that I
>>> would also be interested to follow up with their requirements.
>> I do not know many client applications which uses logging API (because
>> I have
>> never write real client application) and it is hard to say if it uses
>> logging or not.
>> I hoped that you who saying that suggested changes will help to client
>> has some statistic to confirm your expectation
>>>> Ok, so this fix is only about modules. But why AWT should not depend
>>>> on logging module?
>>>> The qiestion is: how many application we want to run doesn't use
>>>> logging& Because if an application
>>>> uses logging there is no reasons for AWT to not use it. Please note
>>>> that even if logging is turned
>>>> off, the application still needs logging package/module. So, though
>>>> end-user doesn't need logging output
>>>> she may need logging module to run the application.
>>> This is exactly why we want to decouple the dependency on logging.
>>> When an
>>> application uses logging, the application knows clearly what module they
>>> require and that's fine. When an application doesn't logging, if the
>>> component requires logging for debugging purpose only, it increases the
>>> download size, footprint and startup performance (class lookup time,
>>> loading, init, etc) - please see my performance analysis report;
>>> it's not fruitful to discuss the details in this thread without the
>>> background info. Just to mention it what we care about.
>> I have found only two links to some performance analysis:
>> but they say about -Xverify and -Xshare and do not understand how they
>> can be related
>> to our topic :( If they do, please explain (I have never been an
>> expert in this area :(
>> Or, if I missed something could you please point me what I have missed.
>>>> So, it is really
>>>> important to understand
>>>> what number of application will get advantage of suggested changes.
>>> You are suggesting the client applications always have a dependency on
>>> logging. Many client team engineers are happy to see the dependency on
>>> logging being eliminated from the client stack requirement and
>>> approve this
>>> fix :)
>> I do not see how this can be considered as prove that the changes will
>> help client applications.
>> Unless we have some statistic it is all just our guess (which, as we
>> know, usually wrong ;)
>>>> Second question is: how big logging module is going to be? How big the
>>>> benefit for end-user will be?
>>> The size of the logging API is not big (~90K) but the size is not the
>>> one factor determining what benefit the end-user will have.
>> what other factors do you know?
>>> It's not
>>> necessary to logging API as one single module and details are to be
>>> out. Subscribe to the jigsaw project to follow the discussion and
>>> there. Serviceability includes other API as well. If awt started
>>> other serviceability API (java.lang.management, java.lang.instrument)
>>> whatever reason, your argument would apply there as well. I don't
>>> think you
>>> wanted the awt module depends on all the serviceability APIs.
>> I agree that usage of any API should be done after careful consideration.
>> Logging API provides us exactly what we need (ability to create log of
>> an application
>> executed on client) this is why we started to use it.
>>>> I'm asking so many question mainly because the changes you suggested
>>>> create rather unnatural code (we can not
>>>> use standard logging machinery any more), so such changes should be
>>> That's what we pay for to modularize the JDK after many years of JDK
>>> development without module support in the platform. Otherwise, if there
>>> were module support in the platform, you would consider very
>>> carefully when
>>> adding a dependency on another module.
>> perhaps you are right, but in case of logging I would expect that we'd
>> use it
>>> If you have further issue, I suggest to start a different thread on the
>>> awt-dev alias.
>>>  http://jcp.org/aboutJava/communityprocess/first/jsr047/index.html
More information about the awt-dev