[OpenJDK 2D-Dev] <AWT Dev> Review Request for 6879044
Igor Nekrestyanov
Igor.Nekrestyanov at Sun.COM
Tue Sep 22 18:00:57 UTC 2009
BTW, note that reducing set of required core classes will save 3x of
memory at least (think of jqs and classes.jsa in addition to rt.jar (on
windows)).
-igor
On 9/22/09 10:19 AM, Mandy Chung wrote:
> (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
> this fix.
>
> I did run the refworkload startup benchmark. But the numbers confirm
> that there is no significant improvement as expected.
>
> ==============================================================================
>
> mchung.baseline.b70:
> Benchmark Samples Mean Stdev
> Geomean Weight
> 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
> ==============================================================================
>
> mchung.platform.logging:
> Benchmark Samples Mean Stdev %Diff P
> Significant
> 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, more
> samples would be needed to detect an actual difference in sample
> means.
>
>> 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.
>
> Mandy
>
>> 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.
>>
>> Thanks,
>> Andrei
>>
>> Oleg Sukhodolsky wrote:
>>> HI Mandy,
>>>
>>> On Sat, Sep 19, 2009 at 12:19 AM, Mandy Chung <Mandy.Chung at sun.com>
>>> wrote:
>>>
>>>> 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
>>>> purpose
>>>> used by the awt developers. As specified in the Requirements
>>>> chapter for
>>>> the Java Logging Spec (JSR-47) [1], the central goal of the logging
>>>> API is
>>>> to support maintaining and servicing software at customer sites.
>>>> Adding
>>>> 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 option
>>>> 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
>>>> apps,
>>>> hard to reproduce problems until running for many days/months. It
>>>> is hard
>>>> to imagine how the logging information is important in client
>>>> applications.
>>>
>>> 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
>>> application
>>> 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 awt
>>>> 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;
>>>> otherwise,
>>>> 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:
>>>
>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2009-July/000181.html
>>> http://cr.openjdk.java.net/~mchung/startup_measurement/perfdata.summary.b64
>>>
>>>
>>> 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 only
>>>> 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
>>>> worked
>>>> out. Subscribe to the jigsaw project to follow the discussion and
>>>> progress
>>>> there. Serviceability includes other API as well. If awt started
>>>> using
>>>> other serviceability API (java.lang.management,
>>>> java.lang.instrument) for
>>>> 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
>>>>> well-justified.
>>>>>
>>>>>
>>>> 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
>>> anyway.
>>>
>>> Oleg.
>>>
>>>
>>>> If you have further issue, I suggest to start a different thread on
>>>> the
>>>> awt-dev alias.
>>>>
>>>> Thanks
>>>> Mandy
>>>> [1] http://jcp.org/aboutJava/communityprocess/first/jsr047/index.html
>>>>
>>
More information about the 2d-dev
mailing list