--- Log opened Sat Aug 01 00:00:22 2009 00:07 -!- ahuillet_ [n=ahuillet@114.169.66-86.rev.gaoland.net] has joined #jato 00:09 -!- ahuillet [n=ahuillet@205.251.80-79.rev.gaoland.net] has quit [Read error: 60 (Operation timed out)] 00:25 -!- ahuillet_ [n=ahuillet@114.169.66-86.rev.gaoland.net] has quit [Read error: 110 (Connection timed out)] 00:26 -!- ahuillet [n=ahuillet@114.169.66-86.rev.gaoland.net] has joined #jato 05:01 -!- ahuillet [n=ahuillet@114.169.66-86.rev.gaoland.net] has quit [Read error: 110 (Connection timed out)] 05:13 -!- ahuillet [n=ahuillet@191.169.66-86.rev.gaoland.net] has joined #jato 05:58 -!- ahuillet [n=ahuillet@191.169.66-86.rev.gaoland.net] has quit [Read error: 110 (Connection timed out)] 06:03 -!- ahuillet [n=ahuillet@191.169.66-86.rev.gaoland.net] has joined #jato --- Log closed Sat Aug 01 08:02:36 2009 --- Log opened Sat Aug 01 08:02:47 2009 08:02 -!- jato-irc1logger [n=vegard@cm-84.209.125.101.getinternet.no] has joined #jato 08:02 -!- Irssi: #jato: Total of 4 nicks [0 ops, 0 halfops, 0 voices, 4 normal] 08:02 -!- Irssi: Join to #jato was synced in 9 secs 08:16 -!- jato-irc-logger [n=vegard@cm-84.209.125.101.getinternet.no] has quit [Read error: 110 (Connection timed out)] 09:42 -!- tgrabiec [n=tomekg@bxd121.neoplus.adsl.tpnet.pl] has joined #jato 10:37 -!- ahuillet [n=ahuillet@191.169.66-86.rev.gaoland.net] has quit [Read error: 54 (Connection reset by peer)] 10:42 -!- ahuillet [n=ahuillet@143.152.72-86.rev.gaoland.net] has joined #jato 13:13 -!- penberg_home [n=penberg@cs149038.pp.htv.fi] has joined #jato 13:13 < penberg_home> hello! 13:15 < tgrabiec> hi 13:15 < penberg_home> 88 new mails in my inbox 13:15 < ahuillet> salut ! 13:15 < penberg_home> salut 13:16 < penberg_home> just opened my email client 13:16 < penberg_home> where are we now?-) 13:28 < ahuillet> vegard fixed a bug with use-def yesterday 13:31 < penberg_home> yeah? 13:32 < ahuillet> he sent a patch to the ML 13:32 < ahuillet> then we discussed and agreed his patch was correct, though he seemed to run into some kind of infinite loop before both of us went to bed 13:32 < ahuillet> so I don't know the present status and recommend against applying his patch until he confirms everything's ok on his side 13:32 < ahuillet> the patch does look OK, though :) 13:34 < tgrabiec> yup, and it unblocks some execution paths 13:36 < penberg_home> k 13:55 < tgrabiec> I'm currently working on getting this working: http://java.sun.com/docs/books/tutorial/uiswing/examples/start/HelloWorldSwingProject/src/start/HelloWorldSwing.java 13:58 < penberg_home> tgrabiec: nice 14:08 -!- ahuillet_ [n=ahuillet@143.152.72-86.rev.gaoland.net] has joined #jato 14:11 < tgrabiec> penberg_home: about recursive trace_mutex 14:11 < penberg_home> tgrabiec: yea? 14:11 < tgrabiec> it's problematic to make it not recursive 14:12 < tgrabiec> hmm, oh well, maybe it isn't 14:12 < ahuillet_> penberg_home : I forwarded to you vegard's explanation about the liveness fix. 14:13 < penberg_home> ahuillet_: ok 14:13 < penberg_home> tgrabiec: :) 14:13 < penberg_home> tgrabiec: I can assure you it's not a problem 14:13 < penberg_home> recursive mutexes are a hack AFAICT 14:14 < penberg_home> tgrabiec: btw, rest of the patches looked ok to me 14:14 < penberg_home> but they don't apply 14:14 < penberg_home> so I hope you'll just resend them 14:14 < tgrabiec> we can make the mutex not recursive and unlock it for the time of bytecode conversion 14:15 < tgrabiec> hmm, no it's not a good idea 14:15 < tgrabiec> the point is, that we don;t want multiple threads to mix their trace outputs 14:15 < tgrabiec> so we must hold the mutex for the whole compilation process 14:15 < penberg_home> or trace to a buffer. 14:16 < penberg_home> which is a much better solution anyway 14:16 < tgrabiec> penberg_home: yes, but make me a bit more miserable because of more work ;) 14:16 < penberg_home> yup, I know. 14:17 < penberg_home> that's why I took the initial hackish patches 14:17 < penberg_home> that used a mutex 14:17 < penberg_home> and didn't complain 14:17 < penberg_home> but recursive mutex is a deal-breaker, sorry 14:17 < penberg_home> otoh 14:17 < penberg_home> I am not completely convinced it's so much work anyway 14:17 < penberg_home> just use __thread again 14:17 < penberg_home> make a string buffer 14:17 < penberg_home> then at the end of compile() 14:18 < penberg_home> take a print_mutex or whatever 14:18 < penberg_home> flush the string buffer to stdout 14:18 < tgrabiec> penberg_home: yup, but steel there's plenty of printf() out there to fix 14:18 < penberg_home> unlock and clear the buffer 14:18 < penberg_home> which can be _trivially_ converted to 14:18 < tgrabiec> it's not hard, just boring 14:18 < penberg_home> thread_printf() or whatever 14:18 < penberg_home> that uses the global string buffer. 14:18 < tgrabiec> ok ok, I'll get it done 14:18 < penberg_home> tgrabiec: :) 14:18 < penberg_home> heh heh 14:24 -!- ahuillet [n=ahuillet@143.152.72-86.rev.gaoland.net] has quit [Read error: 110 (Connection timed out)] 14:24 -!- ahuillet_ is now known as ahuillet 14:25 < tgrabiec> penberg_home: about a separate mutex for static_fixup_site_list, sure we can reuse the mutex ofr the whole class, but doesn't it prevent concurrency ? 14:30 < penberg_home> tgrabiec: well, yes 14:30 < penberg_home> but is that a problem? 14:30 < penberg_home> I guess not? 14:31 < penberg_home> you usually want a mutex per object type of locking 14:31 < penberg_home> if you have _multiple_ locks for an object 14:31 < penberg_home> there needs to be a good reason for it 14:31 < penberg_home> and if you don't have any numbers or profile reports for that 14:31 < penberg_home> you're just guessing and should go for the simplest approach 14:32 < penberg_home> it's too easy to make mistakes there 14:32 < penberg_home> when people add new fields to struct vm_class 14:32 < penberg_home> and fail to understand what lock you need to take 14:32 < tgrabiec> ok, sounds reasonable to me 15:26 -!- Eduard_Munteanu [n=edi@93.112.58.99] has joined #jato 15:26 < Eduard_Munteanu> Hi. 15:30 < ahuillet> penberg_home : reaching definition as a different data flow problem as liveness analysis 15:30 < ahuillet> it's used in optimizers 15:30 < penberg_home> Eduard_Munteanu: hi 15:30 < penberg_home> ahuillet: the use-def part is not that different, is it? 15:30 < ahuillet> for liveness analysis we want the *local* "reaching definition" property 15:31 < penberg_home> in any case, I looked up the original algorithm 15:31 < penberg_home> and there's a figure where some variables are in *both* sets 15:31 < penberg_home> so I think we can just remove the bitset_sub part. 15:31 < ahuillet> penberg_home : variables can be in both sets, yes 15:31 < penberg_home> hmm 15:32 < penberg_home> so send a patch! :) 15:32 < ahuillet> what for? vegard's fixes it as far as I can tell 15:32 < penberg_home> no 15:32 < penberg_home> it doesn't add a variable to the "use" set 15:32 < penberg_home> if it's in the def set. 15:32 < penberg_home> so it's broken. 15:33 < ahuillet> grr, I lost his patch 15:33 < ahuillet> ok got it 15:34 < penberg_home> forwarded it 15:34 < ahuillet> his patch seems to be correct 15:34 < ahuillet> * It's in the use set if and only if it has not 15:34 < ahuillet> + * _already_ been defined by insn basic block. 15:34 < ahuillet> mind the "already" 15:34 < penberg_home> no 15:35 < penberg_home> it's not 15:35 < penberg_home> a variable can be in *both* sets. 15:35 < penberg_home> and I have a figure where 15:35 < penberg_home> c <- a + c 15:35 < penberg_home> has c in use and def sets. 15:35 < penberg_home> the whole "ordering" thing doesn't make *any* sense. 15:36 < ahuillet> actually it does. :) 15:36 < ahuillet> use, define in this order is not the same as define, use 15:36 < ahuillet> in the second case, you don't have to set the "use" bit 15:37 < penberg_home> hhmm 15:40 < penberg_home> ok 15:40 < penberg_home> you're right 15:40 < penberg_home> I'll apply the patch 15:40 < ahuillet> wait for his status report 15:41 < ahuillet> he was encountering strange bugs 15:41 < ahuillet> I don't know if it's tied to the patch or not 15:41 < ahuillet> but better not apply it till he sends green light 15:41 < penberg_home> hmm 15:41 < penberg_home> if make regression passes, I am applying it ;) 15:41 < ahuillet> I don't know whether this patch is to blame, we had no time to talk about it 15:41 < ahuillet> oh, heh :) 15:41 < penberg_home> either the patch is correct or it's not 15:41 < penberg_home> and AFAICT, it is. 15:41 < penberg_home> Acked-by: Ahuillet? 15:42 < ahuillet> definitely 15:42 < penberg_home> hmm 15:42 < penberg_home> ok 15:42 < penberg_home> works fine 15:43 < ahuillet> does println work better now? :) 15:44 < penberg_home> hmmm 15:44 < penberg_home> make test bombs 15:44 < penberg_home> in spill/reload tests now 15:44 < penberg_home> so NAK for the patch ;) 15:45 < penberg_home> so apparently it _has_ an effect on spill/reload too 15:46 < ahuillet> are spill/reload tests correct? 15:47 < penberg_home> dunno 15:47 < penberg_home> I didn't check. 16:31 -!- tgrabiec [n=tomekg@bxd121.neoplus.adsl.tpnet.pl] has quit [Remote closed the connection] 17:11 -!- Eduard_Munteanu [n=edi@93.112.58.99] has quit ["leaving"] 21:25 -!- mode/#jato [+o ahuillet] by ChanServ 21:25 -!- tgrabiec [n=tomekg@bxd121.neoplus.adsl.tpnet.pl] has joined #jato 21:33 < tgrabiec> omg, -Xtrace:jit output for the HelloWorldSwing has 44MiB 22:08 <@ahuillet> whow. 22:08 <@ahuillet> what's HelloWorldSwing? 22:08 < tgrabiec> ahuillet: this: http://java.sun.com/docs/books/tutorial/uiswing/examples/start/HelloWorldSwingProject/src/start/HelloWorldSwing.java 22:09 < tgrabiec> it displays a GUI window with "HelloWorld" text in the frame 22:09 <@ahuillet> no wonder it's 44MB :) 22:09 <@ahuillet> let's make println work first! 22:10 < tgrabiec> so, what's the status on the ThreadLocalTest bug ? 22:11 <@ahuillet> no idea, what is it? :) 22:11 < tgrabiec> ahuillet: I feel like having a dejavu 22:11 <@ahuillet> oh ? 22:12 < tgrabiec> I mean "me mentions the regalloc bug vegard wrote about on thursday, and ahuillet doesn't know about it" 22:13 < tgrabiec> ahuillet: any progress on vegrad's bug ? 22:13 < tgrabiec> what bug ? :] 22:13 < tgrabiec> I've got nothing to do, if yoy have the trace here I'll investigate 22:13 < tgrabiec> ahuillet: well, this one http://folk.uio.no/vegardno/trace3.txt 22:13 <@ahuillet> yeah that's pretty much the usual thing me not remembering what bug we're talking about 22:13 <@ahuillet> I kinda lost track after the 112nd :) 22:13 <@ahuillet> ahem, 122nd 22:13 <@ahuillet> or 112th 22:14 < tgrabiec> right, well so it's the current blocker for S.o.p 22:14 <@ahuillet> k 22:14 <@ahuillet> so, I don't think anyone actually investigated it 22:15 < tgrabiec> ahuillet: I looked at the assembly, and I can tell that we do not reload the right value before invokevirtual 22:16 <@ahuillet> %ebx contains the object pointer at this point. 22:16 <@ahuillet> right after the "push %ebx", we should reload another value into %ebx? 22:17 < tgrabiec> ahuillet: the point is that when we jump to 0xa7c91909:, the ebx doesn not contain rigth value, we should hit mov edi, ebx first, i think 22:18 <@ahuillet> so the push %ebx pushes the wrong value too? 22:18 <@ahuillet> better question : is the LIR correct? 22:18 <@ahuillet> I don't understand vegard's comment 22:18 <@ahuillet> *comments 22:18 < tgrabiec> yup, the LIR seems correct 22:19 <@ahuillet> ok, I'll check the LIR <-> assembly then 22:21 < penberg_home> ok 22:21 < penberg_home> so 22:21 < penberg_home> I am off for a night out! 22:21 < penberg_home> (again) 22:21 < penberg_home> so have fun 22:21 < penberg_home> and send lots of patches 22:21 < penberg_home> :) 22:22 <@ahuillet> don't drink too much. :) 22:22 <@ahuillet> or do drink too much if such is your wish... :) 22:23 < tgrabiec> ahuillet: the regalloc says that vreg8 is reloaded at pos 26, while we take a branch at 27, so we "miss" the reload 22:23 <@ahuillet> err 22:24 <@ahuillet> control flow resolution should take care of this properly 22:26 <@ahuillet> [ 19 ] 0xa7c918d0: 89 fe mov %edi,%esi 22:26 <@ahuillet> [ 16 ] 0xa7c918d2: 89 5d a8 mov %ebx,-0x58(%ebp) 22:26 <@ahuillet> [ 16 ] 0xa7c918d5: 8b 75 e0 mov -0x20(%ebp),%esi 22:26 <@ahuillet> [ 16 ] 0xa7c918d8: ff 75 a8 pushl -0x58(%ebp) 22:26 <@ahuillet> [ 20 ] 0xa7c918db: 8f 45 e4 popl -0x1c(%ebp) 22:26 <@ahuillet> [ 16 ] 0xa7c918de: e9 26 00 00 00 jmp 0x00000000a7c91909 22:26 <@ahuillet> sorry kinda big paste but it's easier to work with this way 22:26 <@ahuillet> so, the first mov 22:26 <@ahuillet> [ 19 ] 20: mov_reg_reg r7, r8 22:26 <@ahuillet> probably is this 22:27 <@ahuillet> then, the four instructions before the jump are control flow resolving moves 22:27 <@ahuillet> normally they should be putting things at the right places. 22:27 <@ahuillet> you'll note we screw up %esi in the process. :) 22:27 < tgrabiec> right 22:28 <@ahuillet> [ 16 ] 0xa7c918de: e9 26 00 00 00 jmp 0x00000000a7c91909 22:28 <@ahuillet> [ 16 ] 0xa7c918e3: 89 75 dc mov %esi,-0x24(%ebp) 22:28 <@ahuillet> we do spill it 22:28 <@ahuillet> but after the jump, so we're doing something not correct 22:28 <@ahuillet> so, at the target of the jump, %ebx is not correct you say 22:29 <@ahuillet> [ 20 ] 28: push_reg r8 22:29 < tgrabiec> yup 22:29 <@ahuillet> we need a mov %esi %ebx somewhere 22:30 <@ahuillet> so why don't we have it... 22:31 <@ahuillet> we do some nice work for %edi 22:31 <@ahuillet> placing the value in -0x1c(%ebp) 22:31 <@ahuillet> but there seems to be nothing at all writing %ebx before the jump or at the jump target 22:32 <@ahuillet> therefore we can assume that control flow resolution is not properly detecting it has to do something 22:34 <@ahuillet> so, let me cherry pick my tracing code 22:34 <@ahuillet> and have some fun. :) 22:37 < tgrabiec> sure :) 22:40 <@ahuillet> do you know why when I add ThreadLocalTest.java to regression/jvm 22:40 <@ahuillet> and add it into Makefile 22:40 <@ahuillet> it does *not* get built? 22:40 <@ahuillet> it gets on my nerve a little bit. :) 22:41 <@ahuillet> itable resolver stub error! 22:41 <@ahuillet> is that the expected crash for this test? 22:41 < tgrabiec> ahuillet: yes, it's the crash caused by the invalid value of "this" (first arg) 22:42 < tgrabiec> ahuillet: oh, wait a second 22:42 <@ahuillet> yes? 22:42 < tgrabiec> ahuillet: it looks like the vegard's patch solves the problem 22:42 <@ahuillet> which patch? 22:43 < tgrabiec> the one which fxes use-def, not yet in mainline because of make test 22:43 <@ahuillet> I don't believe it yet 22:43 <@ahuillet> I don't see why :/ 22:43 < tgrabiec> you don't see why what ? 22:44 <@ahuillet> > What regression test does it fix? 22:44 <@ahuillet> It fixes the issue I started trying to solve two days ago, where the 22:44 <@ahuillet> invokeinterface would get called on the wrong reference (see below). 22:44 <@ahuillet> vegard did actually make this patch to fix this problem, I think :] 22:44 <@ahuillet> (I'm quoting his reply) 22:45 < tgrabiec> right, so apparently S.o.p is now blocked by this: http://pastebin.com/d15f23b88 22:46 <@ahuillet> sounds like a job for me. :] 22:46 <@ahuillet> hey, would you mind re-running this with a tracing patch of mine? 22:46 <@ahuillet> provided I still have it :/// 22:46 < tgrabiec> ahuillet: why don;t you rerun it with vegard's patch ? 22:47 <@ahuillet> my tree's a mess, but yeah 22:47 < tgrabiec> I already have it in my tree, makes the world move forward 22:48 <@ahuillet> you have no idea about my build problem btw? 22:48 <@ahuillet> do you know why when I add ThreadLocalTest.java to regression/jvm 22:48 <@ahuillet> and add it into Makefile 22:48 <@ahuillet> it does *not* get built? 22:49 <@ahuillet> vm/field.c:172: warning: vm_field_init_static not implemented 22:49 <@ahuillet> is that bad? 22:49 <@ahuillet> S.o.println spits that out 22:49 < tgrabiec> I think it's about double 22:50 <@ahuillet> oh, that's what vegard was asking me about then :) 22:50 <@ahuillet> fuck it 22:50 <@ahuillet> so we have println in an infinite loop 22:50 <@ahuillet> possibly because of lack of double support 22:50 < tgrabiec> it infinites loop on your machine? 22:50 <@ahuillet> seems to. 22:50 < tgrabiec> on mine it crashes... after several seconds 22:50 <@ahuillet> or it's reaaaaaaaaaaaaaaal slow :) 22:51 < tgrabiec> it runs 10 second here 22:51 <@ahuillet> what CPU do you have? 22:51 <@ahuillet> -rw-r--r-- 1 arthur users 31M 2009-08-01 22:50 abc 22:52 <@ahuillet> 42MB 22:52 <@ahuillet> 57MB 22:52 <@ahuillet> .... 22:52 < tgrabiec> ahuillet: core 2 duo, t7100 22:52 <@ahuillet> running in x86? 22:52 <@ahuillet> ok I'm stopping at 80MB of dump. 22:53 < tgrabiec> ahuillet: try with -Xtrace:invoke, it stops for ~300ms in HashMap.next 22:53 < tgrabiec> *java/util/HashMap$HashIterator.hasNext()Z 22:53 <@ahuillet> http://paste.pocoo.org/show/132093/ 22:53 <@ahuillet> that's the result of grep TRACE over the file 22:53 <@ahuillet> let me try out invoke 22:54 <@ahuillet> [thread: main] trace invoke: java/util/HashMap$HashIterator.hasNext()Z 22:54 <@ahuillet> stops here 22:54 <@ahuillet> and basically seems to infinite loop back there 22:54 < tgrabiec> for me it does not stop, but significantly delays, so it must be something wrong there, possibly a loop on initialized counter ? 22:55 < tgrabiec> *uninintialized 22:55 <@ahuillet> it filled up my RAM and my swap 22:55 < tgrabiec> maybe it has something to do with the ignored DOUBLE field initializers 22:55 <@ahuillet> yeah, it certainly does :) 22:55 <@ahuillet> so, I'm gonna have to ask you for an HIR trace of the function where it crashes 22:55 <@ahuillet> since I can't reproduce the problem here apparently 22:59 <@ahuillet> tgrabiec : any chance you can get me this dump? 23:00 <@ahuillet> I'm implementing the double field initializers 23:00 < tgrabiec> ahuillet: yeah, it's being generating right now 23:00 < tgrabiec> *generated 23:00 <@ahuillet> oh, is it big? 23:01 < tgrabiec> I'm waiting for the whole trace, and I'll cut out the thing from it 23:04 <@ahuillet> building 23:04 <@ahuillet> mmh, it doesn't work 23:04 <@ahuillet> 600MB of RAM for a S.o.println........... 23:04 <@ahuillet> not good 23:04 <@ahuillet> same thing as before. 23:06 <@ahuillet> http://ahuillet.users.sourceforge.net/up/0001-vm-implement-vm_field_init_static-for-double-data-ty.patch 23:06 <@ahuillet> tgrabiec: here is my patch, if it does you any good... 23:15 < tgrabiec> ahuillet: it finally ended, the last 1000 line of trace are here: http://pastebin.com/ 23:15 < tgrabiec> here: http://pastebin.com/d60866739 23:16 < tgrabiec> ok, my wife gives my an angry eye, gotta go ;) 23:16 <@ahuillet> good night and whatever comes before :) --- Log closed Sun Aug 02 00:00:22 2009