--- Log opened Mon Aug 10 00:00:22 2009
00:51 -!- tgrabiec [n=tomekg@abkx62.neoplus.adsl.tpnet.pl] has quit [Remote closed the connection]
08:15 < penberg_home> ahuillet, vegard: BTW, I was reading my UNIX kernel book last night
08:15 < penberg_home> and I realized that our "write past ESP" code is broken.
08:15 < penberg_home> if we cross a page boundary and there's no physical page
08:16 < penberg_home> the kernel will check whether we're above ESP or not
08:16 < penberg_home> and if we're not, we'll SIGSEGV or SIGBUS
08:16 < ahuillet> it's implemented like this?
08:17 < ahuillet> so the kernel checks for the value of %esp before allocating a new page?
08:17 < penberg_home> I did not check Linux yet
08:17 < penberg_home> but it makes perfect sense
08:17 < ahuillet> yes....
08:18 < penberg_home> otherwise you'd need to allocate pages at random pages in the sbrk too
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:20 -!- penberg_ is now known as penberg
08:21 < ahuillet> so it's push we have to use
08:22 < penberg_home> I think we should allocate a scratch stack slot
08:22 < penberg_home> instead
08:22 < penberg_home> that's what gcc does
08:23 < ahuillet> mmh yes that's the best
08:23 < ahuillet> "non temporal stack slot" :]
08:23 < ahuillet> (I was talking with my mentor about what "non temporal" in e.g. prefetchnta actually means, we did not come up with a convincing answer)
08:24 < ahuillet> our best bet was that it was actually placed in the cache but at the top of th
08:24 < ahuillet> *the eviction lists
08:25 < penberg> ahuillet: arch/x86/mm/fault.c
08:25 < penberg> do_page_fault()
08:26 < penberg> ahuillet: http://pastebin.com/m125d1d8c
08:26 < penberg> so Linux *does* check it, but with large margin
08:26 < penberg> so our approach works with Linux
08:26 < penberg> but it's a bug all the same.
08:27 < penberg_home> ahuillet: I'd assume the opposite
08:28 < penberg_home> a non-temporal is placed at the bottom of the cache
08:28 < penberg_home> so that it's not evicted early.
08:28 < penberg_home> non-temporal = will be used for a long time
08:28 < penberg_home> ahuillet: btw, HelloWorldSwing brings up a window and doesn't crash!
08:29 < penberg_home> the label is missing but it's still impressive as hell!
08:33 < ahuillet> penberg_home : mmh no, non temporal isn't described as such by intel
08:33 < penberg_home> aah?
08:33 < ahuillet> a non temporal mov (movntpa? not sure of the name) pretty much bypasses the caches
08:33 < ahuillet> (that's why bull used it to speed up infiniband transfers)
08:34 < penberg_home> haha
08:34 < penberg_home> http://torvalds-family.blogspot.com/2009/08/programming.html
08:34 < penberg_home> ahuillet: ok, I don't know much about intel caches to be honest
08:35 < ahuillet> mmh, time to get dressed for rain bike riding
08:37 < vegard> is raining here too.
08:37 < ahuillet> no water is  falling from the sky at the moment but the road is quite wet
08:39 < ahuillet> ok, I'm off to the office
09:01 < vegard> hm
09:01 < vegard> does MEMDISP need a register?
09:02 < penberg_home> no
09:09 < vegard> comments? http://folk.uio.no/vegardno/0001-x86-add-support-for-INSN_TEST_IMM_MEMDISP.patch
09:15 -!- tgrabiec [n=tomekg@abkx62.neoplus.adsl.tpnet.pl] has joined #jato
09:25 < penberg_home> vegard: /* XXX: Supports only byte or long imms */
09:25 < penberg_home> heh, AFAICT, the instruction set only supports that.
09:25 < vegard> jumps between basic blocks -- where do they come from?
09:25 < vegard> penberg_home: no, by using REX prefix we get 64-bit version and with 0x66 prefix we get 16-bit version
09:25 < penberg_home> aha
09:26 < penberg_home> I think we can drop the XXX in any case
09:26 < penberg_home> vegard: so this if for the safepoint guard page?
09:26 < vegard> yes
09:26 < penberg_home> looks ok to me
09:26 < vegard> ok!
09:26 < penberg> jumps hmm
09:27 < penberg> I don't remember :)
09:27 < vegard> there's a emit_insn(buf, NULL, jump_insn(bb->successors[i])); in jit/emit.c
09:28 < penberg> that's emit_resolution_blocks()
09:28 < vegard> yes. it sounds somehow wrong.
09:29 < penberg> well, it's bit of a mess for sure.
09:30 < tgrabiec> vegard: why wrong ?
09:30 < vegard> tgrabiec: wrong for my purposes :)
09:30 < penberg> tgrabiec: did the patches fix HelloWorldSwing for you?
09:30 < penberg> tgrabiec: I'm missing the label still.
09:31 < tgrabiec> penberg: no
09:31 < tgrabiec> me too
09:31 < tgrabiec> I'm on track of a bug
09:31 < tgrabiec> seems like vtable thing
09:31 < penberg> oh?
09:31 < tgrabiec> I'm not 100% sure  yet
09:31 < penberg> Bug everywhere! Just the way we like it, eh?-)
09:31 < penberg> tgrabiec: btw, jEdit installer dies of NPE :-)
09:31 < penberg> wrong compilation probably
09:32 < tgrabiec> we're so crashing everywhere :)
09:32 < tgrabiec> vegard: you want to insert safepoints right ?
09:32 < vegard> tgrabiec: yes :)
09:32 < penberg> next up: azureus
09:32 < vegard> tgrabiec: I could of course just go with the easy temporary solution and emit them only at the beginning of each function
09:33 < penberg> tgrabiec: http://pastebin.com/m14a6dda1 :-)
09:33 < penberg> vegard: safepoints?
09:33 < penberg> safepoints _before_ every CALL
09:33 < penberg> and in the beginning of each loop
09:33 < vegard> penberg: I said temporary :-P
09:33 < penberg> hmm
09:33 < tgrabiec> penberg: or after call, and before backward branch ?
09:34 < penberg> tgrabiec: I don't remember, check the paper :)
09:34 < penberg> function prolog makes sense, though.
09:34 < penberg> OTOH, it won't work for natives...
09:35 < tgrabiec> probably we want to insert safepoints on enter_vm_from_jni() too
09:35 < penberg> oh, true
09:35 < penberg> but won't work for _vm natives_ :-)
09:36 < tgrabiec> true
09:36 < penberg> OTOH, we _can_ add poll_safepoint() type of thing in those?
09:37 < penberg> tgrabiec: http://www-jpc.physics.ox.ac.uk/download_download.html
09:37 < penberg> :)
09:38 < penberg> mono_burg_emit: EXPR_CONVERSION: no conversion from 6 to 2
09:38 < penberg> disappointing :-)
09:44 < vegard> hm
09:44 < vegard> is there an %eiz register??
09:45 < vegard> 0xe7f7e500:   f6 04 25 00 80 86 08 00    testb  $0x0,0x8868000(,%eiz,1)
09:45 < vegard> heh
09:45 < ahuillet> vegard : not a hardware one no
09:45 < vegard> is that zero ?
09:45 < ahuillet> yes it is
09:45 < vegard> heh, right. weird!
09:45 < ahuillet> that's for a disp32 IIRC
09:45 < ahuillet> the intel manuals do NOT list this as eiz
09:46 < penberg_home> holy crap!
09:46 < ahuillet> but "as" & friends use it
09:46 < penberg_home> never seen that before.
09:46 < vegard> anyway, it works :D
09:46 < ahuillet> I can help you find the line in the modrm+sib tables if you're stuck ;)
09:46 < ahuillet> I love GNU as syntax for x86
09:46 < ahuillet> except for that shit
09:46 < ahuillet> because it doesn't match anything in the intel doc
09:47 < penberg_home> yeah
09:47 < penberg_home> there's few insn mnemonics too that don
09:48 < penberg_home> 't match
09:48 < ahuillet> %eiz, seriously.. :)
09:48 < vegard> hm. so when gc kicks in, we need to walk the stack too, right?
09:49 < vegard> so that's why it has to be in front of every call
09:49 < penberg_home> vegard: yes.
09:49 < vegard> otherwise we don't know what the registers/stack slots are in use for callers
09:49 < penberg_home> don't look at me
09:49 < penberg_home> I don't know the stack walking code
09:49  * penberg_home looks at tgrabiec
09:49 < penberg_home> ;)
09:50 < ahuillet> GCs suck!
09:50 < vegard> ahuillet: I couldn't agree more.
09:50 < penberg_home> You just don't know what you're talking about :-)
09:50 < ahuillet> come on penberg_home
09:51 < vegard> GC seems really fragile, with lots of downsides, and there's still plenty of potential (for the "end"-programmer) to mess up his code
09:52 < penberg_home> heh heh
09:52 < ahuillet> and it makes people poor coders by teaching them that memory is not of the concern of the programmer.
09:53 < penberg_home> I have one word for you guys: "fragmentation"
09:53 < ahuillet> penberg_home : fragmentation of ?
09:53 < penberg_home> memory
09:53 < penberg_home> and the "plenty of potential to mess up his code" is not an argument against GCs at all.
09:54 < penberg_home> The only problem with GCs is that you can still leak memory
09:54 < penberg_home> but use after free, double free, etc. are not an issue
09:54 -!- tgrabiec [n=tomekg@abkx62.neoplus.adsl.tpnet.pl] has quit [Read error: 110 (Connection timed out)]
09:54 -!- tgrabiec [n=tomekg@amm242.neoplus.adsl.tpnet.pl] has joined #jato
09:55 < penberg_home> and oh, sure latency is a problem for GCs
09:55 < ahuillet> I don't know.. for high level applications I can see the point
09:55 < ahuillet> (of not bothering with memory management)
09:55 < ahuillet> anything that is even remotely performance critical however I'm much less certain about
09:55 < ahuillet> and that does include any application I use. :]
09:55 < penberg_home> ahuillet: depends on your application
09:55 < vegard> because of its unpredictability?
09:56 < penberg_home> there are soft realtime gcs out there
09:56 < ahuillet> but I guess it's more of an argument against VMs than against GCs
09:56 < penberg_home> but if you hate GCs so much
09:56 < penberg_home> I guess you're going to love escape analysis
09:56 < penberg_home> and turning heap allocations to stack allocations
09:56 < penberg_home> if we can prove that a reference never escapes a method.
09:57 < ahuillet> I mean I don't really care why most Java programs are so slow and eat so much memory, it's just a fact I don't like whatever the cause is :)
09:57 < penberg_home> ahuillet: which apps are you talking about?
09:57 < penberg_home> hotspot generates pretty damn tight asm
09:57 < ahuillet> penberg_home : azureus comes to mind
09:57 < penberg_home> ahuillet: never tried that.
09:58 < ahuillet> that's the only java application I use on a regular basis
09:58 < penberg_home> ahuillet: swing + friends are dog slow
09:58 < ahuillet> eclipse is a funny beast, too
09:58 < penberg_home> but AFAICT, that's not a _java_ problem
09:58 < penberg_home> ahuillet: eclipse is slow to start up
09:58 < ahuillet> penberg_home : maybe in a perfect world java would be good
09:58 < penberg_home> OTOH, Eclipse has gotten more and more bloated over the years.
09:58 < ahuillet> but when even the best JIT+VM implementations run java programs slowly..
09:59 < penberg_home> ahuillet: again, AFAICT, it's the _native_ parts of swing that suck
09:59 < vegard> oh, well, at least they're portably slow!
09:59 < penberg_home> vegard: :)
10:00 < ahuillet> :)
10:00 < penberg_home> in any case, I'm pretty excited about our upcoming GC
10:00 < penberg_home> I've written a few malloc() implementations
10:00 < penberg_home> so it's going to be interesting to see what we can do with GC
10:02 < penberg> ahuillet: http://www-jpc.physics.ox.ac.uk/home_home.html
10:02 < penberg> running that is going to be really interesting!
10:05 < penberg> haha, running doom at a slow frame rate with CPU capped to 100% :-)
10:06 < tgrabiec> ok, it is definitely vtable bug
10:12 < penberg> http://pastebin.com/m3760c8f6
10:12 < penberg> http://www.codealchemists.com/jdarkroom/
10:12 < penberg> OK, I'm off! See ya in few hours.
10:20 < ahuillet> guys, did you know that printf("%s\n", aezrazr) was replaced by puts(aezrazr) by gcc?
10:20 < ahuillet> even in -O0
10:20 < ahuillet> gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3
10:27 < vegard> ahuillet: yes
10:27 < vegard> it's annoying
10:28 < ahuillet> -fno-builtin-printf if you want to kill it
10:28 < vegard> because printf "%p\n" (which would print "(null)" with printf) now crashes with NULL dereference
10:28 < vegard> oh wait
10:28 < vegard> no, it's still %s
10:28 < vegard> but if the argument is NULL
10:28 < vegard> so printf("%s\n", NULL); crashes because of the puts conversion
10:29 < ahuillet> yeah, but the spec doesn't guarantee it
10:29 < vegard> yes, true.
10:29 < ahuillet> so you should not rely on the (null) thing ;)
10:31 < vegard> penberg_home: afaics, your safepoint() is buggy()
10:34 < vegard> ah, hm.
10:38 < tgrabiec> our fixup_vtable() is broken
10:39 < tgrabiec> we should not fixup vtable on invokespecial calls
10:39 < vegard> do you know what's wrong and how to fix it? :)
10:39 < tgrabiec> and invokesuper
10:39 < tgrabiec> because we might put the pointer to superclass's method to our vtable
10:40 < tgrabiec> and invokevirtual will be broken next time we try invokevirtual
10:40 < tgrabiec> hmm
10:40 < tgrabiec> but I don't know how to fix it
10:40 < vegard> I guess constructors should not be part of vtable ?
10:41 < tgrabiec> they can
10:44 < tgrabiec> here is the bastard: http://pastebin.com/d15b07591
10:44 < vegard> hm
10:45 < tgrabiec> our fiup vtable is so wrong
10:45 < tgrabiec> I wrote it
10:47 < vegard> :)
10:48 < tgrabiec> vegard: I fixed it
10:48 < vegard> haha. well done :D
10:48 < tgrabiec> better, check if S.o.p still works
10:49 < tgrabiec> S.o.p() works after fix
10:49 < tgrabiec> but HelloWorldSwing complains it needs getDeclaredMethods()
10:53 < vegard> http://pastebin.com/m6b0b23ce
10:53 < vegard> any ideas? :)
10:54 < tgrabiec> regallocbug ? ;)
10:54 < ahuillet> !!!!
10:55 < tgrabiec> sorry for that
10:55 < tgrabiec> vegard: works here !
10:55 < vegard> ah. maybe I should rebase, then
10:56 < tgrabiec> well, almost
10:56 < tgrabiec> it doesn't crash, but it prints only "end"
10:56 < vegard> hm
10:56 < vegard> nope, here the same thing happens with latest mainline
10:57 < tgrabiec> it looks like the main thread doesn't wait for other threads
10:57 < tgrabiec> I'll check with clean mainline
10:59 < tgrabiec> it's the same
10:59 < tgrabiec> prints "end" and exits
10:59 < vegard> hm.
10:59 < tgrabiec> oh, I got the exception finally !
11:00 < tgrabiec> it's some race condition most probably
11:01 < tgrabiec> these are fun to debug :)
11:02 < vegard> ehe.
11:03 < vegard> I'm thinking that System.out initialization is racing
11:03 < vegard> or, well, System class initialization, perhaps
11:03 < vegard> this is based on nothing but speculation and gut feelings
11:03 < tgrabiec> it is possible
11:04 < tgrabiec> class initialization should be secured, but you double check
11:04 < vegard> I think the problem is that we say "we're initializing now" at the beginning of class init
11:04 < vegard> and then the "is initialized" check only checks whether "we're initiailizing OR we're initialized"
11:05 < vegard> or maybe you changed all that ;)
11:05 < tgrabiec> vegard: I implemented the algorithm described in JVM spec
11:06 < tgrabiec> vegard: do you have multicore ?
11:06 < vegard> yes, NR_CPUS = 2
11:07 < tgrabiec> it is possible we fall into the issue, that we do not handle java memory model properly, that is, we are missing memory fences
11:07 < tgrabiec> but that would be exposed only in unsynchronized access
11:07 < vegard> those races are fairly small afaik
11:07 < tgrabiec> yup
11:07 < vegard> but it's a possibility yes
11:14 < vegard> penberg_home: your safepoints.c is buggy
11:19 < vegard> because pthread_cond_wait() may wake up (and return) spuriously
11:44 < vegard> tgrabiec: the ->classloader stuff isn't 100% done yet
11:44 < vegard> afaics
11:44 < tgrabiec> no it isn't
11:45 < vegard> I actually had some partial patches for this too :)
11:45 < vegard> but I couldn't figure out how to deal with the [VM]Classloader classes
11:45 < tgrabiec> aha
11:45 < tgrabiec> I implemented just as much as was necessary to make HelloWorldSwing run
11:46 < vegard> afaics we only ever set ->classloader to NULL now, right?
11:46 < tgrabiec> right
12:07 < vegard> tgrabiec: now I get only the "end" printout too :)
12:07 < vegard> and I can't reproduce the NPE anymore.. .weird :)
12:07 < tgrabiec> what did you do
12:07 < vegard> nothing that affects run-time
12:08 < vegard> I added some more code, but it is unused
12:09 < vegard> make clean all jato regression test
12:09 < tgrabiec> races are very valatile
12:10 < vegard> yeah. it could even be the fact that I was playing music before and not anymore
12:10 < vegard> or something silly like this.
12:59 -!- t_grabiec [n=tomekg@app71.neoplus.adsl.tpnet.pl] has joined #jato
13:01 -!- tgrabiec [n=tomekg@amm242.neoplus.adsl.tpnet.pl] has quit [Read error: 110 (Connection timed out)]
13:44 < penberg_home> vegard: how did you fix safepoints?
13:44 < vegard> loop on an extra value
13:52 < vegard> emitting gc safepoints now :D
13:52 < vegard> and generating a rough sort of gc map
13:52 < vegard> it's not complete, by far
13:54 < penberg_home> :)
14:01 < penberg> t_grabiec:
14:01 < penberg> jit-test-runner: ../../jit/expression.c:586: null_check_expr: Assertion `ref->vm_type == J_REFERENCE' failed.
14:01 < penberg> make[1]: *** [run] Aborted
14:01 < penberg> make[1]: Leaving directory `/home/penberg/src/jato/test/jit'
14:01 < penberg> make: *** [test] Error 2
14:01 < penberg> t_grabiec: can I have fix for this?
14:01 < t_grabiec> penberg: my pre-last patch fixes it
14:01 < penberg> ok
14:02 < t_grabiec> oh
14:02 < t_grabiec> you have to do make clean
14:02 < penberg> t_grabiec: which patch is that?
14:02 < t_grabiec> I thought it is broken make test
14:02 < t_grabiec> try make clean
14:02 < penberg_home> t_grabiec: doesn't help
14:03 < t_grabiec> which patches did you merge so far ?
14:03 < penberg> t_grabiec: all
14:03 < t_grabiec> weird
14:04 < penberg> t_grabiec: first series ok
14:05 < penberg> toplevel/vm/types.o: In function `count_arguments':
14:05 < penberg> /home/penberg/src/jato/test/vm/../../vm/types.c:73: undefined reference to `parse_method_args'
14:05 < penberg> collect2: ld returned 1 exit status
14:05 < penberg> make[1]: *** [vm-test-runner] Error 1
14:05 < penberg> make[1]: Leaving directory `/home/penberg/src/jato/test/vm'
14:05 < penberg> second series
14:07 < penberg> I'll merge the first series
14:07 < penberg> then move on to vegard's patches.
14:12 < penberg> t_grabiec: ping
14:13 < penberg> t_grabiec: can you please fix up the series? I'm reviewing vegard's patches here and would love to merge your stuff too
14:13 < penberg> I merged the first series
14:13 < penberg> t_grabiec: which fixes the vtable thing
14:15 < penberg> vegard: git format-patch -M
14:15 < penberg> for renames
14:15 < penberg> or moves
14:16 < vegard> ah, sorry, forgot (or: didn't realize I had one)
14:16 < penberg> vegard, t_grabiec: why is exception guard page hidden by default?
14:16 < vegard> because it used to be. my change is a no-op in terms of functionality.
14:17 < penberg> vegard: so does 8/8 have the loop fix in it?
14:17 < vegard> yes
14:17 < penberg> ok cool
14:17 < vegard> +       while (!can_continue)
14:17 < vegard> +               pthread_cond_wait(&can_continue_cond, &safepoint_mutex);
14:17 < penberg> vegard: I think I actually saw those bugs on SMP
14:18 < penberg> why do we get spurious wakeups though?
14:19 < penberg> OK, tomek is gone, I guess I'll try to fix his patchset
14:19 < vegard> I don't know the technical reason
14:19 < penberg> vegard: I'm pushing your GC stuff now
14:19 < penberg> excellent work!
14:19 < penberg> toplevel/arch/x86/insn-selector.o: In function `select_safepoint':
14:19 < penberg> /home/penberg/src/jato/test/arch-x86/../../arch/x86/insn-selector.c:671: undefined reference to `gc_safepoint_page'
14:19 < penberg> mhmh
14:19 < vegard> ah
14:19 < vegard> add void *gc_safepoint_page; to test/vm/gc-stub.c
14:20 < penberg> ok
14:20 < penberg> which patch adds that?
14:20 -!- tmgrabiec [n=tomekg@akw250.neoplus.adsl.tpnet.pl] has joined #jato
14:21 -!- t_grabiec [n=tomekg@app71.neoplus.adsl.tpnet.pl] has quit [Read error: 110 (Connection timed out)]
14:21 < vegard>     vm: count the number of threads for GC
14:21 < vegard> no
14:21 < vegard> hm.
14:21 < vegard> either that one or
14:21 < vegard> x86: select gc safepoints before function calls
14:22 < penberg>     x86: select gc safepoints before function calls
14:22 < penberg> ok!
14:22 < penberg> tmgrabiec: I guess you lost internet connection?
14:22 < penberg> tmgrabiec: I merged your first patch set. Care you fix up the others? Or send incremental patches?
14:22 < penberg> I'd love to merge and push them too
14:22 < tmgrabiec> penberg: what's wrong with them, do not apply?
14:22 < penberg> breaks make test
14:23 < tmgrabiec> penberg: I've just send a patch to fix that
14:23 < tmgrabiec> [PATCH] test: fix 'make test' breakage
14:26 < penberg_home> tmgrabiec: ok cool
14:26 < penberg_home> which patch should I squeeze that into?
14:27 < tmgrabiec> penberg_home: I think  "[PATCH 4/6] vm: use parse_method_args() in count_arguments()"
14:27 < penberg> ok
14:27 < tmgrabiec> probably something earlier
14:27 < tmgrabiec> this:	[PATCH 2/6] vm: introduce vm_method_java_argument_count()
14:28 < penberg> will fix!
14:28 < tmgrabiec> thanks !
14:29 < penberg> toplevel/vm/types.o: In function `count_arguments':
14:29 < penberg> /home/penberg/src/jato/test/vm/../../vm/types.c:73: undefined reference to `parse_method_args'
14:29 < penberg> collect2: ld returned 1 exit status
14:29 < penberg> make[1]: *** [vm-test-runner] Error 1
14:29 < tmgrabiec> gosh, what a mess
14:29 < penberg> yup
14:29 < penberg> I'll let you sort it out :-)
14:29 < penberg> please resend
14:30 < tmgrabiec> ok
14:30 < penberg> tmgrabiec: the first series in in master
14:30 < penberg> and pushed
14:30 < tmgrabiec> k
14:49 < vegard> penberg: are we going to keep around the liveness/var info after compiling the method?
14:50 < vegard> I guess we need a way to map the bitset index to machine register/stack slot in the GC
14:53 < penberg> vegard: nope.
14:54 < penberg> vegard: we should keep all that in compact gc maps
14:54 < vegard> so how do you want to do it? :D
14:54 < vegard> the lower NR_MACHINE_REGS map to machine registers and the rest map to stack slots?
14:55 < penberg> vegard: no idea! (sorry bit busy atm)
14:55 < vegard> but not all stack slots have reference type either
15:08 < vegard> struct live_range uses lir positions ?
15:20 -!- tmgrabiec [n=tomekg@akw250.neoplus.adsl.tpnet.pl] has quit [Read error: 110 (Connection timed out)]
15:20 -!- tmgrabiec [n=tomekg@avv102.neoplus.adsl.tpnet.pl] has joined #jato
15:22 < penberg> vegard: merged and pushed.
15:29 < vegard> so I'm not entirely sure how to get the right stack slot
15:30 < vegard> I think we might have to check whether the variable is _before or after_ the interval
15:31 < vegard> and we should only mark the stack slot "in use" if the safepoint instruction is _after_ the interval and it is marked spill ?
15:31 < vegard> or is it more magical than this?
15:34 < vegard> I should ask ahuillet if he comes back.
15:34 < ahuillet> mmh?
15:35 < vegard> aha
15:36 < vegard> I want, for a particular instruction, which variables that are in use at that point, and where their values are (in machine register or stack slot, if so, which ones)
15:36 < vegard> my first attempt is in print_gc_map() in jit/trace-jit.c :)
15:38 < ahuillet> I'm sorry I need to work for my employer right now
15:38 < ahuillet> I'll see what I can do later
15:38 < vegard> ok ok :)
15:47 < penberg_home> vegard: did you need my help with something?
15:47 < penberg_home> sorry I was bit busy
15:55 < vegard> oh, I don't know
15:55 < vegard> if you can answer the question above.. :)
15:56 < penberg_home> vegard: yes.
15:56 < penberg_home> vegard: as long as the spill store is there.
15:57 < penberg_home> before the safepoint poll
15:57 < penberg_home> vegard: local variables are easy
15:57 < penberg_home> we always keep them in stack slots.
15:57 < penberg_home> (note: you can get duplicate references because some are in registers _and_ in stack slots)
16:01 < vegard> so, um
16:01 < vegard> you'll do the patch?
16:01 < penberg_home> no :)
16:01 < vegard> oh.
16:01 < penberg_home> I'm resting my wrist.
16:02 < penberg_home> it hurts like hell
16:02 < vegard> there is just one range per vreg, no?
16:02 < vegard> sorry, one interval
16:03 < penberg> hmm, it's not that simple.
16:03 < penberg> there can be multiple intervals
16:03 < penberg> because an interval can be split to child intervals.
16:04 < penberg> see ->next_child and ->prev_child in struct live_interval
16:05 -!- t_grabiec [n=tomekg@ale243.neoplus.adsl.tpnet.pl] has joined #jato
16:05 -!- tmgrabiec [n=tomekg@avv102.neoplus.adsl.tpnet.pl] has quit [Read error: 110 (Connection timed out)]
16:15 < vegard> ugh, I knew there had to be something like this ;)
16:18 < vegard> and can those be split as well?
16:21 < penberg_home> yes
16:21 < penberg_home> AFAICT, yes.
16:49 < t_grabiec> penberg_home: bomb incoming
16:50 < penberg_home> :)
16:50 < t_grabiec> it adds lots of reflection stuff and LONG array load/store
16:50 < t_grabiec> HelloWorldSwing blocks on conversion_to_float 5 to 8
16:51 < penberg> t_grabiec: long to double, right?
16:52 < t_grabiec> right
16:52 < t_grabiec> I'm taking a break now
16:54 < penberg_home> (merging)
17:07 < penberg> http://pastebin.com/m4e355f91
17:08 < penberg> l2d
17:08 < penberg> wth is it doing...
17:12 < vegard> lol :-P
17:14 < penberg>   13:   f2 0f 59 0d 00 00 00    mulsd  0x0,%xmm1
17:14 < penberg>   1b:   f2 0f 58 05 08 00 00    addsd  0x8,%xmm0
17:14 < penberg> I don't understand these at all!
17:17 < penberg> http://pastebin.com/m7064bba7
17:17 < penberg> hmh
17:22 < vegard> what's wrong?
17:23 < penberg> vegard: well, what are they doing?
17:23 < penberg>  mulsd  0x0,%xmm1
17:24 < penberg> it takes xmm reg or mem operand!
17:24 < penberg> and multiply by zero doesn't make _any_ sense.
17:24 < vegard> boog in lir-printer?
17:24 < penberg> that's _gcc_
17:24 < vegard> ah :-p
17:27 < penberg> ahuillet: heelp!
17:27 -!- t_grabiec [n=tomekg@ale243.neoplus.adsl.tpnet.pl] has quit [Read error: 104 (Connection reset by peer)]
17:28 -!- tgrabiec [n=tomekg@ale243.neoplus.adsl.tpnet.pl] has joined #jato
17:30 < penberg> vegard: ok, so it's a memory location
17:30 < penberg> and if I like the sucker, I get better values
17:30 < penberg> WTH is it doing!?
17:33 < penberg_home> s/like/link/g
17:36 < penberg_home> The book states that to master your work, you need 10,000 hours of practice, and it's after those 10,000 hours of practice that this people made their greatest works. Bill Gates wrote windows after having 10,000, and Bill Joy wrote Berkley unix after having 10,000 hours of programming.
17:36 < penberg_home> http://robertoyudice.com/thoughts/10000-hours-to-master-programming/
17:36 < penberg_home> LOL
17:36 < penberg_home> Bill Gates wrote Windows?
17:38 < vegard> =.o ?
17:59 < penberg_home> tgrabiec: the long -> double thing seems really crazy
18:00 < penberg> tgrabiec: +       if (BITS_PER_LONG == 32) {
18:01 < penberg> We use CONFIG_32_BIT for these
18:01 < penberg> but I'll merge the patch anyway
--- Log closed Mon Aug 10 18:11:49 2009
--- Log opened Mon Aug 10 18:12:00 2009
18:12 -!- jato-irc-logger [n=vegard@cm-84.209.125.101.getinternet.no] has joined #jato
18:12 -!- Irssi: #jato: Total of 5 nicks [0 ops, 0 halfops, 0 voices, 5 normal]
18:12 < penberg> tgrabiec: not really, I'm stuck :)
18:12 -!- Irssi: Join to #jato was synced in 5 secs
18:12 < penberg> tgrabiec: I was looking at what GCC does and I don't understand it.
18:13 < penberg> tgrabiec: http://pastebin.com/me4bd593
18:13 < penberg> crazy!
18:13 -!- vegard [n=vegard@luke.ifi.uio.no] has joined #jato
18:14 < penberg> vegard: J_NATIVE_PTR vs. vm_pointer_type()
18:14 < penberg> vegard: thoughts?
18:16 < vegard> what does vm_pointer_type() return ?
18:16 < penberg> J_INT or J_LONG
18:16 < penberg> depending on arch
18:17 < penberg> vegard, tgrabiec: one option is to make J_NATIVE_PTR a #define
18:17 < tgrabiec> I'm ok with that
18:17 < penberg> vegard: ?
18:18 < tgrabiec> penberg: this is what I get, seems sane : http://pastebin.com/d4d21763e
18:19 < penberg_home> tgrabiec:
18:19 < penberg_home>  80483e3:       f2 0f 59 0d 00 85 04    mulsd  0x8048500,%xmm1
18:19 < penberg_home>  80483eb:       f2 0f 58 05 08 85 04    addsd  0x8048508,%xmm0
18:19 < penberg_home> if you can explain what the hell those two are :)
18:20 < tgrabiec> penberg_home: I think that the first is * 0x80000000f
18:21 < tgrabiec> the second should be the same, hmm
18:21 < vegard> hm, right. I think a #define is probably the right thing to do
18:24 < tgrabiec> penberg_home: hmm, I don't understand it too
18:27 < tgrabiec> penberg_home: http://software.intel.com/en-us/forums/intel-avx-and-cpu-instructions/topic/59114/
18:30 < tgrabiec> penberg_home: in "mulsd  0x8048500,%xmm1"0x8048500 is not a value but a memory location
18:31 < penberg_home> yes!
18:31 < penberg_home> Let me have a look at the link you sent
18:32 < penberg_home> we have signed longs.
18:35 < penberg_home> http://software.intel.com/en-us/articles/fast-floating-point-to-integer-conversions/
18:35 < penberg_home> not what we want to do but anyway
18:35 < tgrabiec> penberg_home: the first mul is by 0x100000000, the addition is with 0x80000000
18:36 < tgrabiec> makes sense
18:36 < tgrabiec> makes perfect sense
18:36 < penberg_home> tgrabiec: http://paste.pocoo.org/show/133485/
18:36 < penberg_home> (related to writes past ESP)
18:36 < penberg_home> tgrabiec: and they're in MEM because SSE insn set is crap?-)
18:37 < penberg_home> tgrabiec: so we just make two globals and use them here?
18:37 < tgrabiec> yup
18:37 < tgrabiec> there is no mulsd imm,reg
18:37 < penberg_home> what about imm -> reg ?
18:37 < tgrabiec> I don;t know
18:37 < penberg_home> the memory load scares the crap out of me.
18:38 < tgrabiec> I'm almost sure there is no mov with imm to XMM reg
18:39 < penberg_home> lets see what happens with SSE3...
18:39 < penberg> same crap
18:40 < penberg> hmm even -O2 uses the mem load
18:40 < penberg> maybe that really is the best se can do here?
18:41 < penberg> gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12)
18:44 < penberg_home> I wonder what icc does.
18:47 < vegard> is it free?
18:47 < vegard> I noticed that we have it at uni.
18:47 < penberg_home> free as in beer.
18:48 < vegard> costs money ?
18:49 < penberg> :)
18:49 < vegard> icc (ICC) 11.0 20090131
18:49 < penberg> can you try the conversion?
18:49 < vegard> which code?
18:49 < penberg> just a sec
18:50 < vegard> btw, there's a difference between SSE3 and SSSE3
18:50 < penberg> vegard: http://pastebin.com/m4a6cc893
18:50 < vegard> I can generate SSE4 code too if you want :-P
18:50 < penberg> vegard: SSE2 level, please.
18:51 < penberg> well, if you want, SSE2 and up.
18:51 < penberg> but SSE2 is the most interesting one
18:51 < penberg> reg params too if ICC can do that
18:51 < penberg> (so we have long long in eax/edx)
18:51 < penberg> SSE instruction set seems to love memory loads...
18:53 < vegard> hm
18:53 < vegard> it looks a bit crazy
18:53 < penberg_home> :)
18:54 < penberg_home> x86 is crazy
18:54 < vegard> which one do you want?
18:54 < penberg_home> SSE2
18:54 < vegard> no
18:54 < vegard> which function
18:54 < penberg_home> all of them
18:55 < vegard> hm
18:55 < vegard> -xSSE2 not supported, but -xSSE3 is
18:55 < penberg_home> aha?
18:55 < penberg_home> lets see SSE3 then?
18:56 < vegard> heh
18:56 < vegard> I think it optimized it a bit too agressively
18:56 < vegard> http://pastebin.com/m225f525d
18:56 < penberg_home> 64-bit
18:56 < vegard> ah
18:56 < penberg_home> nice to see it's better there :)
18:56 < penberg_home> 64-bit on 32-bit is pure crap!
18:58 < vegard> Internal error: check_target_config: targ_size_t_max is too large
18:58 < vegard> :-/
18:58 < penberg_home> :)
18:58 < penberg_home> well, I don't have sse3 anywa
18:58 < penberg_home> y
18:59 < vegard> :-/
18:59 < vegard> no, this is with -m32 and sse2
18:59 < vegard> apparently the error is unrelated to what I give it as input
18:59 < vegard> (c source)
19:00 < vegard> I guess ICC just really sucks, then.
19:00 -!- tgrabiec [n=tomekg@ale243.neoplus.adsl.tpnet.pl] has quit ["Leaving"]
19:01 < penberg> vegard: :)
19:03 < penberg> so we need INSN_FMUL_64_MEMDISP_REG and INSN_FADD_64_MEMDISP_REG
19:04 < vegard> http://pastebin.com/m31483744
19:04 < penberg> 64-bit :)
19:04 < vegard> sure
19:04 < vegard> we don't have those instructions on 32-bit ?
19:04 < penberg> probably.
19:05 < penberg> SSE2 anyway
19:05 < vegard> it works for me
19:07 < penberg_home> 32-bit?
19:07 < vegard> http://pastebin.com/m6dcb321d
19:08 < penberg_home> vegard: edi?
19:08 < penberg_home> l2d can't be right, can it?
19:08 < vegard> because of 32-bit reg?
19:08 < penberg> just one, yes
19:08 < vegard> I have no idea.
19:09 < vegard> I just changed %r -> %e and *q -> *l :-)
19:09 < vegard> the main point is that it compiles ;)
19:09 < penberg> hmmm, vegard! :)
19:10 < penberg> CVTSI2SD--Convert Dword Integer to Scalar Double-Precision FP Value
19:10 < vegard> cvtsi2sd in intel manual...
19:10 < penberg> 32-bit -> double
19:12 < penberg> CVTDQ2PD hmm
19:14 < vegard> what's "packed"?
19:14 < penberg_home> dunno
19:15 < vegard> I think my manual has a typo.
19:15 < vegard> in the "Instruction" column it says xmm2/m64
19:15 < vegard> in the "Description" column it says "xmm2/m128"
19:15 < penberg_home> can we abuse mmx too?
19:15 < penberg_home> move quadword integer from MMX to XMM registers
19:16 < vegard> why do you want to avoid the memory so badly ;)
19:16 < vegard> it stays in cache only, and if it's the stack it will be hot cache anyway
19:17 < penberg> Oh, it's just fucking ugly, that's why :-)
19:17 < penberg> we can go for it.
19:17 < penberg> I just have hard time believing it's the best we can do.
19:18 < vegard> all the fp is fugly
19:18 < vegard> fp stuff
19:18 < vegard> everything's just been hack upon hack since the start
19:18 < penberg> :-)
19:18 < vegard> and I don't mean in jato, I mean on the cpu vendors' side
19:18 < penberg> that's x86
19:19 < penberg> I'm gonna switch to PPC soon.
19:19 < penberg> I was reading the ppc manual today on the bus.
19:19 < penberg> slightly cleaner isa.
19:19 < penberg> hmm
19:19 < vegard> that can't be hard ;)
19:25 < ahuillet> cleaner ISA, but much more expensive implementations...
19:25 < penberg> Expensive, how?
19:26 < ahuillet> PPC CPUs are expensive to
19:26 < ahuillet> *+buy
19:26 < penberg> sure, because Intel is able to bring the price down because of volumes.
19:36 < penberg> the conversion code is a freaking mess
19:49 < penberg> ok, works but produces wrong results :)
19:50 < vegard> hey
19:50 < vegard> what happnd to our release?
19:50 < penberg> vegard: whaddya mean?
19:50 < penberg> vegard: http://pastebin.com/m4daee97d
19:50 < penberg> can you spot the bug?
19:50 < vegard> is it happening todau? :D
19:51 < penberg> nope.
19:51 < penberg> So, can you see the bug? I can't :(
19:52 < penberg> vegard: how do you compile just one method?
19:56 < vegard> -Xtrace:method java/lang/system.method(Lsignature;)V
19:56 < vegard> it will be the last one in the trace
19:56 < vegard> we need to load some stuff for threading
19:56 < penberg> I guess the magic values are wrong!
20:13 < penberg> fixed!
20:17 < penberg> mono_burg_emit: EXPR_CONVERSION_FROM_DOUBLE: no conversion from 8 to 5
20:17 < penberg> blah
20:18 < penberg> l2d done!
20:19 < penberg> d2l needs to be done next!
20:24 < penberg_home> vegard: bare minimum for v0.01 is 100% coverage on 32-bit
20:24 < penberg_home> it's just silly to release something that has _four_ bytecodes missing!
20:26 < vegard> ;-)
20:26 < vegard> yes. and gc is a bit further away than I thought :)
20:26 < penberg_home> vegard: :)
20:26 < vegard> (but we have at least some of the ground work done)
20:26 < penberg_home> vegard: not a v0.01 merge blocker IMHO
20:26 < penberg_home> but I think the conversion code needs bit more work
20:26 < penberg_home> I don't think we cover all the cases
20:26 < penberg_home> and its ugly.
20:26 < vegard> :)
20:28 -!- tgrabiec [n=tomekg@apj75.neoplus.adsl.tpnet.pl] has joined #jato
20:28 < penberg_home> tgrabiec: l2d done!
20:28 < vegard> setup_max_cpus
20:28 < tgrabiec> great!
20:28 < vegard> oops.
20:28 < penberg_home> tgrabiec: your suggeste magic numbers were wrong.
20:29 < penberg_home> check the commit for details.
20:29 < penberg_home> it's black magic to me...
20:29 < tgrabiec> penberg_home: the values I gave you were double values
20:30 < tgrabiec> not int values
20:30 < penberg> oh :)
20:30 < penberg> tgrabiec: send a patch to fix that up?-)
20:31 < tgrabiec> ok, I'll send
20:31 < penberg> tgrabiec: I blame your specification :-)
20:31 < tgrabiec> penberg: sure
20:31 < penberg> tgrabiec: We need d2l next.... :)
20:33 < penberg> tgrabiec: I won't be writing more code this evening, my right hand wrist is almost destroyed :-)
20:33 < tgrabiec> too much writing ?
20:33 < penberg> heh heh, I guess so!
20:33 < penberg> tgrabiec: I should stick to merging ;)
20:33 < tgrabiec> :)
20:45 < tgrabiec> penberg: so, is it ok to use extended column number (132) in insn-selector ?
20:45 < penberg_home> whaddya mean?
20:46 < tgrabiec> penberg_home: your patch, you do not wrap lines after 80 characters
20:46 < penberg_home> aah
20:46 < penberg_home> its ok
20:46 < penberg_home> :)
20:47 < tgrabiec> good. it's sometimes impossible to get tight
20:50 < ahuillet> 80 chars is stupid. :)
20:58 < penberg_home> was never a hard limit in Jato anyway
20:59 < vegard> I like 80 chars.
20:59 < vegard> but ':set nowrap' is OK too.
21:01 < penberg_home> vegard: well, I like 80 chars in most code too
21:01 < penberg_home> insn selector, not really
21:05 < penberg_home> tgrabiec: nice
22:02 < penberg> tgrabiec: merged + pushed
22:06 < tgrabiec> penberg: d2l done
22:07 < penberg> oh cool!
22:08 < tgrabiec> oh, I resent by mistake the l2d fix patch, drop it
22:08 < tgrabiec> sorry
22:08 < penberg> yup
22:08 < penberg> I think we need to clean things up a bit in the conversion code
22:08 < penberg> I was planning to do that
22:08 < penberg> but I don't want to punish my poor wrist :)
22:08 < penberg> maybe tomorrow
22:09 < tgrabiec> :)
22:09 < tgrabiec> HelloWorldSwing runs now
22:09 < tgrabiec> but still no label
22:09 < penberg> oh?
22:10 < tgrabiec> and it doesn't complain about anything
22:10 < tgrabiec> just some warning
22:10 < penberg> classloader warnings, though.
22:10 < penberg> I'm still betting it's getResource()
22:10 < tgrabiec> will check
22:11 < tgrabiec> the -Xtrace:invoke-verbose log is like 96MB
22:11 < penberg> :-)
22:11 < penberg> tgrabiec: I think we need regexp for those!
22:11 < penberg> wow
22:11 < tgrabiec> yup, could be useful
22:11 < penberg> penberg@penberg-laptop:~/testing/jato$ ./scimark
22:11 < penberg> jato: include/vm/stack.h:21: stack_pop: Assertion `stack->nr_elements' failed.
22:11 < penberg> Aborted
22:11 < penberg> scimark!
22:11 < tgrabiec> tetris shows it too
22:12 < tgrabiec> mimic stack resolution error ?
22:12 < penberg> or just a conversion error.
22:13 < tgrabiec> [main]  [<0806ba0b>] native     : pc_map_get_max_lesser_than+28
22:13 < tgrabiec> that would be subroutin einlining
22:13 < penberg> http://pastebin.com/m2667fd6
22:13 < penberg> probably argument handling bug :)
22:13 < penberg> we've had plenty of those.
22:14 < penberg> laload, lastore, and f2l missing!
22:14 < tgrabiec> penberg: I implemented lastore laload today
22:14 < vegard> haha
22:14 < penberg> tgrabiec: where?!
22:14 < penberg> tgrabiec: merged?
22:14 < vegard> we have 1 missing insn!!!! :D
22:14 < tgrabiec> commit ce60a51cdd94b23beda60835523d8a2a2ed1c955
22:15 < penberg> hmm, seems like someone is paying attention when merging.....
22:15 < vegard> \o/
22:15 < vegard> penberg_home: you HAVE to implement f2l now
22:15 < penberg> vegard: no!
22:15 < penberg> it hurts too much :)
22:18 < penberg> frozen bubble: http://pastebin.com/m2b6a4d6d
22:19 < vegard> I think we should get rid of the regalloc bug before 0.1
22:19 < penberg> vegard: infinite loop?
22:19 < vegard> no
22:19 < penberg> which bug is that then?
22:20 < vegard> between the first and second (or last?) "call" instruction, e{b,c,d}x are unavailable for allocation
22:20 < vegard> you'll see it in almost any liveness analysis trace
22:20 < penberg> vegard: oh, true!
22:20 < penberg> mono_burg_emit: EXPR_CONVERSION: no conversion from 6 to 2
22:20 < penberg> hmm?
22:20 < penberg> vegard: lets make a ticket!
22:22 < tgrabiec> penberg: we do not support implicit conversions
22:24 < penberg> vegard: http://jato.lighthouseapp.com/projects/29055-jato/tickets/7-ebcdx-are-unavailable-for-allocation-after-some-call-instructions
22:24 < penberg> vegard: http://jato.lighthouseapp.com/projects/29055-jato/milestones/current
22:25 < penberg> tgrabiec: char -> byte
22:30 < penberg> vegard:
22:30 < penberg>     70.15%     jato  /home/penberg/bin/jato                   [.] gc_map_init
22:30 < penberg> you made it slow
22:30 < penberg> :-)
22:30  * penberg is off to get some sleep!
22:31 < penberg> wow
22:31 < penberg>     46.92%     jato  /tmp/perf-4437.map                       [.] jnt/scimark2/FFT.transform_internal([DI)V
22:31 < penberg>     39.37%     jato  /home/penberg/bin/jato                   [.] vm_object_check_array
22:31 < penberg>      4.14%     jato  /tmp/perf-4437.map                       [.] jnt/scimark2/FFT.bitreverse([D)V
22:31 < penberg>      3.79%     jato  /home/penberg/bin/jato                   [.] array_store_check_vmtype
22:31 < penberg>      1.58%     jato  /tmp/perf-4437.map                       [.] jnt/scimark2/FFT.inverse([D)V
22:31 < penberg> scimark!
22:31 < penberg> array checks!
22:31 < tgrabiec> penberg:  array_store_check_vmtype() is empty
22:32 < penberg_home> we need arraycheck elimination probably.
22:32 < tgrabiec> yup
22:32 < penberg_home> as soon as we get things working :-X
22:32 < penberg_home> :-D
22:33 < penberg_home> good night everyone!
22:33 < tgrabiec> good night
22:33 < vegard> good night!
22:34 -!- tgrabiec [n=tomekg@apj75.neoplus.adsl.tpnet.pl] has quit ["Leaving"]
22:37 -!- tgrabiec [n=tomekg@apj75.neoplus.adsl.tpnet.pl] has joined #jato
--- Log closed Tue Aug 11 00:00:22 2009