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

Andrei Dmitriev Andrei.Dmitriev at Sun.COM
Fri Sep 25 11:26:14 UTC 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 2d-dev mailing list