--- Log opened Tue Jul 21 00:00:22 2009
08:49 < vegard> hi
08:49 < vegard> ahuillet: ping
11:05 < ahuillet> hello
11:05 < ahuillet> vegard : pong
11:22 < vegard> hi
11:22 < vegard> ack
11:26 < ahuillet> syn/ack
11:28 < ahuillet> vegard : I've got something ready, it fixes SubstringTest
11:28 < ahuillet> but not PrintTest yet
11:34 < vegard> oh
11:34 < vegard> cool
11:35 < vegard> so does PrintTest break because of something else unrelated?
11:35 < vegard> or is it just a different shade of the same bug?
11:35 < ahuillet> have you seen my patch I sent yesterday?
11:35 < vegard> no
11:35 < vegard> let me find it
11:35 < ahuillet> it has a NOT_IMPLEMENTED; line
11:35 < ahuillet> and I'm hitting exactly this :)
11:35 < vegard> aha
11:35 < vegard> when is pekka coming back, do you know?
11:35 < ahuillet> tomorrow IICR
11:35 < ahuillet> *IIRC
11:38 < vegard> do you know how to fix it? :B
11:39 < ahuillet> fix what?
11:39 < vegard> NOT_IMPLEMENTED line
11:39 < ahuillet> well, this NOT_IMPLEMENTED line, yes
11:39 < ahuillet> although there is something else, the algorithm requires sorting the MOV
11:40 < ahuillet> so for example if you have to mov EAX into EBX and EBX into ECX
11:40 < ahuillet> the only "correct" order to do this is EBX -> ECX; EAX -> EBX
11:40 < ahuillet> I'm not doing that, yet
11:40 < ahuillet> because for now in our test cases we have 0 moves (everything but SubstringTest and PrintTest) or 1 move (Substring and PrintTest)
11:41 < vegard> ouch, it sounds hard :)
11:41 < vegard> or maybe: it sounds complex.
11:41 < ahuillet> yes, especially because it theorically has no solution in case you have to swap all registers
11:41 < ahuillet> ie. I need a temporary
11:41 < ahuillet> so I'm not gonna do this right now :)
11:41 < vegard> ah
11:42 < vegard> is it possible to reach such a situation?
11:42 < ahuillet> I wasn't able to prove that or the opposite
12:01 < ahuillet> oh, penberg is back it seems
12:01 < ahuillet> he applied my patch.
12:02 < vegard> mine too :D
12:18 -!- penberg_home [n=penberg@cs149038.pp.htv.fi] has joined #jato
12:18 < penberg_home> ahuillet: http://github.com/penberg/jato/commit/e7bd57fa4f744207b5e1c3098baa7af63282addb
12:19 < penberg_home> ahuillet: http://github.com/penberg/jato/commit/839585867ed434af80f2d1b73ad335e505f7ea07
12:19 -!- mode/#jato [+o penberg_home] by ChanServ
12:19 <@penberg_home> 78% !
12:19 <@penberg_home> http://jatovm.sourceforge.net/bytecode-coverage.html
12:20 < ahuillet> hey penberg_home
12:20 <@penberg_home> hey
12:21 < ahuillet> penberg_home : we do fdiv too
12:21 <@penberg_home> aah
12:21 <@penberg_home> I'll fix that up.
12:22 < ahuillet> http://github.com/penberg/jato/commit/839585867ed434af80f2d1b73ad335e505f7ea07 <- this was tgrabiec's code ;)
12:22 < ahuillet> nice job on the shifts
12:22 <@penberg_home> ahuillet: aah
12:23 <@penberg_home> but yeah, the char conversion thing was just broken.
12:33 < ahuillet> vegard : ping
12:33 < ahuillet> vegard : I'd like some help for PrintTest
13:17 <@penberg_home> vegard: PrintTest?
13:18 < ahuillet> I'm encountering a NullPointerException in some <god I hate java, 4000000 lines of code for a println> object code
13:19 < ahuillet> PermissionCollection.setReadOnly I think
13:38 < vegard> ping.
13:40 < ahuillet> vegard : brb
13:40 < ahuillet> vegard : I'd love if you could try PrintTest with a patch I'll send you
13:40 < ahuillet> and help me investigate
13:40 < vegard> yes, ok! :)
13:44 < ahuillet> some intervals are unassigned (REG_UNASSIGNED)
13:44 < ahuillet> and I thought it was normal
13:44 < ahuillet> but in fact it probably is not
13:48 < ahuillet> vegard : I have a trace of System.out.println("hello world")
13:48 < vegard> yes?
13:48 < vegard> please post
13:48 < ahuillet> I'm trying to...
13:49 < ahuillet> it's huge...
13:49 < ahuillet> six megabytes. :)
13:50 < vegard> uhu
13:50 < vegard> pastebin won't take it.
13:50 < vegard> we should narrow it down
13:50 < ahuillet> 280K after bzip2
13:51 < ahuillet> http://ahuillet.users.sourceforge.net/up/out.bz2
13:52 < vegard> ok
13:52 < vegard> isn't it in java.security.ProtectionDomain.<init>(ProtectionDomain.java:132) ?
13:53 < ahuillet> I would think so, but why?
13:53 < vegard> hm
13:53 < vegard> I don't have a matching classpath source and binaries
13:54 < ahuillet> i'd like to know if it's a bug in my code or what
13:54 < vegard> I don't think it is
13:54 < vegard> but you should redo it with -Xtrace:exceptions
13:54 < vegard> that way we get to know where the exception occurred
13:54 < ahuillet> I'll confess something to you
13:54 < ahuillet> my new code isn't used in this trace.
13:55 < ahuillet> but it goes further than before anyway. :)
13:55 < ahuillet> I added printfs in my code and I see none show up
13:55 < vegard> ah
13:55 < vegard> fwiw the log you sent me looks exactly like what I get here and what pekka got before he left
13:56 < ahuillet> sounds like I have been fixing the wrong problem then?
13:56 < ahuillet> why is it we used to hit something in Substring?
13:57 < vegard> um
13:57 < ahuillet> http://paset.pocoo.org/show/129865
13:57 < ahuillet> here's the exception trace
13:57 < vegard> um, and -Xtrace:jit? :)
13:57 < vegard> I wanted to get the EIP that threw the exception so that we can find the opcode
13:58 < vegard> ah
13:59 < vegard> if you have the source code of java.security.ProtectionDomain there
13:59 < vegard> I think the problem was this line:
13:59 < vegard>     this.principals =
13:59 < vegard>         (principals != null ? (Principal[]) principals.clone() : new Principal[0]);
13:59 < ahuillet> I updated out.bz2 at the same URL as before
13:59 < vegard> because something there is null which shouldn't be
13:59 < ahuillet> yeah, but is my code wrong somehow?
13:59 < ahuillet> I don't manage to reproduce the Substring problem
14:00 < ahuillet> http://paste.pocoo.org/show/129866 <- this is the substringtest I am using
14:00 < ahuillet> what happens when you try to run it with current HEAD?
14:00 < vegard> the new trace is with your patches?
14:01 < ahuillet> yeah, but I think they're unused
14:01 < ahuillet> vegard : I want to reproduce the substring problem
14:01 < ahuillet> to see if I've actually fixed anything
14:01 < vegard> right
14:02 < ahuillet> so, how does substring test behave for you?
14:02 < ahuillet> (sorry for asking for help but I really am lost)
14:03 < ahuillet> (too high level for me maybe :P)
14:03 < vegard> um
14:03 < vegard> it runs fine here..
14:03 < vegard> oh
14:03 < vegard> sorry, that's with your patch
14:04 < vegard> no it's not
14:04 < vegard> *confused*
14:04 < vegard> ok, so as far as I can tell
14:04 < vegard> that test runs fine with latest mainline
14:04 <@penberg_home> what are you guys doing?-)
14:04 <@penberg_home> mainline should be fine
14:05 <@penberg_home> or is this a new test?
14:05 < vegard> new test
14:05 < vegard> :-(
14:05 <@penberg_home> aa
14:05 < vegard> something else changed, this used to crash.
14:05 <@penberg_home> i fixed stuff ;)
14:05 <@penberg_home> what kind of test is it?
14:05 <@penberg_home> i fixed some conversion things
14:06 <@penberg_home> and implemented some 64-bit shifts.
14:06 < vegard> it's supposed to test the register allocator bug thingy with dup expressions and IF
14:06 <@penberg_home> aa
14:07 < vegard> I'll bisect it
14:08 < vegard> :-(
14:09 < vegard> ahuillet: didn't the SubstringTest use to crash for you too??
14:11 < vegard> well
14:11 < vegard> we should be able to reproduce it using the real String.substring()
14:12 <@penberg_home> vegard: http://java.sun.com/developer/technicalArticles/DynTypeLang/index.html
14:12 <@penberg_home> heh heh hee!
14:13 < vegard> ahuillet: http://pastebin.com/m50dd86f2
14:13 < vegard> SIGSEGV at EIP 080749cb while accessing memory address 55535657.
14:14 < vegard> penberg_home: AW. you're not making me implement that.
14:14 < ahuillet> vegard : so this test crashes?
14:15 < vegard> ahuillet: yes, for me it does
14:15 < vegard> don't know if it's the regalloc bug thingy though.
14:15 < vegard> but this is where we saw the bug before
14:16 <@penberg_home> vegard: ;)
14:16 < ahuillet> k
14:16 < ahuillet> god we're SLOW
14:16 < ahuillet> or maybe it's just the terminal output
14:17 < ahuillet> StringIndexOutOfBoundsException <- bad to get that?
14:17 < vegard> I don't get it
14:17 < vegard> but yes
14:17 < ahuillet> fuck it
14:17 < vegard> it's not what we want
14:17 < vegard> so "hello".substring(1, 2) shuold return "el"
14:18 < vegard> for me it crashes with SIGSEGV in native_vmsystem_arraycopy
14:18 < ahuillet> I go slightly further it seems
14:19 < ahuillet> but why...
14:19 < vegard> you're running with your patches right?
14:19 < vegard> aha
14:19 < vegard> try running without any -Xtrace at all
14:19 <@penberg_home> hmmm
14:19 < vegard> I now tried with -Xtrace:invoke (only) and I got this: Exception in thread "main" java/lang/StringIndexOutOfBoundsException: offset + count: 30236
14:20 <@penberg_home> __builtin_return_addr() crap again?
14:21 < vegard> I think this is a kind of bug that should not happen :)
14:21 <@penberg_home> yes
14:22 < ahuillet> you guys know about those live intervals that have REG_UNASSIGNED?
14:22 < ahuillet> I'm sure you found plenty
14:22 < ahuillet> well, it's not normal at all. :]
14:22 <@penberg_home> that's not good.
14:22 < ahuillet> I thought it was.
14:26 < ahuillet> penberg_home : ping
14:26 < ahuillet> penberg_home : test_bit(live_in_set, 25) <- this will tell me if vreg 25 is alive at entry of the block, right?
14:26 < ahuillet> how comes I have many blocks which have a vreg live_in, but no interval covering them:
14:26 < ahuillet> ?
14:29 <@penberg_home> hmm
14:30 <@penberg_home> yes, that's what test_bit there should do
14:30 < ahuillet> ok, so I'm using it correctly
14:30 <@penberg_home> liveness analysis problem? use-def problem for some insns?
14:31 < ahuillet> http://paste.pocoo.org/show/9xB9Q0PDPXVBZf9wE9Re/
14:32 < ahuillet> I had to add that.
14:33 <@penberg_home> hmm
14:33 <@penberg_home> ok
14:33 <@penberg_home> I wonder where those are coming from thouogh
14:34 < ahuillet> same here
14:34 < ahuillet> that and the REG_UNASSIGNED
14:36 < ahuillet> btw, Wimmer's algorithm is underspecified
14:36 < ahuillet> each day that passes I like his thesis less
14:36 < vegard> heh
14:36 < vegard> can you e-mail them to ask?
14:37 -!- tgrabiec [n=tgrabiec@bpr136.neoplus.adsl.tpnet.pl] has joined #jato
14:37 < ahuillet> I'd rather not, it would take a very long time to explain etc.
14:37 < ahuillet> ok so, where are we
14:37 < ahuillet> the patch I've been working on recently seems to be useless
14:37 < ahuillet> I mean, we're not sure we have a bug in the regallocator are we?
14:37 < ahuillet> err, we're not sure we are hitting this bug we know we have, I mean
14:37 < ahuillet> hey tgrabiec
14:37 < vegard> apparently yes.
14:37 < tgrabiec> hi all
14:37 < ahuillet> tgrabiec : remember the substring problem?
14:38 < tgrabiec> yeah
14:38 < ahuillet> who was it who concluded it was because of the register allocator?
14:38 < ahuillet> I don't think I investigated it myself, was it you?
14:38 < tgrabiec> yes, I investigated the generated assembly
14:39 < ahuillet> are you getting a StringIndexOutOfBounds exception?
14:39 < ahuillet> or was it something else?
14:39 < tgrabiec> yes, it was this
14:39 < ahuillet> ok
14:39 < tgrabiec> and it is thrown because f corruption in substring AFAIK
14:39 < ahuillet> corruption?!
14:39 < vegard> count: -1211068672
14:39 < vegard> the count is comletely whacky
14:40 < ahuillet> yeah, that's for sure
14:40 < ahuillet> question is why ;)
14:40 < tgrabiec> ahuillet: isn't it the problem you were working on recently ?
14:40 < ahuillet> that's the problem my patch was supposed to fix
14:40 < ahuillet> but it doesn't
14:40 < ahuillet> so I want to check the original diagnostic was right
14:41 < tgrabiec> so, substring still doesn't work, but the assembly seems tobe good ?
14:41 < ahuillet> I don't know about the assembly yet, i'll read it
14:42 < tgrabiec> ahuillet: you can try running jato with -Xtrace:invoke-verbose, so you can see when the args are getting corrupted
14:42 < vegard> unfortunately, using -Xtrace: changes the output, at least for me :-(
14:43 < tgrabiec> but, calling substring("asds",1,2) fails right ?
14:44 < tgrabiec> "asda".substring(1,2)
14:44 < vegard> "asdf".substring(1, 2) fails (for me) with SIGSEGV without any -Xtrace, and fails with IndexOOBException with -Xtrace:invoke
14:45 < tgrabiec> I think that the register allocator bug could produce such behaviors, because it uses registers which value is not assigned in substring(), I'd suggest looking at assembly. Too bad I don't have my laptop here
14:45 <@penberg_home> vegard, tgrabiec: can we get the tracing causes SIGSEGV bugs fixed pls?
14:46 < ahuillet> tgrabiec : I'm positive the register allocator problem could produce this
14:57 < vegard> for me it is now crashing in trace_lir() all of a sudden
14:57 < vegard> or so it seems.
14:59 < vegard> #1  0x0805c0d5 in compile (cu=0x1) at jit/compiler.c:89
14:59 < vegard> ok, it has to be stack corruption
15:00 < ahuillet> that's a bit worrying
15:00 < ahuillet> a regallocator bug by itself probably could not do that
15:09 < vegard> ok
15:09 < vegard> so what's the plan now?
15:09 < ahuillet> I'm reading assembly
15:09 < ahuillet> the UNASSIGNED things seem fine to me
15:10 <@penberg_home> ahuillet: yeah?
15:10 < ahuillet> penberg_home : yes, and it's in wimmer's algorithm
15:10 <@penberg_home> please explain :)
15:11 < ahuillet> I'm looking it up right now.
15:12 < ahuillet> __spill_interval_intersecting()
15:12 < ahuillet> when we spill like this
15:12 < ahuillet> we split the interval at the position of the intersection
15:12 < ahuillet> but the split child is then split again at its next use position
15:15 <@penberg_home> hmmh
15:15 <@penberg_home> well, ok ;)
15:15  * penberg_home is off, will be back later this evening
15:24 < vegard> ah, ok
15:24 < vegard> now I have a test-case again
15:24 < vegard> a simple one
15:24 < ahuillet> oh. good
15:24 < vegard> well, simpler than a 3 MB trace ;)
15:28 < vegard> uhu
15:28 < vegard> actually it's 5.8M
15:29 < vegard> ah
15:30 < vegard> but it's just because assertTrue() wants to use String
15:32 < vegard> http://pastebin.com/m7c17a796
15:32 < vegard> I didn't simplify it
15:32 < vegard> it probably helps to understand what goes wrong if you use -Xtrace:invoke
15:33 < vegard> it shows that the arguments passed to the second C constructor are completely wrong
15:33 < vegard> (this test returns 0 with hotspot, and 1 with jato)
15:33 < vegard> and the whole trace is 1290 lines
15:38 < vegard> http://pastebin.com/m441c6beb
15:38 < vegard> that's a slightly reduced one
15:39 < vegard> will now see if your patches fixes that
15:39 < vegard> *fix
15:40 < ahuillet> you don't have an up to date version, but I'm encountering other problems right now.
15:40 < vegard> ok with your patch I get segfault in insert_mov_insn
15:41 < ahuillet> ok, not surprising
15:41 < ahuillet> I'll handle it from now, thanks
15:41 < ahuillet> I need to find out about those REG_UNASSIGNED.
15:41 < vegard> ok :)
15:44 < ahuillet> god I hate -Werror
15:44 < ahuillet> vegard, penberg_home, tgrabiec : btw, any update about coming to FOSDEM?
15:46 < vegard> just: I want to go and I don't see what would be stopping me from going.
15:47 < ahuillet> money
15:48 < vegard> ;)
15:48 < vegard> I have teh gsoc!
15:48 -!- Eduard_Munteanu [n=edi@79.115.194.103] has joined #jato
15:48 < Eduard_Munteanu> Hi there.
15:48 < Eduard_Munteanu> penberg_home, you're back :)
15:48 < vegard> hi!
15:49 < ahuillet> penberg_home : page 71 of the thesis
15:50 < ahuillet> "Therefore, they are split a second time before these use positions, and the second split children are sorted into the unhanded list"
15:50 < ahuillet> grep for that, it explains the UNASSIGNED thing.
15:51 < Eduard_Munteanu> Is EXPR_INSTANCE_FIELD used for local variable access somehow? I'm working on FibonacciTest.
15:56 < vegard> I wouldn't think so but I don't know for sure :)
16:00 < ahuillet> ok, I understand the problem now.
16:00 < ahuillet> REG_UNASSIGNED is perfectly normal and acceptable
16:00 < ahuillet> but wimmer's algorithm isn't properly specified related to the existence of those intervals with no register assigned
16:03 < vegard> can you fix it? :B
16:03 < ahuillet> that's my job, baby
16:03 < ahuillet> I'll try the straightforward solution I have in mind
16:04 -!- tgrabiec [n=tgrabiec@bpr136.neoplus.adsl.tpnet.pl] has quit [Read error: 110 (Connection timed out)]
16:19 -!- tgrabiec [n=tomekg@app62.neoplus.adsl.tpnet.pl] has joined #jato
16:27 < ahuillet> tgrabiec : assembly dump lists bytecode offsets
16:27 < ahuillet> do you mind if I make it LIR offsets instead?
16:28 < ahuillet> oh, do we have that information at all...
16:29 < tgrabiec> ahuillet: we don't have such info, I think
16:29 < ahuillet> crap
16:30 < tgrabiec> ahuillet: sorry, we do - we can lookup all struct insn, and check mach_offset to find a struct insn corresponding to some EIP
16:31 < tgrabiec> so, it's slow, but doable
16:31 < tgrabiec> and I'm ok with the change
16:32 < ahuillet> I found out what the problem was
16:32 < ahuillet> grrrrr
16:35 < vegard> oooh, oooh
16:35 < vegard> please do say
16:35 < tgrabiec> so substring problem is solved ?
16:35 < ahuillet> ok so
16:35 < ahuillet> when I insert a mov between two stack slots
16:35 < ahuillet> because this is the most common case apparently
16:35 < ahuillet> a register is spilled in block A and reloaded from another slot in block C
16:36 < ahuillet> because control flow as seen by the linera scan algorithm was A -> B -> C and it did not see A -> C
16:36 < ahuillet> when I do that, I need to do it on the edge of the basic blocks - at a boundary
16:36 < ahuillet> I was doing it at live interval boundaries, which screws up everything
16:36 < ahuillet> but I'm not sure, alas
16:37 < ahuillet> oh no it's actualy ok
16:37 < ahuillet> what I did wrong is that I reload the register and *after* I do the mov
16:37 < ahuillet> so it's reload from wrong slot, mov right slot, wrong slot
16:37 < ahuillet> and should be the other way around
16:41 < vegard> did you make the patch!? does it work??
16:43 < ahuillet> I'm on it.
16:43 < ahuillet> it's easier said than done ;)
16:49 < ahuillet> I'll be slower now because the debates at our parliament for that stupid internet law have started again
16:53 < ahuillet> and I'm watching them
17:01 < vegard> I can't wait for this generation to grow up ;)
17:01 < vegard> (and decide stuff.)
17:12 < ahuillet> not sure it will do much better
17:16 -!- tgrabiec [n=tomekg@app62.neoplus.adsl.tpnet.pl] has quit [Remote closed the connection]
17:30 < Eduard_Munteanu> ahuillet, yeah, I agree. When someone gets to _make_ decisions, stupidity surfaces.
17:33 < vegard> I don't mean to be impatient, but how is the patch doing? :B
17:34 < ahuillet> my friend I'm staying at came back from work
17:34 < ahuillet> and we're going to the pub so I guess it will be tomorrow
17:34 < ahuillet> I can send you a preliminary patch if you're impatient
17:34 < ahuillet> and/or have an evening to kill reading x86 assembly
17:34 < Eduard_Munteanu> Is this about the print to stdout patch?
17:34 < vegard> ah, right. no, I'll wait :)
17:35 < ahuillet> Eduard_Munteanu : it's about making println() work
17:38 < Eduard_Munteanu> ahuillet, oh, great stuff, hurry up then :P
18:31 -!- Eduard_Munteanu [n=edi@79.115.194.103] has quit ["Lost terminal"]
20:40 <@penberg_home> so
20:40 <@penberg_home> how is it going
20:41 < ahuillet> penberg_home : well, as I told vegard, my friend and I went to the pub tonight
20:41 <@penberg_home> :)
20:41 < ahuillet> so for now it's mostly about getting some salmon with tomato and cream ready, and watch a movie ;)
20:41 <@penberg_home> heh heh
20:41 <@penberg_home> but I see you figured out something?
20:42 <@penberg_home> vegard: did the tracing thing get resolved?
20:42 < ahuillet> yeah, for now we reload registers *before* moving stack slots
20:42 < ahuillet> so for example when we have to move slot 1 to slot 3 (because of control flow stuff), we reload the interval from slot 3 before doing the mov
20:43 < ahuillet> i'll try to fix that tomorrow but it's never as easy as you intend
20:43 < ahuillet> that's what I learnt with register allocation
20:43 < ahuillet> with a bit of luck once this is done we get println
20:44 <@penberg_home> :)
20:51 <@penberg_home> on a related note
20:51 <@penberg_home> looking at the coverage table
20:51 <@penberg_home> the only things we're missing are switch statements and doubles on 32-bit
20:51 <@penberg_home> that's pretty damn impressive
20:53 < ahuillet> switch = annoying
20:54 < ahuillet> because the CFG ends up with more than two children for a block
20:57 <@penberg_home> hmm
20:58 <@penberg_home> AFAICT, we can convert that to a bunch of STMT_IFs
20:59 < ahuillet> yes, but it's suboptimal when we can use a jump table
21:00 <@penberg_home> well
21:01 <@penberg_home> gcc doesn't seem to use jump tables for -Os
23:06 -!- penberg_home [n=penberg@cs149038.pp.htv.fi] has quit []
--- Log closed Wed Jul 22 00:00:22 2009