<AWT Dev> [OpenJDK 2D-Dev] Review Request for 6879044
Andrei V. Dmitriev
Andrei.Dmitriev at Sun.COM
Tue Sep 22 13:22:04 PDT 2009
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