<AWT Dev> debugging a regression

[Semyon Sadetsky]

Hi Yuri,

If you remember we had a quick discussion about this issue before the 
PIT. Fix was ready but did not go into the PIT.

--Semyon

On 7/1/2015 6:53 PM, Yuri Nesterenko wrote:
> Well, yes, I'm afraid so. On Nimbus, however, I don't see
> any degradation, and it seems that after switching from Nimbus
> to Metal or GTK SwingSet2 is more responsive.
> But the fix is not in this PIT, is it?
>
> -yan
>
> On 07/01/2015 06:27 PM, Phil Race wrote:
>> BTW I meant to send email on this but yesterday whilst doing
>> manual testing of the final PIT builds on 64 bit Linux I still saw one
>> CPU core
>> max out on the HTMLEditor test in SwingSet2.
>> I think it was GTK L&F but I do not remember for sure ..
>> I suspect it is actually all of them.
>>
>> I did not see the same on OS X (for example).
>>
>> Yuri ??
>>
>> -phil.
>>
>> On 7/1/15 7:17 AM, Pete Brunet wrote:
>>> That fixed it.  Thanks Semyon.
>>>
>>> On 7/1/15 8:25 AM, Pete Brunet wrote:
>>>> Thanks Semyon!  I'll give it a try. -Pete
>>>>
>>>> On 7/1/15 2:29 AM, Semyon Sadetsky wrote:
>>>>> Hi Pete,
>>>>>
>>>>> I heard that you got performance issue in b68 connected to text
>>>>> components.
>>>>> It can be caused by https://bugs.openjdk.java.net/browse/JDK-8098835.
>>>>>
>>>>> The next patch can help:
>>>>>
>>>>> ---
>>>>> old/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java 
>>>>>
>>>>>
>>>>> 2015-06-16 20:20:42.678311800 +0300
>>>>> +++
>>>>> new/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java 
>>>>>
>>>>>
>>>>> 2015-06-16 20:20:42.136257600 +0300
>>>>> @@ -971,7 +971,7 @@
>>>>>               ((AbstractDocument)doc).readLock();
>>>>>           }
>>>>>           try {
>>>>> -            d.width = (int) rootView.getMinimumSpan(View.X_AXIS) +
>>>>> i.left + i.right;
>>>>> +            d.width = (int) rootView.getMinimumSpan(View.X_AXIS) +
>>>>> i.left + i.right + caretMargin;
>>>>>               d.height = (int) rootView.getMinimumSpan(View.Y_AXIS) +
>>>>> i.top + i.bottom;
>>>>>           } finally {
>>>>>               if (doc instanceof AbstractDocument) {
>>>>> @@ -996,7 +996,7 @@
>>>>>           }
>>>>>           try {
>>>>>               d.width = (int) Math.min((long)
>>>>> rootView.getMaximumSpan(View.X_AXIS) +
>>>>> -                                     (long) i.left + (long) i.right,
>>>>> Integer.MAX_VALUE);
>>>>> +                                     (long) i.left + (long) 
>>>>> i.right +
>>>>> caretMargin, Integer.MAX_VALUE);
>>>>>               d.height = (int) Math.min((long)
>>>>> rootView.getMaximumSpan(View.Y_AXIS) +
>>>>>                                         (long) i.top + (long) 
>>>>> i.bottom,
>>>>> Integer.MAX_VALUE);
>>>>>           } finally {
>>>>> @@ -1027,7 +1027,7 @@
>>>>>               Insets insets = editor.getInsets();
>>>>>               alloc.x += insets.left;
>>>>>               alloc.y += insets.top;
>>>>> -            alloc.width -= insets.left + insets.right;
>>>>> +            alloc.width -= insets.left + insets.right + caretMargin;
>>>>>               alloc.height -= insets.top + insets.bottom;
>>>>>               return alloc;
>>>>>           }
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 6/29/2015 10:13 AM, Vadim Pakhnushev wrote:
>>>>>> I think './common/bin/hgforest bisect ...' should do the trick then.
>>>>>>
>>>>>> On 29.06.2015 7:30, Phil Race wrote:
>>>>>>> Just be aware that you will need to apply the same to each repo in
>>>>>>> the JDK forest.
>>>>>>> Else it will very likely not build. Eg the jdk repo must be in sync
>>>>>>> with the top-level repo.
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 6/28/15 5:59 PM, Pete Brunet wrote:
>>>>>>>> Thanks Vadim, I'll give it a try.  -Pete
>>>>>>>>
>>>>>>>> On 6/28/15 3:24 PM, Vadim Pakhnushev wrote:
>>>>>>>>> Pete,
>>>>>>>>>
>>>>>>>>> Actually you should use hg bisect command to do this.
>>>>>>>>> First, you mark 2 revisions you now as bad and good, like this:
>>>>>>>>> hg bisect --good jdk9-b67
>>>>>>>>> hg bisect --bad tip
>>>>>>>>> The last command will bisect the list of changesets and update 
>>>>>>>>> the
>>>>>>>>> repo to some changeset in between.
>>>>>>>>> Then you build the repo, test it and mark it as either bad or 
>>>>>>>>> good:
>>>>>>>>> hg bisect --bad
>>>>>>>>> This will advance the current changeset and you test it again 
>>>>>>>>> until
>>>>>>>>> you arrive at the 'first bad' changeset.
>>>>>>>>> See here for reference: https://www.selenic.com/hg/help/bisect
>>>>>>>>>
>>>>>>>>> Hope this helps,
>>>>>>>>> Vadim
>>>>>>>>>
>>>>>>>>> On 28.06.2015 18:15, Pete Brunet wrote:
>>>>>>>>>> Looks like I can use hg update to accomplish this, i.e. hg 
>>>>>>>>>> update
>>>>>>>>>> to the
>>>>>>>>>> rev that is b67 and then hg update to each possibly offending 
>>>>>>>>>> rev
>>>>>>>>>> of the
>>>>>>>>>> jdk repo.  Sound right?
>>>>>>>>>>
>>>>>>>>>> On 6/26/15 4:13 PM, Pete Brunet wrote:
>>>>>>>>>>> Hi, I found a problem on b68 and there are a half dozen 
>>>>>>>>>>> possible
>>>>>>>>>>> changesets that could be responsible.  What is the best way to
>>>>>>>>>>> do the
>>>>>>>>>>> process of elimination.  It seems like the right approach would
>>>>>>>>>>> be to
>>>>>>>>>>> start with b67 and then add changesets one at a time until the
>>>>>>>>>>> problem
>>>>>>>>>>> surfaces.  Is that right or is there a better way?
>>>>>>>>>>>
>>>>>>>>>>> Starting with a fresh current clone what are the steps to strip
>>>>>>>>>>> back to
>>>>>>>>>>> b67 and then to add changesets?
>>>>>>>>>>>
>>>>>>>>>>> This will be in the jdk branch of the forest.
>>>>>>>>>>>
>>>>>>>>>>> Thanks, Pete
>>
>