<AWT Dev> [OpenJDK 2D-Dev] Review Request for 6879044
Andrei Dmitriev
Andrei.Dmitriev at Sun.COM
Fri Sep 25 04:26:14 PDT 2009
We've chatted with Igor and I see no concern. Ok from my side.
Thanks,
Andrei
Andrei V. Dmitriev wrote:
>
> Igor Nekrestyanov wrote:
>> Let me clarify this as it is does not directly translate into 3x
>> footprint.
>> But savings are not just "size of classes to be loaded".
>>
>> Common "core" classes are also included into shared archive
>> (classes.jsa) and removing logging classes
>> from the "core" will reduce size of classes.jsa (which is mmap-ed to
>> the memory on Windows).
>> Note that we may read same class from rt.jar too if it happens to be
>> in the same block as other class we need.
> Oh, I got it. In other words you are trying not to cache Loggers in
> classes.jsa and nothing else classes.jsa will be mmap-ed to the
> memory? That sounds promising.
>
>>
>> It will also reduce java quickstarter "read set" and this will make
>> jqs more user friendly (less load on the system,
>> smaller portion of disk cache taken for java stuff).
>>
>> None of these changes is "stunning" per se. But they sum up.
>> (This does not mean that Mandy's approach is the only way to go, if
>> someone can suggest how to improve logging package to
>> get same savings and preserve backward compatibility - this will be
>> even better.)
> We could make local to AWT changes with respect to loggers as
> described in 7).
> Thanks,
> Andrei
>
>> -igor
>>
>> On 9/22/09 11:00 AM, Igor Nekrestyanov wrote:
>>> 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 awt-dev
mailing list