--- Log opened Thu Aug 06 00:00:22 2009
00:11 -!- penberg_ [n=penberg@cs146249.pp.htv.fi] has joined #jato
00:24 -!- penberg [n=penberg@cs146249.pp.htv.fi] has quit [Read error: 110 (Connection timed out)]
08:20 -!- penberg_ [n=penberg@cs146249.pp.htv.fi] has quit ["Changing server"]
08:20 -!- penberg [n=penberg@cs146249.pp.htv.fi] has joined #jato
08:22 < penberg> things like these bring tears to my eyes:
08:22 < penberg> penberg@penberg-laptop:~/testing/jato$ jato Hello
08:22 < penberg> vm/jni-interface.c:459: warning: vm_jni_delete_local_ref not implemented
08:22 < penberg> hello, world
08:22 < penberg> vm/jni-interface.c:459: warning: vm_jni_delete_local_ref not implemented
08:22 < penberg> vm/jni-interface.c:459: warning: vm_jni_delete_local_ref not implemented
08:22 < penberg> ahuillet: we need to fix the regalloc bug!!! :)
08:22 < penberg> S.o.println() waits on the other side.
08:24 < penberg> 4 years and 5 developers later we can (almost) print "hello, world!"
08:24 < penberg> quite an amazing accomplishment :)
08:39 < ahuillet> :)
08:39 < ahuillet> I'll read the backlog once I'm at work
08:39 < ahuillet> and will see what I can do today though I have some stuff to carry out
08:39 < ahuillet> meeting that will probably give me more work :)
08:42 < penberg_home> :)
08:43 < penberg_home> http://student.agh.edu.pl/~tgrabiec/0001-jit-make-XMM0-XMM7-callers-saved-registers.patch
08:43 < penberg_home> latest master + this patch = infinite loop.
08:43 < penberg_home> with S.o.println()
08:47 < penberg> haha
08:47 < penberg> without tomek's xmm patch
08:47 < penberg> the test program prints "h"
08:47 < penberg> :-)
09:58 -!- tgrabiec [n=tomekg@cdw218.neoplus.adsl.tpnet.pl] has joined #jato
09:59 < tgrabiec> hi
10:00 < ahuillet> hey :
10:00 < ahuillet> *!
10:03 < penberg_home> hi!
10:09 < tgrabiec> penberg_home: how can I reproduce that SIGSEGV with <unknown>s?
10:16 < penberg_home> tgrabiec: I ran HelloWorldSwing
10:18 < vegard> hi
10:22 < penberg_home> hi!
10:25 -!- vegard [n=vegard@luke.ifi.uio.no] has quit [Read error: 110 (Connection timed out)]
10:25 < tgrabiec> penberg_home: workse here: http://pastebin.com/d2ed647c6
10:25 < penberg_home> tgrabiec: curious.
10:25 < penberg_home> I wonder what goes wrong.
10:52 -!- penberg [n=penberg@cs146249.pp.htv.fi] has quit [Read error: 110 (Connection timed out)]
10:54 < penberg_home> ok so jato is 1421 days old
10:54 < penberg_home> or 3 years, 10 months, 22 days
10:54 < penberg_home> well little older than that
10:54 < penberg_home> but that's from the first commit.
11:22 -!- vegard [n=vegard@luke.ifi.uio.no] has joined #jato
11:24 < penberg_home> vegard: yo!
11:24 < vegard> hi
11:24 < penberg_home> vegard: now I am trying to turn perf into a memory profiler also!
11:25 < vegard> I saw.
11:25 < penberg_home> :-)
11:25 < penberg_home> vegard: did you try hello world already?
11:26 < vegard> it crashed with the same sigsegv 0 as you
11:27 < penberg_home> it's fixed now.
11:28 < vegard> heh
11:28 < vegard> it printed "H"
11:28 < penberg_home> yeah
11:28 < penberg_home> you need the xmm workaround
11:29 < vegard> takes 2.764s though
11:29 < vegard> hotspot is 1.572s
11:29 < penberg_home> yes
11:29 < tgrabiec> vegard: I'm wondering how much time could be saved if we used hash table in classloader
11:30 < penberg_home> oh
11:30 < penberg_home> guys!
11:30 < penberg_home> I already explained why it's slow!
11:30 < vegard> hehe
11:30 < penberg_home> 70% of time is spent in liveness analysis!
11:30 < vegard> tgrabiec: yes. in natives too
11:30 < penberg_home> _70%_
11:30 < vegard> penberg_home: did libzip disappear from the profiles completely?
11:30 < penberg_home> 2.7 * 0.3 = 0.81
11:31 < penberg_home> so there's a good chance we'll _beat_ hotspot
11:31 < penberg_home> if someone bothers do tomek's suggested lir pos mapping patch!
11:31 < penberg_home> grr
11:31 < penberg_home> hashmaps in classloader my ass!
11:31 < penberg_home> :)
11:31 < vegard> well, I think if nobody else does it, you will
11:31 < penberg_home> true.
11:32 < penberg_home> I am merging the xmm workaround now
11:32 < penberg_home> and adding a ticket on lighthouse.
11:32 < vegard> you really want 0.1, don't you?
11:32 < penberg_home> well
11:32 < penberg_home> I am beginning to think we should do 100% bytecode coverage
11:32 < penberg_home> and a rudimentary gc for 0.1
11:32 < penberg_home> I just hate bugs, that's all.
11:34 < vegard> release early, release often
11:37 < penberg_home> without a gc?
11:37 < penberg_home> I have mixed feelings
11:37 < penberg_home> what do you guys think?
11:38 < penberg_home> the thing is
11:38 < ahuillet> GCs are for wimps
11:38 < penberg_home> I think we can get 100% coverage in few weeks probably.
11:38 < ahuillet> real men manage their memory by hand
11:38 < penberg_home> ahuillet: heh heh
11:38 < penberg_home> and I do think a rudimentary gc that uses malloc() and free() for the _allocation_ part
11:38 < penberg_home> is quite doable too.
11:39 < vegard> so, new branch?
11:40 < penberg_home> branch?
11:40 < vegard> penberg/jato/gc
11:40 < vegard> so that we can start submitting patches
11:40 < penberg_home> hmm?
11:40 < penberg_home> we don't need a branch for that!
11:41 < penberg_home> tgrabiec, ahuillet: http://jato.lighthouseapp.com/projects/29055/tickets/5-sse-registers-are-saved-and-registered-unconditionally#ticket-5-1
11:41 < vegard> well, we do, I think, if more than 1 person wants to work on it
11:41 < penberg_home> hmm?
11:41 < vegard> it's not going to work straight out of the box?
11:41 < penberg_home> lets merge to master.
11:41 < penberg_home> vegard: hey, you just _disable_ it by default
11:41 < penberg_home> and add a -Xgc
11:41 < penberg_home> as simple as that.
11:41 < penberg_home> yes, I am a genious!
11:41 < penberg_home> I know, you can thank me later.
11:42 < penberg_home> It just doesn't make any sense to branch, really.
11:42 < vegard> it prints Hello world... amazing.
11:42 < penberg_home> any gc patches are an improvement!
11:42 < penberg_home> and besides
11:42 < penberg_home> it's not as if you do free() any time soon anyway
11:42 < penberg_home> first you add safepoints
11:42 < penberg_home> then gc maps
11:42 < penberg_home> and only at the very last step do you do free()
11:42 < penberg_home> safepoints and gc maps are totally non-invasive patches anyway
11:43 < vegard> 19286 methods invoked for SOP(Hello world)
11:44 < penberg_home> that's just crazy!
11:44 < tgrabiec> penberg_home: I'm currently on double support, I think it'll be ready by evening
11:44 < penberg_home> tgrabiec: oh, nice!
11:48 < vegard> it feels really weird to see the S.o.p
11:48 < vegard> working
11:50 < penberg_home> tgrabiec: ahuillet and I were thinking of doing a "use single precision for doubles" thing for see1 class machines.
11:50 < penberg_home> and make a lighthouse ticket on it ;)
11:50 < penberg_home> http://www.laughingpanda.org/~penberg/cpuid.c
11:51 < penberg_home> just in case someone wants to do the cpu_has_sse2 thingy.
11:51 < tgrabiec> penberg_home: thanks for cpuid.
11:51 < penberg_home> that's tested code too btw ;)
11:51 < tgrabiec> do you know how hotspot handles machines withou SSE2 ?
11:52 < tgrabiec> can't we do the emulate_ thing ?
11:52 < tgrabiec> like we already do
11:52 < penberg_home> oh sure
11:52 < penberg_home> that's an even better idea!
11:52 < penberg_home> lets do that instead!
11:57 < penberg_home> tgrabiec: what are the JNI warnings about for S.o.println() btw?
11:58 < tgrabiec> penberg_home: vm_jni_delete_local_ref() - that does nothing currently, because we have no GC
11:58 < tgrabiec> it should notify GC that given reference is no longer used
11:58 < penberg_home> ok, lets remove the warning please?
11:59 < vegard> hm
11:59 < vegard> if insn_array is used _only_ for getting the first and last insns
11:59 < vegard> why don't we just add a ->first and ->last?
11:59 < tgrabiec> penberg_home: ok, you can do it, and add lighthous ticket
12:00 < penberg_home> vegard: splitting
12:00 < vegard> we don't split after liveness analysis, do we?
12:01 < tgrabiec> vegard: we can split in regalloc
12:01 < vegard> oh.
12:01 < vegard> split interval == split basic_block ?
12:02 < penberg_home> no
12:02 < penberg_home> intervals can span multiple basic blocks
12:06 < vegard> do we want per-cu or per-bb mapping of lir-pos -> insn ?
12:08 < penberg_home> cu
12:15 < vegard> penberg_home: btw, I think we shouldn't do the fixed register initialization in compilation_unit_alloc()
12:15 < vegard> it adds some unnecessary overhead, we don't need it until the cu is compiled
12:30 < vegard> penberg_home: I did the patch :D
12:30 < vegard> it WAS straightforward
12:31 < vegard> http://pastebin.com/m6f7cdf81
12:31 < vegard> that's the profile minus jit functions
12:31 < vegard> hehe
12:31 < vegard> and time went down to 0m0.721s !!!
12:32 < vegard> http://folk.uio.no/vegardno/lir_insn_map.patch
12:33 < vegard> it needs to be cleaned up, but I've gotta go
12:37 < tgrabiec> wow !
15:52 < ahuillet> I'm still fighting autotools
15:52 < ahuillet> oh no, that's actually done, I now am fighting mercurial
15:52 < ahuillet> what a piece of shit it seems to be... :)
16:03 -!- t_grabiec [n=tomekg@avu182.neoplus.adsl.tpnet.pl] has joined #jato
16:05 -!- tgrabiec [n=tomekg@cdw218.neoplus.adsl.tpnet.pl] has quit [Read error: 110 (Connection timed out)]
16:10 < vegard> does x86 unit tests fail in mainline?
16:10 < vegard> *do
16:33 < vegard> penberg_home: I'm waiting for your new perf report, by the way
16:42 < vegard> insert_to_list() in linear-scan.c seems to be the next bottleneck ;)
16:42 < ahuillet> :)
16:42 < ahuillet> we're gonna need all those optimizations for the optimizer at some point anyway
16:43 < ahuillet> which is going to be much heavier than linear scan btw
16:43 < ahuillet> because it will scan several times
16:47 < vegard> which optimizations?
16:48 < ahuillet> we'll talk later, gotta catch my train back home
16:58 < vegard> me too, bye :)
17:48 < ahuillet> I screwed up big time at Bull today
17:48 < ahuillet> pushed something onto the internal mercurial repository
17:48 < ahuillet> in the main branch, but I wasn't supposed to
17:48 < ahuillet> I did not know that, still I got whipped a little bit
17:49 < ahuillet> and I'm not sure I suceeded in fixing it
18:08 < ahuillet> so, make test fails on my machine with latest mainline
18:08 < ahuillet> normal?
18:37 < vegard> it does here too
19:11 < ahuillet> so, how can I reproduce the XMM problems?
19:32 < vegard> revert the save-all-regs patch
19:33 < vegard> it's this one: 5345bc374c82ad1fe8e7949168f406a2876abbee
19:33 < vegard> and then you need to apply a patch from tomek on the mailing list
19:34 < vegard> I think it's this one: [DO-NOT-MERGE][PATCH] make xmm0-xmm7 caller saved
19:40 < vegard> you probably want to write a small test case first
19:55 < vegard> "x86: explicitly save and restore XMM registers in prolog/epilog"
19:55 < vegard> <-- this is what broke "make test"
20:14 < t_grabiec> vegard, ahuillet : here is the newer patch - http://student.agh.edu.pl/~tgrabiec/0001-jit-make-XMM0-XMM7-callers-saved-registers.patch
20:15 < t_grabiec> here's the test case: http://pastebin.com/dae4044e
20:18 < t_grabiec> uhm, yes the make test is broken, I didn't think Pekka will finally merge this patch so I didn't bother to fight with unit tests
20:43 < t_grabiec> penberg_home: do you want double support with SSE2 patches, or want to wait for support for double emulation?
20:57 < penberg_home> yes
20:57 < penberg_home> t_grabiec: I actually thought I had fixed the tests ;)
20:58 < penberg_home> and didn't notice the breakage (oops)
20:59 < t_grabiec> I sent the fix
21:00 < t_grabiec> penberg_home: so how about double support? will you merge SSE2 without emulation support?
21:00 < penberg_home> t_grabiec: yes, ship it in!
21:02 < penberg_home> vegard: and btw, thanks for the optimization!
21:02 < penberg_home> we still lose to hotspot though
21:02 < penberg_home> it needs 20 msec (!) to run hello world
21:02 < penberg_home> we use 500 msec.
21:02 < vegard> oh
21:02 < vegard> but "time" shows much less?
21:03 < ahuillet> time isn't precise at this level
21:04 < penberg_home> I'm talking about "time" on my machine.
21:05 < penberg_home> ahuillet: what do you mean?
21:05 < penberg_home> I'm referring to "user time"
21:05 < penberg_home> but
21:05 < penberg_home> we're using too much memory too
21:05 < ahuillet> penberg_home : you can't measure 20ms with time
21:05 < penberg_home> so kernel page allocator shows up in the performance traces.
21:05 < penberg_home> ahuillet: why?
21:05 < penberg_home> 20 ms is _a lot_
21:05 < vegard> for me, jato is faster than hotspot in time {jato|java} HelloWorld.
21:05 < penberg_home> vegard: is it?
21:05 < ahuillet> well, 20ms you can, 2ms you can't, sorry
21:06 < penberg_home> yeah, I'd assume that too
21:06 < penberg_home> the closer you get to 1 msec mark, the less precise it's going to be.
21:06 < ahuillet> submillisecond works not so badly with gettimeofday() up to some level, after that you need HPET
21:07 < ahuillet> though I always did rdtsc instead of other things
21:07 < ahuillet> because on my CPU it's usable :)
21:08 < penberg_home> ahuillet: so, we're going to add sse2 now
21:08 < ahuillet> great
21:08 < penberg_home> then we're going to do if !cpu_has_sse2 revert to emulate_
21:08 < penberg_home> for doubles
21:09 < penberg_home> so everything will work properly on your sse1 machine too real soon now (tm) ;)
21:09 < penberg_home> ahuillet: did you have the chance to look at the register allocator problem?
21:09 < ahuillet> no, with my screwing up at Bull today I got late on my planning and had no time for jato
21:09 < penberg_home> ahuillet: and oh, allocate_registers() is now the hottest function for "hello, world"
21:09 < ahuillet> same for tomorrow
21:09 < penberg_home> at 17% or something ;)
21:10 < penberg_home> ahuillet: k
21:10 < ahuillet> penberg_home : I'm not surprised, it's pretty normal
21:10 < penberg_home> ahuillet: I went ahead and merged tomek's workaround
21:10 < penberg_home> until we get register allocator issues sorted out
21:10 < penberg_home> ahuillet: true
21:10 < penberg_home> but I think we should look into optimizing too
21:10 < penberg_home> maybe there are low hanging fruits there?
21:10 < ahuillet> not so sure, we'll need detailed profiling
21:10 < ahuillet> (line numbers)
21:11 < penberg_home> there's "perf annotate" that should be able to do that actually
21:11 < ahuillet> I do not think there is much we can do though
21:11 < penberg_home> I have never used it though.
21:11 < penberg_home> try to reduce the number of temporaries, probably
21:11 < penberg_home> in the front-end.
21:11 < t_grabiec> penberg_home: we have 3143 classloader requests for hello world
21:11 < penberg_home> :)
21:12 < penberg_home> t_grabiec: none of that shows up in the performance profile though.
21:12 < penberg_home> it's basically register allocator + kernel (!) page allocator at the top now ;)
21:12 < penberg_home> so we need to fix our memory consumption problems
21:12 < ahuillet> <penberg_home> try to reduce the number of temporaries, probably
21:12 < penberg_home> other than that, I don't think we should optimize other parts yet.
21:12 < ahuillet> most of the stuff will be around reducing the size of the data set indeed
21:13 < penberg_home> yup.
21:13 < penberg_home> that said, there can be some simple tricks
21:13 < penberg_home> that benefit the register allocator
21:14 < penberg_home> (I just spent the last 8 hours trying to squeeze an opengl program into 4K so maybe I'm biased)
21:15 < penberg_home> and oh
21:15 < penberg_home> we need to have a serious discussion on v0.0.1
21:15 < ahuillet> let's have a serious discussion then
21:15 < penberg_home> I always wanted to run tetris for v0.01 ;)
21:16 < penberg_home> what are your expectations for v0.01?
21:16 < ahuillet> S.o.println
21:16 < penberg_home> GC: yes ( ), no ( )
21:16 < ahuillet> I don't really have expectations regarding Java features, you know ;)
21:16 < penberg_home> ahuillet: you don't want to run tetris?-)
21:16 < ahuillet> I would not expect a GC to be necessary though
21:16 < ahuillet> people need to be able to run simple programs
21:16 < penberg_home> 100% of the instruction set?
21:16 < ahuillet> so they see Jato is a serious project
21:17 < penberg_home> that probably means we need GC
21:17 < penberg_home> if you want to run a long lived app
21:17 < ahuillet> 100% of the insn set isn't a purpose in itself methinks, but we need enough of the insn set that we can run simple programs
21:17 < penberg_home> ahuillet: well
21:17 < penberg_home> the point is
21:17 < penberg_home> we're missing (1) doubles, (2) 64-bit arrays, and (2) lookupswitch or tableswitch I forgot which
21:17 < penberg_home> vegard, t_grabiec: feel free to chip in!
21:17 < ahuillet> 2) doesn't matter
21:17 < ahuillet> 1) doesn't really
21:18 < t_grabiec> penberg_home: we're missing lookupswitch
21:18 < vegard> I'm scared of GC
21:18 < vegard> but
21:18 < vegard> I bet we could make it work before monday.
21:19 < t_grabiec> I think we have some bugs, I have full double support and I get assertions failing for HelloWorldSwing
21:19 < t_grabiec> I think 100% instruction set is doable within a week at most
21:19 < penberg_home> oh
21:19 < penberg_home> vegard: :)
21:20 < t_grabiec> vegard: what do you mean by "work" ?
21:20 < vegard> work. gc.
21:21 < vegard> well. AT LEAST for a single thread.
21:22 < t_grabiec> well, maybe
21:23 < penberg_home> oh
21:23 < penberg_home> that's not a problem
21:23 < penberg_home> I already wrote multithreaded safepoints
21:23 < penberg_home> t_grabiec, vegard: http://www.laughingpanda.org/~penberg/jato/safepoints
21:24 < t_grabiec> oh, and our patching code is not MP safe, that should be fixed somehow
21:24 < penberg_home> gc maps are the more interesting one AFAICT.
21:24 < penberg_home> t_grabiec: we can fix that with safepoints!
21:24 < t_grabiec> penberg_home: but I don't mean XMC errata here, our patching code is not _atomic_
21:24 < penberg_home> t_grabiec: http://jato.lighthouseapp.com/projects/29055/tickets/2-lack-of-icache-invalidation-on-code-cross-modyfication#ticket-2-3
21:25 < penberg_home> t_grabiec: that doesn't matter if we add a serializing insn
21:26 < t_grabiec> hmm, right
21:30 < ahuillet> penberg_home : I think it's a bug in Wimmer's algorithm we have
21:30 < ahuillet> Wimmer sets block_pos of active fixed intervals to 0
21:31 < penberg_home> ahuillet: yeah?
21:32 < ahuillet> but I don't understand his block_pos thing
21:32 < penberg_home> you know what
21:32 < ahuillet> he seems to use it to ensure that fixed intervals are always kept in registers
21:32 < penberg_home> me neither!
21:32 < ahuillet> (never spilled)
21:32 < penberg_home> aha
21:32 < ahuillet> but that's not the definition of fixed intervals
21:32 < ahuillet> (not even his definition)
21:32 < penberg_home> hmh
21:32 < ahuillet> what do you think?
21:32 < penberg_home> check out the paper?
21:32 < penberg_home> if the algorithm is different there?
21:33 < ahuillet> grmbl I don't have it on the harddrive
21:33 < ahuillet> you got the link?
21:33 < ahuillet> got it
21:33 < ahuillet> http://www.christianwimmer.at/Publications/Wimmer05a/
21:33 < ahuillet> there is no occurence of "allocate_blocked" in this PDF
21:34 < ahuillet>   For each physical register, one fixed interval stores where
21:34 < ahuillet> the register is not available for allocation. Use positions
21:34 < ahuillet> are not needed for fixed intervals because they are never
21:34 < ahuillet> split and spilled.
21:34 < ahuillet> so he kind of smoked the carpet if you ask me
21:34 < ahuillet> (the quote is from the paper)
21:34 < ahuillet> FWIW his definition works for one reason
21:34 < ahuillet> I'll guess you which one
21:34 < ahuillet> answer: his liveness analysis is "perfect", ie. the live ranges computed are the smallest possible ranges
21:35 < ahuillet> our ranges are too large
21:35 < ahuillet> so two solutions here
21:35 < ahuillet> we can make liveness analysis more precise, or throw away Wimmer's property for fixed intervals that they are never spilled
21:35 < ahuillet> this same problem is what is holding us back on both XMM registers and callee saved registers
21:36 < ahuillet> penberg_home : so what are you thoughts?
21:36 < penberg_home> ahuillet: are you sure our ranges are too large?
21:36 < ahuillet> definitely
21:36 < penberg_home> the use-def things fixed a lot!
21:36 < ahuillet> they're bound to basic blocks
21:36 < penberg_home> oh, true.
21:36 < penberg_home> hmm
21:36 < ahuillet> Wimmer's have instruction granularity
21:36 < ahuillet> we have bb granularity
21:37 < penberg_home> I'm fine with either way, really.
21:37 < ahuillet> since Wimmer's assumption is properly stupid in my opinion
21:37 < penberg_home> more precise liveness analysis seems more risky somehow
21:37 < ahuillet> I want to make block_pos do something sensible
21:37 < penberg_home> yes
21:37 < ahuillet> ie. be tied to use positions (which we compute for fixed intervals AFAIK)
21:37 < ahuillet> instead of being tied to beginning of live range
21:38 < penberg_home> IIRC we do.
21:38 < ahuillet> this should fix it, mostly, and will enable both XMM stuff and callee saved GPRs
21:38 < penberg_home> yup
21:38 < penberg_home> two issues with one patch?
21:38 < penberg_home> ;)
21:38 < ahuillet> then we can see about more precise liveness analysis, see if it is a perf. improvement or not
21:38 < penberg_home> that would be awesome!
21:38 < ahuillet> because it's *far* from obvious
21:38 < penberg_home> agreed.
21:41 < ahuillet> soooooo
21:41 < ahuillet> let me give a shot to fixed register assumption sanitization
21:42 < ahuillet> so all intervals in "active" already have a register allocated, right?
21:44 < penberg_home> yes
21:45 < ahuillet> so I'm trying to remove block_pos completely
21:45 < ahuillet> but it's complicated because of the logic at the end I don't quite get
21:47 < ahuillet> I believe one of the three cases goes away
21:47 < ahuillet> but can't quite convince myself of it
21:51 < ahuillet> I'm gonna go for a variant of the algorithm in the paper
21:51 < ahuillet> the one in the thesis sucks
21:56 < vegard> so, um
21:56 < vegard> penberg_home: can you tell again what steps were needed for gc?
21:56 < penberg_home> vegard: sure.
21:56 < penberg_home> safepoints + gc maps
21:56 < penberg_home> the point here is that
21:56 < penberg_home> we need to suspend everything (safepoints)
21:57 < penberg_home> then figure out the root set (gc maps)
21:57 < penberg_home> then do a mark + sweep thingy
21:57 < ahuillet> vegard : wait
21:57 < ahuillet> vegard : are you in any position to try a regalloc patch for the XMM thing?
21:57 < penberg_home> and free() objects that are not used
21:57 < vegard> ahuillet: oh, sure
21:57 < vegard> penberg_home: ok. you look into safepoints, I look into gc maps?
21:57 < ahuillet> let me check it builds first
21:57 < ahuillet> and passes regression tests
21:58 < penberg_home> vegard: http://www.laughingpanda.org/~penberg/jato/safepoints
21:58 < penberg_home> it needs little bit loving
21:58 < ahuillet> massive SIGSEGVs! :)
21:58 < vegard> heh
21:58 < penberg_home> vegard: I'm doing my tax declarations now, sorry :)
21:58 < penberg_home> need to do them by tomorrow!
21:59 < vegard> sure
22:01 < ahuillet> [main] [     ? ]  0x97cf664c:   83 c4 20                   add    $0x20,%esp
22:01 < ahuillet> that [main] thing wastes screen space
22:03 < ahuillet> mmmh, we have much better liveness analysis now it seem
22:03 < ahuillet> *seems
22:03 < ahuillet> penberg_home : we seem to have insn granularity now
22:03 < ahuillet> don't ask me why
22:05 < ahuillet> http://paste.pocoo.org/show/132925/
22:06 < ahuillet> I'd appreciate some help understanding what's wrong with this patch
22:06 < ahuillet> I don't understand the trace output
22:10 < ahuillet> ok, got it
22:10 < ahuillet> I know what's w rong
22:11 < ahuillet> split_interval_at does not properly set fixed_reg
22:13 < ahuillet> http://paste.pocoo.org/show/132927/
22:13 < ahuillet> updated patch
22:13 < ahuillet> still not working but better
22:15 < ahuillet> I'd *love* some help figuring out what goes wrong
22:15 < ahuillet> the "init half a hundred classes" thing makes it difficult to see what really happens.
22:17 < vegard> patch bomb from tomek ;)
22:18 < ahuillet> thanks for the warning
22:18 < ahuillet> I almost had time to disable comsat :)
22:18 < t_grabiec> shall I warn you ? :)
22:19 < penberg_home> ahuillet: does that fix it?
22:19 < penberg_home> ahuillet: yeah it does, but we need it to identify the thread anyway
22:19 < ahuillet> penberg_home : it does not fix it
22:20 < ahuillet> tests break for some reason I can't figure out
22:20 < penberg_home> hmm
22:20 < penberg_home> yeah
22:20 < penberg_home> so a fixed reg needs the same fixed reg
22:20 < penberg_home> right
22:20 < penberg_home> you're awful quiet in the changelog ;)
22:21 < penberg_home> k, so patch bomb
22:21 < ahuillet> t_grabiec
22:21 < ahuillet> -	select_insn(s, tree, reg_membase_insn(INSN_MOV_XMM_MEMBASE, state->left->reg1, esp, -8));
22:21 < ahuillet> -	select_insn(s, tree, reg_membase_insn(INSN_MOV_XMM_MEMBASE, state->right->reg1, esp, -4));
22:21 < ahuillet>  	select_insn(s, tree, imm_reg_insn(INSN_SUB_IMM_REG, 8, esp));
22:21 < ahuillet> +	select_insn(s, tree, reg_membase_insn(INSN_MOV_XMM_MEMBASE, state->left->reg1, esp, 0));
22:21 < ahuillet> +	select_insn(s, tree, reg_membase_insn(INSN_MOV_XMM_MEMBASE, state->right->reg1, esp, 4));
22:21 < ahuillet> why?
22:22 < ahuillet> none is incorrect, but I don't believe your version is any clearer.
22:22 < t_grabiec> ahuillet: Pekka says that it's better to first reserve the space, then modify
22:22 < ahuillet> substracting something from %esp does not reserve any space
22:22 < t_grabiec> doesn't it ?
22:22 < ahuillet> not by itself no
22:23 < ahuillet> that said I agree that your version will shut up programs like valgrind who might complain
22:24 < t_grabiec> penberg_home: any opinion?
22:24 < vegard> I prefer the SUB first
22:24 < penberg_home> is there a call before that or something?
22:24 < penberg_home> ahuillet: well
22:24 < penberg_home> with things like valgrind
22:25 < penberg_home> the stack portion can be marked as "uninitialized" AFAICT
22:25 < ahuillet> writing there should be allowed, still
22:25 < ahuillet> if valgrind complains about it it will be a "program MIGHT be doing something incorrect"
22:25 < ahuillet> not "program DEFINITELY did something fishy"
22:25 < ahuillet> because it's not incorrect to write above top of the stack :)
22:25 < vegard> but what difference does it make to us?
22:25 < ahuillet> vegard : pretty much none
22:26 < vegard> why not just pick the one that works with valgrind? :P
22:26 < ahuillet> I'm just reading a 30kB patch
22:26 < ahuillet> having convenience modifications mixed with actual useful modifications makes it longer to read, that's all
22:26 < ahuillet> I'm giving up at half of patch5
22:28 < penberg_home> vegard, t_grabiec: ahuillet has a point there
22:28 < penberg_home> mixing cleanups and functional changes can be a pain
22:28 < penberg_home> to read.
22:28 < ahuillet> ok, so Acked-By: me for the whole x86: series except patch 5
22:28 < ahuillet> which I simply haven't finished ready
22:28 < ahuillet> same for the whole jit: patches except patch 19 I'm not qualified to comment on
22:28 < ahuillet> vm: patches are out of my league
22:29 < ahuillet> t_grabiec : thanks for all that, must have taken you quite a bit of time
22:29 < t_grabiec> thanks for appreciaction!
22:30 < penberg_home> 15/19 looks pretty suspicious
22:30 < ahuillet> quick look at the end of patch 5 makes me say it looks good
22:30 < t_grabiec> penberg_home: why ?
22:30 < penberg_home> look at the patch
22:30 < penberg_home> then look at the subject line
22:30 < penberg_home> hmm?
22:30 < ahuillet> yeah 15 looks strange
22:30 < ahuillet> the changes don't seem to be too related to the subject :)
22:30 < t_grabiec> oops
22:30 < ahuillet> ok it's time to go to bed
22:31 < ahuillet> I'll try to find some time for regalloc tomorrow
22:31 < ahuillet> this is my latest version http://paste.pocoo.org/show/R8S9X0KyhtgN8hF9FsB7/
22:31 < ahuillet> you need to apply the patch I sent to the ML too
22:31 < penberg_home> t_grabiec: can you resend that?
22:31 < penberg_home> and I'll merge.
22:31 < penberg_home> ahuillet: I'll do that.
22:31 < t_grabiec> penberg_home: you can squash it to the rpevious
22:31 < ahuillet> if you can understand what went wrong and investigate a bit, that would be nice as I'm kinda lost
22:31 < penberg_home> t_grabiec: 14?
22:31 < penberg_home> sure.
22:31 < ahuillet> penberg_home : btw look how my WIP patch looks nice
22:31 < t_grabiec> yup
22:31 < ahuillet>  1 file changed, 3 insertions(+), 51 deletions(-)
22:32 < penberg_home> ahuillet: :) yes!
22:32 < penberg_home> too bad it doesn't work yet
22:32 < penberg_home> heh heh
22:32 < ahuillet> paper vs. thesis. :)
22:32 < ahuillet> anyway good night guys
22:32 < penberg_home> good night!
22:32 < t_grabiec> good night!
22:32 < penberg_home> t_grabiec: http://jatovm.sourceforge.net/bytecode-coverage.html
22:32 < penberg_home> so help me out here a little bit
22:32 < penberg_home> which ones did you do now :)
22:32 < t_grabiec> so..
22:33 < t_grabiec> why is fstore not green?
22:33 < penberg_home> mistake?
22:33 < t_grabiec> I thought it worked
22:33 < penberg_home> probably just forgot it?
22:34 < t_grabiec> penberg_home: so, you should mark green all _but_ : f2l, d2l, l2f, l2d, lookupswitch
22:34 < penberg_home> 64-bit arrays too?
22:34 < penberg_home> is there a regression test for it?
22:35 < t_grabiec> oh, no no
22:35 < penberg_home> k
22:36 < vegard> what's a 64-bit array?
22:36 < t_grabiec> lastore, dastore
22:36 < t_grabiec> laload, daload
22:36 < penberg_home> hmm
22:36 < penberg_home> -	vm_jni_get_static_double_field,
22:36 < penberg_home> +	NULL, /* GetStaticDoubleField */
22:36 < penberg_home> are you sure that's correct?
22:36 < penberg_home> I am squashing
22:36 < t_grabiec> penberg_home: yup, look at the patch 16
22:36 < penberg_home> but I think there could be a bug there
22:37 < penberg_home> aha
22:37 < penberg_home> ok
22:37 < t_grabiec> I just messed up patch splitting
22:37 < t_grabiec> oh well, happens
22:37 < penberg_home> yup
22:39 < penberg_home> fastore too?
22:39 < penberg_home> float arrays work?
22:39 < penberg_home> I don't see a regression test for those
22:39 < t_grabiec> hmm, it should work
22:39 < t_grabiec> I can try to add some regression test
22:40 < penberg_home> 94%
22:40 < penberg_home> t_grabiec: yes please.
22:41 < penberg_home> ok
22:41 < penberg_home> http://jatovm.sourceforge.net/bytecode-coverage.html
22:41 < penberg_home> time for me to get some sleep!
22:41 < penberg_home> see ya tomorrow!
22:42 < t_grabiec> see ya!
22:42 < vegard> whoa
22:42 < vegard> 94% !!!
22:42 < vegard> well done!
22:44 < t_grabiec> fastore, faload also work
22:48 < vegard> dcmpl ?
22:49 < t_grabiec> I think it works too, if fcmpl does
22:51 < vegard> yeah, they're just a variant of each other
23:25 < t_grabiec> this fails with jato: http://pastebin.com/d663237ca
23:26 < t_grabiec> fails to JIT compile I mean
23:27 < vegard> what does it do?
23:27 < t_grabiec> vegard: I don't know, some buffering stuff. I encountered it in HelloWorldSwing
23:28 < t_grabiec> looks like he tries to reload an interval, and interval->spill_parent->spill_slot == NULL
23:35 < t_grabiec> This is more sane test case: http://pastebin.com/d3075f165
23:35 < vegard> interesting :)
23:36 < t_grabiec> jato: arch/x86/emit-code.c:561: __encode_reg: Assertion `!"unassigned register in code emission"' failed.
23:36 < t_grabiec> this is interesting
23:36 < t_grabiec> more regalloc bugs?
23:38 < t_grabiec> simplified: http://pastebin.com/d20b3a2fb
23:41 < vegard> I'm guessing you could simplify it even more
23:42 < t_grabiec> yup
23:46 < t_grabiec> http://pastebin.com/d417024b8
23:46 < t_grabiec> I can't simplify it more
23:46 < vegard> hehe
23:46 < vegard> that's good enough!
--- Log closed Fri Aug 07 00:00:22 2009