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 fro
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 yeste
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
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.openj
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/j
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 +030
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.
O
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 P
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
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
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 coul
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 righ
12 matches
Mail list logo