You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(5) |
2
(3) |
3
(1) |
4
(4) |
5
(1) |
6
(11) |
7
(5) |
|
8
|
9
(6) |
10
(2) |
11
(10) |
12
|
13
|
14
(4) |
|
15
(7) |
16
(1) |
17
(3) |
18
|
19
|
20
|
21
(1) |
|
22
(1) |
23
|
24
|
25
|
26
|
27
|
28
(4) |
|
29
|
30
|
31
|
|
|
|
|
|
From: Jeremy F. <je...@go...> - 2002-12-06 23:33:17
|
On Fri, 2002-12-06 at 15:11, Julian Seward wrote:
> Re my analysis of stack-clearing add, I can't be exactly right, since
> VG_(emit_add_lit_to_esp) begins with the correct call to new_emit.
No, it isn't correct - True means "operate on Simd flags"; False means
"non-simd flags".
Fixing this seems to work, and even has a slight performance improvement
(OO starts up in 47 rather than 48 seconds). At very least it seems
performance neutral.
J
|
|
From: Jeremy F. <je...@go...> - 2002-12-06 23:27:24
|
On Fri, 2002-12-06 at 14:37, Julian Seward wrote:
> The translation is pretty dismal, due to calling helpers for both fnstsw and
> sahf, but "that's not important right now" :) The problem is the call the to
> latter's helper ... and specifically the add $0x4,%esp to clear the args off
> the stack. This trashes the live %eflags
Ah, yes, that's where I've seen moz spin. That's why I was suspecting
some badness in FP+flags interaction.
> Assuming this analysis is correct ... there's no convenient way to clear
> dead args off the real stack, unless we find a dead reg to dump it in.
Ewww, nasty.
> Umm, actually that's nonsense. Imagine we have a baseBlock slot purely
> for the purpose of receiving deal values, then we could do
>
> popl VGOFF_(dummySlot)(%ebp)
>
> Just occasionally, CISC is great!
>
> What do you think? Is the analysis correct?
Yes, that looks likely. The quick fix is to change the
VG_(new_emit)(True, ...) to False in emit_add_lit_to_esp, since that add
is not operating on Simd state. That will make it generate flag save
before trashing them. I agree the nicer solution is to fix the helper
calling convention to not trash the flags. How about changing the
convention to just use a real register for the value? Unfortunately for
helpers like CPUID, the stack does seem like the nicest way of doing the
passing (unless you want to allocate an array of slots in the bas
block).
It's a pity that SAHF/LAHF doesn't do the O flag; otherwise they'd be
ideal for flags saving/restoring - the P3 optim guide says they're 1
uop.
J
|
|
From: Julian S. <js...@ac...> - 2002-12-06 23:12:41
|
Apologies for mailbombing you even more. Quick prod with GDB shows OO is also spinning in a fstsw_AX .. SAHF ..conditional jump loop. J |
|
From: Julian S. <js...@ac...> - 2002-12-06 23:04:02
|
> > Hmm. This is very odd. I'm wondering if there is some problem with the
> > non-D flags (OSZACP) causing "if (res > 0) {" at line 2636 never to
> > get into the then-clause. Except that if there was such a problem,
> > most programs wouldn't work (I'd guess).
>
> I think that's a red herring.
I agree.
Re my analysis of stack-clearing add, I can't be exactly right, since
VG_(emit_add_lit_to_esp) begins with the correct call to new_emit.
So perhaps the analysis didn't think that we were in a UPD_Real state
at the point of the call to vgPlain_helper_SAHF. Except that as soon as
it has CLEARed the stack, it then acts to get into UPD_Simd/Both in
preparation for the conditional jump:
1: x/i $eip 0x42377bd2: pushf
1: x/i $eip 0x42377bd3: popl 0x20(%ebp)
Odd.
> In OO's case, thread 3 is polling on IO
> (I presume to the X server), thread 2 is blocked in a condvar_wait, and
> thread 1 is spinning CPU-bound. I'm guessing that thread 2 is waiting
> for either thread 1 or 3 to do something, and thread 1 is expected to do
> something but isn't.
Yes, so that fits together; at least we have a plausible explaination of
why it was spinning, if the moz problem also afflicts OO.
J
|
|
From: Jeremy F. <je...@go...> - 2002-12-06 22:41:26
|
On Fri, 2002-12-06 at 12:12, Julian Seward wrote:
> > Anyway, tell me what you get with the current versions of 61 and 62.
>
> No improvement with OO.
>
> I tried mozilla. It also won't start up, the simulated machine falling
> into an endless sequence of poll() calls seperated by nanosleep(13
> milliseconds), which afaics is the nonblocking poll() in vg_libpthread.c.
>
> Trying OO with tracing on indicates it spins in the same place.
>
> Hmm. This is very odd. I'm wondering if there is some problem with the
> non-D flags (OSZACP) causing "if (res > 0) {" at line 2636 never to
> get into the then-clause. Except that if there was such a problem,
> most programs wouldn't work (I'd guess).
I think that's a red herring. In OO's case, thread 3 is polling on IO
(I presume to the X server), thread 2 is blocked in a condvar_wait, and
thread 1 is spinning CPU-bound. I'm guessing that thread 2 is waiting
for either thread 1 or 3 to do something, and thread 1 is expected to do
something but isn't.
However, if I use "--trace-codegen=10001 --trace-signals=yes" and pipe
that into a "tail -100000" (my disk not being big enough to fit a
complete codegen trace) and then wait for it to stabilize (stop codegen
for new BBs, observed by looking at strace of the process), then it
tends to actually work. So that's no use.
Mozilla is similar. Sometimes it works, and sometimes it doesn't.
Sometimes it works, but takes a really long time. In particular, it
normally takes 30 user CPU seconds for moz to appear on my laptop with
--skin=none. Sometimes it never appears, and just seems to burn CPU.
Other times, it appears after 60 or more (wall-clock seconds), but after
still only using 30 CPU seconds (with nothing else using the CPU).
If you try just 61, do you see the same problem?
It does seem very fragile. I just added another patch to V, which
should be completely benign, but it changes the behaviour.
J
|
|
From: Julian S. <js...@ac...> - 2002-12-06 22:29:44
|
Hi. I think I've found an anomaly. Dunno if its the problem, might be tho. With mozilla spinning and not proceeding, a bit of prodding about shows it is spinning on these original insns: -- ORIGINAL CODE 0x4017263c <js_DoubleToECMAInt32+80>: fprem 0x4017263e <js_DoubleToECMAInt32+82>: fnstsw %ax 0x40172640 <js_DoubleToECMAInt32+84>: sahf 0x40172641 <js_DoubleToECMAInt32+85>: jp 0x4017263c The translation is pretty dismal, due to calling helpers for both fnstsw and sahf, but "that's not important right now" :) The problem is the call the to latter's helper ... and specifically the add $0x4,%esp to clear the args off the stack. This trashes the live %eflags -- push %AH 1: x/i $eip 0x42377bb6: mov 0x0(%ebp),%ebx 1: x/i $eip 0x42377bb9: mov $0xff00,%ecx 1: x/i $eip 0x42377bbe: and %ecx,%ebx 1: x/i $eip 0x42377bc0: push %ebx -- GET EFLAGS 1: x/i $eip 0x42377bc1: pushl 0x20(%ebp) 1: x/i $eip 0x42377bc4: popf -- call helper 1: x/i $eip 0x42377bc5: call *0x17c(%ebp) 1: x/i $eip 0x4005cc84 <vgPlain_helper_SAHF>: push %eax 1: x/i $eip 0x4005cc85 <vgPlain_helper_SAHF+1>: mov 0x8(%esp,1),%eax 1: x/i $eip 0x4005cc89 <vgPlain_helper_SAHF+5>: sahf 1: x/i $eip 0x4005cc8a <vgPlain_helper_SAHF+6>: pop %eax 1: x/i $eip 0x4005cc8b <vgPlain_helper_SAHF+7>: ret -- %eflags is now live -- oops! 1: x/i $eip 0x42377bcb: add $0x4,%esp -- move EIP 1: x/i $eip 0x42377bce: movb $0x41,0x24(%ebp) -- PUT (polluted) eflags 1: x/i $eip 0x42377bd2: pushf 1: x/i $eip 0x42377bd3: popl 0x20(%ebp) -- jump (on result of %esp-adjust :) 1: x/i $eip 0x42377bd6: jnp 0x42377be5 Assuming this analysis is correct ... there's no convenient way to clear dead args off the real stack, unless we find a dead reg to dump it in. Umm, actually that's nonsense. Imagine we have a baseBlock slot purely for the purpose of receiving deal values, then we could do popl VGOFF_(dummySlot)(%ebp) Just occasionally, CISC is great! What do you think? Is the analysis correct? I might check of all places where %esp is involved in an arithmetic op, since those are all potential trashers. J -------------------------------------------------------------------------- The complete translation, in case you should want it, is ... -- preamble 1: x/i $eip 0x42377b84: decl 0x400bb72c 1: x/i $eip 0x42377b8a: jne 0x42377b92 -- GET fpustate 1: x/i $eip 0x42377b92: frstor 0x8c(%ebp) -- fprem 1: x/i $eip 0x42377b98: fprem -- advance EIP 1: x/i $eip 0x42377b9a: movb $0x3e,0x24(%ebp) -- push $0 (why?) 1: x/i $eip 0x42377b9e: xor %eax,%eax 1: x/i $eip 0x42377ba0: push %eax -- PUT fpustate 1: x/i $eip 0x42377ba1: fnsave 0x8c(%ebp) 1: x/i $eip 0x42377ba7: call *0x178(%ebp) 1: x/i $eip 0x4005cc6d <vgPlain_helper_fstsw_AX>: push %eax 1: x/i $eip 0x4005cc6e <vgPlain_helper_fstsw_AX+1>: push %esi 1: x/i $eip 0x4005cc6f <vgPlain_helper_fstsw_AX+2>: mov 0x400a08e0,%esi 1: x/i $eip 0x4005cc75 <vgPlain_helper_fstsw_AX+8>: frstor 0x0(%ebp,%esi,4) 1: x/i $eip 0x4005cc79 <vgPlain_helper_fstsw_AX+12>: fstsw %ax 1: x/i $eip 0x4005cc7a <vgPlain_helper_fstsw_AX+13>: fnstsw %ax 1: x/i $eip 0x4005cc7c <vgPlain_helper_fstsw_AX+15>: pop %esi 1: x/i $eip 0x4005cc7d <vgPlain_helper_fstsw_AX+16>: mov %ax,0x8(%esp,1) 1: x/i $eip 0x4005cc82 <vgPlain_helper_fstsw_AX+21>: pop %eax 1: x/i $eip 0x4005cc83 <vgPlain_helper_fstsw_AX+22>: ret 1: x/i $eip 0x42377bad: pop %eax -- %ax holds FPU status word (simd) -- PUT %AX 1: x/i $eip 0x42377bae: mov %ax,0x0(%ebp) -- advance %EIP 1: x/i $eip 0x42377bb2: movb $0x40,0x24(%ebp) -- push %AH 1: x/i $eip 0x42377bb6: mov 0x0(%ebp),%ebx 1: x/i $eip 0x42377bb9: mov $0xff00,%ecx 1: x/i $eip 0x42377bbe: and %ecx,%ebx 1: x/i $eip 0x42377bc0: push %ebx -- GET EFLAGS 1: x/i $eip 0x42377bc1: pushl 0x20(%ebp) 1: x/i $eip 0x42377bc4: popf -- call helper 1: x/i $eip 0x42377bc5: call *0x17c(%ebp) 1: x/i $eip 0x4005cc84 <vgPlain_helper_SAHF>: push %eax 1: x/i $eip 0x4005cc85 <vgPlain_helper_SAHF+1>: mov 0x8(%esp,1),%eax 1: x/i $eip 0x4005cc89 <vgPlain_helper_SAHF+5>: sahf 1: x/i $eip 0x4005cc8a <vgPlain_helper_SAHF+6>: pop %eax 1: x/i $eip 0x4005cc8b <vgPlain_helper_SAHF+7>: ret -- %eflags is now live 1: x/i $eip 0x42377bcb: add $0x4,%esp 1: x/i $eip 0x42377bce: movb $0x41,0x24(%ebp) 1: x/i $eip 0x42377bd2: pushf 1: x/i $eip 0x42377bd3: popl 0x20(%ebp) 1: x/i $eip 0x42377bd6: jnp 0x42377be5 1: x/i $eip 0x42377bd8: mov $0x4017263c,%eax 1: x/i $eip 0x42377bdd: mov %eax,0x24(%ebp) 1: x/i $eip 0x42377be0: jmp 0x42377b84 |
|
From: Julian S. <js...@ac...> - 2002-12-06 20:19:25
|
Hmm, I tried the following, of course linked with libpthread and it works
perfectly. so no easy leads there :-(
J
#include <sys/poll.h>
#include <stdio.h>
int main ( void )
{
int fd;
struct pollfd tab[1];
fd = fileno(stdin);
tab[0].fd = fd;
tab[0].events = POLLIN;
printf("poll begins ... press return\n" );
poll( tab, 1, -1 );
printf("done\n");
return 0;
}
|
|
From: Julian S. <js...@ac...> - 2002-12-06 20:05:10
|
> Anyway, tell me what you get with the current versions of 61 and 62.
No improvement with OO.
I tried mozilla. It also won't start up, the simulated machine falling
into an endless sequence of poll() calls seperated by nanosleep(13
milliseconds), which afaics is the nonblocking poll() in vg_libpthread.c.
Trying OO with tracing on indicates it spins in the same place.
Hmm. This is very odd. I'm wondering if there is some problem with the
non-D flags (OSZACP) causing "if (res > 0) {" at line 2636 never to
get into the then-clause. Except that if there was such a problem,
most programs wouldn't work (I'd guess).
Opera works, so it's not threaded programs per se. Opera doesn't use
the nonblocking poll, tho.
J
|
|
From: Jeremy F. <je...@go...> - 2002-12-06 19:19:06
|
On Thu, 2002-12-05 at 17:15, Julian Seward wrote:
> I just tried 01- and 61- and 62- and things run faster. bzip2,
> xedit, kate work.
>
> However OO 1.0.1 no longer starts up. You know when you start it, there
> is a splash screen, which sits above all other windows. If I now run it
> with --skin=none --trace-children=yes, the same patch of screen behaves
> as if it is the splash screen, except that the picture of the bluish sky
> with the stylised birds does not appear -- that rectangle of screen contains
> whatever was there before.
>
> Does that make any sense? Can you repro it?
Well, I fiddled about a bit, and the symptom has gone away, without any
obvious changes on my part. The only significant thing I remember doing
was fixing a bug in 61-special-d which flipped the state of D over a
context switch (ie, when the dispatch counter dropped to 0). But when I
could reproduce it, it was only with 62 in place - it worked with the
buggy 61. Interestingly, I can still repro it with 63-chained-indirect
in place, even though that works for everything else (and when that
patch has bugs, they're rarely subtle).
So I'm somewhat confused. I wonder if its a timing/race problem in OO
itself, which we're sometimes hitting and sometimes not?
Anyway, tell me what you get with the current versions of 61 and 62.
J
|
|
From: Jeremy F. <je...@go...> - 2002-12-06 02:26:18
|
On Thu, 2002-12-05 at 17:15, Julian Seward wrote:
> However OO 1.0.1 no longer starts up. You know when you start it, there
> is a splash screen, which sits above all other windows. If I now run it
> with --skin=none --trace-children=yes, the same patch of screen behaves
> as if it is the splash screen, except that the picture of the bluish sky
> with the stylised birds does not appear -- that rectangle of screen contains
> whatever was there before.
>
> Does that make any sense? Can you repro it?
Hm, I don't even get the splash screen (but then I don't normally; maybe
I turned it off at one point). Looking into it. I have some suspicious
around flags and FP instructions.
J
|
|
From: Julian S. <js...@ac...> - 2002-12-06 01:08:10
|
Hi. That's great! I just tried 01- and 61- and 62- and things run faster. bzip2, xedit, kate work. However OO 1.0.1 no longer starts up. You know when you start it, there is a splash screen, which sits above all other windows. If I now run it with --skin=none --trace-children=yes, the same patch of screen behaves as if it is the splash screen, except that the picture of the bluish sky with the stylised birds does not appear -- that rectangle of screen contains whatever was there before. Does that make any sense? Can you repro it? J |