<AWT Dev> debugging a regression

[Yuri Nesterenko]

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
>