--- Log opened Tue Jul 28 00:00:22 2009
08:55 < vegard> hi!
08:58 < penberg_home> hi
09:12 < ahuillet> ping
09:17 < penberg_home> pong
09:19 < vegard> syn
09:19 < penberg_home> ack
09:20 < penberg_home> I learned to do matrix multiplication by hand yesterday evening!
09:20 < penberg_home> maybe I will pass my maths exams now!
09:20 < vegard> O.o
09:21 < vegard> ehm. I was going to say. weren't you supposed to learn that in your first semester? :-p
09:21 < penberg_home> maybe
09:21 < penberg_home> but I spent my time on Linux back then, I think.
09:24 < penberg_home> vegard: as a matter of fact, I am thinking of taking my "linear algebra I" in the fall
09:31 < ahuillet> penberg_home: but what's your academic level? weren't you significantly older than us?
09:32 < penberg_home> I'm 27.
09:32 < penberg_home> I would have a B Sc if I did my maths exams.
09:32 < penberg_home> so I have completed all my comp sci courses.
09:32 < penberg_home> I would have done my masters comp sci courses too
09:32 < penberg_home> but they don't let me ;)
09:33 < penberg_home> the bastards changed the rules in the middle of my studies!
09:33 < penberg_home> so now I need to _graduate_
09:33 < penberg_home> and oh, I need to do my mandatory swedish (!) exam too
09:33 < penberg_home> (finland has two official languages: finnish and swedish)
09:33 < penberg_home> the latter was a huge blocker for me
09:34 < penberg_home> but ever since I met my current gf who also speaks swedish, things are slowly improving ;)
09:34 < penberg_home> but never mind, I'm not that uncommon here, really
09:34 < penberg_home> lots of people are in similar position as I am
09:34 < penberg_home> I've been working professionally since 2002 (?)
09:34 < penberg_home> but I haven't graduated yet
09:35 < ahuillet> aha
09:35 < penberg_home> what's "significantly older" btw?
09:36 < penberg_home> because I had a funny incident with a kernel guy (christoph lameter)
09:36 < penberg_home> when I first met him at Ottawa last year
09:36 < penberg_home> he said he was expecting an older guy
09:36 < penberg_home> ;)
09:37 < ahuillet> I don't know, 27 is "significantly older"
09:37 < ahuillet> you're
09:37 < ahuillet> *30% older than I
09:37 < ahuillet> that's "significant"
09:37 < vegard> hm, only 22% older than me
09:38 < vegard> well, 23%
09:38 < penberg_home> vegard: now you know what it feels like to be old!
09:38 < ahuillet> 1.2857142857142858 here
09:38 < penberg_home> but I think christoph was expecting a 35-40 range guy
11:12 < ahuillet> #* This is not Free or Open Source software. Please contact Bull S. A. S. for
11:12 < ahuillet> #* details about its license.
11:12 < ahuillet> :)))
11:19 < penberg_home> :)
11:40 -!- tgrabiec [n=tomekg@alf225.neoplus.adsl.tpnet.pl] has joined #jato
11:41 < tgrabiec> hello there
11:43 < ahuillet> hi
11:51 < penberg_home> hello
12:14 -!- tgrabiec [n=tomekg@alf225.neoplus.adsl.tpnet.pl] has quit [Read error: 110 (Connection timed out)]
12:19 -!- tgrabiec [n=tomekg@ald174.neoplus.adsl.tpnet.pl] has joined #jato
12:32 < penberg_home> tgrabiec: why the RFC?
12:32 < penberg_home> we need to wait for eduard to comment on it?
12:32 < tgrabiec> penberg_home: yes, I was waiting for Eduard's comments, though I think it is correct
12:33 < penberg_home> ok
12:33 < penberg_home> that's cool
12:37 < tgrabiec> penberg_home: is there a C function to get the system timer with nanosecond precision (gettimeofday returns micro-) ?
12:38 < tgrabiec> if there isn't, micro precisious should be fine enough though
12:38 < penberg_home> tgrabiec: clock_gettime() I guess
12:39 < tgrabiec> penberg_home: thanks
12:40 < penberg_home> tgrabiec: http://people.redhat.com/mingo/misc/mmap-perf.c
12:40 < penberg_home> hmm
12:41 < penberg_home> it doesn't do any timer things
12:41 < penberg_home> oh well
12:41 < penberg_home> so never mind that
12:43 < penberg_home> tgrabiec: rdtsc might be something to use here
12:43 < tgrabiec> clock_gettime() seems good enought, no ?
12:43 < penberg_home> sure
12:43 < penberg_home> but what are you doing?-)
12:43 < tgrabiec> I'm implementoing VMSystem.nanoTime()
12:44 < tgrabiec> It;s needed for Thread.sleep()
12:44 < penberg_home> oh
12:44 < penberg_home> right
12:44 < penberg_home> lets see what hotspot uses?
12:46 < penberg_home> you clock_gettime(CLOCK_MONOTONIC)
12:46 < penberg_home> s/you/yup/g
12:50 < tgrabiec> seems that classloader and class initialization is not thread safe at all
12:51 < penberg_home> tgrabiec: yeah?
12:51 < penberg_home> vegard: ping
12:52 < tgrabiec> yeah, no locking there
12:52 < penberg_home> add some
12:52 < penberg_home> :)
12:52 < tgrabiec> oh, I think I will
12:57 < penberg_home> tgrabiec: oh
12:57 < penberg_home> are you aware of how hotspot deals with "kill -3"?
12:57 < penberg_home> that's SIGHUP or something
12:57 < penberg_home> it's pretty damn useful for debugging running processes.
12:58 < tgrabiec> I'm not, what does it?
13:00 < penberg_home> tgrabiec: http://vafer.org/blog/20050705162937
13:00 < penberg_home> it's best if you just try it
13:00 < penberg_home> full thread dump (including stack trace)
13:00 < penberg_home> and deadlock detection
13:03 < tgrabiec> that's probably something we want in jato too
13:03 < penberg_home> yes
13:12 < vegard> yes, true
13:12 < vegard> it is not safe at all
13:13 < ahuillet> ?
13:13 < ahuillet> oh yes I did miss something
13:13 < ahuillet> with two clients on the bouncer
13:13 < vegard> tgrabiec: are you working on threading now? :D
13:13 < penberg_home> yes he is.
13:13 < vegard> wow..
13:13 < vegard> ok, does S.o.p() work now or what??
13:14 < penberg_home> nope
13:14 < vegard> what's the blocker?
13:14 < penberg_home> regalloc maybe?
13:14 < penberg_home> try it?-)
13:14 < ahuillet> :]
13:14 < vegard> urk
13:15 < vegard> somebody added the mmix stubs that I was working on :(
13:15 < vegard> tomek... three days ago. hm.
13:17 < vegard> ProtectionDomain stuffs
13:18 < penberg_home> yeah
13:18 < penberg_home> that's register allocator
13:18 < vegard> really? how do you know it?
13:20 < vegard> hm
13:25 < vegard> hmhm
13:25 < vegard> looking at S.o.p() now
13:25 < vegard> something is weird here.
13:25 < vegard> trace exception (NPE) says: from    : 0xa7d78a3a: java/security/ProtectionDomain.<init>
13:25 < vegard> but looking at the TRACE: java/lang/NullPointerException.<init>
13:26 < vegard> it's returning to jit_magic_trampoline: ret0=0xa7d605dd, ret1=0x806bf30: java/lang/NullPointerException.<init> #1
13:26 < vegard> oh
13:30 -!- t_grabiec [n=tomekg@avq119.neoplus.adsl.tpnet.pl] has joined #jato
13:30 -!- tgrabiec [n=tomekg@ald174.neoplus.adsl.tpnet.pl] has quit [Read error: 110 (Connection timed out)]
13:34 -!- penberg_home [n=penberg@cs149038.pp.htv.fi] has quit [Read error: 104 (Connection reset by peer)]
13:35 -!- penberg_home [n=penberg@cs149038.pp.htv.fi] has joined #jato
13:35 < penberg_home> vegard: so
13:35 < penberg_home> that's the register allocator bug
13:35 < vegard> even weirder
13:35 < vegard> I used javap to decompile the ProtectionDomain.java
13:35 < vegard> *.class
13:35 < vegard> from the glibj.zip that I'm using
13:36 < vegard> and I can't find the method signature that appears in the trace
13:38 < vegard> I think it's decompiling the hotspot versino of the class...
13:39 < vegard> yay -bootclasspath did the trick
13:46 < vegard> let me try to put together a test case.
13:58 < vegard> yay :)
13:59 < vegard> is quite fun to put together test cases.
14:00 < vegard> http://pastebin.com/m378ca373
14:01 < vegard> somehow, the "this" pointer becomes null when the assignment to "this.y" is executed (line 16)
14:01 < vegard> i.e. it's the putfield that fails
14:02 < vegard> hm
14:02 < vegard> it (the bug) happens only if b _isn't_ null
14:03 < vegard> i.e. it only happens if the first if-block is executed
14:07 < vegard> hm, no, I was wrong
14:07 < vegard> it's the opposite
14:07 < vegard> it happens only if b is null
14:20 < vegard> hmmmm
14:21 < vegard> maybe I can write an even better test with jasmin, let's try
14:26 < penberg_home> that would be nice
14:26 < penberg_home> please do submit it if you do it
14:39 < vegard> bleh :P
14:39 < vegard> all I can do is get lots of "assertion failed" from jat
14:39 < vegard> o
14:39 < vegard> jato: include/vm/stack.h:21: stack_pop: Assertion `stack->nr_elements' failed.
14:42 < vegard> hm
14:42 < penberg_home> wow
14:42 < vegard> SIGSEGV at EIP 0805b4b0 while accessing memory address 00000040.
14:42 < penberg_home> does it run with hotspot?
14:42 < vegard> Exception in thread "main" java.lang.ClassFormatError: Field "x" in class Crash2 has illegal signature "int"
14:42 < vegard> heh
14:43 < vegard> the verifier.. ;)
14:43 < vegard> is missing.
14:43 < vegard> so it tries to run my crappy code.
14:43 < penberg_home> :)
14:43 < vegard> Exception in thread "main" java.lang.VerifyError: (class: Crash2, method: bar signature: ()V) Stack size too large
14:44 < vegard> O.o
14:45 < t_grabiec> vegard: the same you'll get for example WideTest and SubroutineTest. I didn't figure out why
14:45 < vegard> oh really? they're also jasmin tests?
14:46 < t_grabiec> yup, in regression/jvm
14:46 < vegard> you have .limit locals 257 there..?
14:46 < t_grabiec> yup, but in SubroutineTest I don't
14:49 < vegard> .limit stack
14:54 < t_grabiec> vegard: are we able to run static field initializers ?
14:54 < vegard> yes.
14:54 < t_grabiec> like in: private static final Runtime current = new Runtime();
14:54 < t_grabiec> from Runtime.java
14:54 < vegard> that gets compiled to the <clinit> method
14:57 < vegard> which we run on class initialization
14:57 < vegard> if you find that it doesn't work, please tell me how to reproduce :)
15:00 < vegard> ok, so we apparently need both .limit stack and .limit locals for hotspot to accept it
15:01 < penberg_home> oh
15:01 < penberg_home> you fixed WideTest?
15:01 < vegard> um, dunno, but I got rid of the same error that tomek reported for my own test :)
15:01 < vegard> and my jasmin source now runs in hotspot
15:03 < t_grabiec> vegard: nice!
15:03 < penberg_home> patches please!
15:04 < t_grabiec> oh man, debugging multithreaded apps with -Xtrace:jit is no can do.
15:04 < ahuillet> I have a little C question - I'm writing this library that exports a structure that is supposed to be opaque to the user
15:04 < ahuillet> however the user will need to know what's inside the structure to know its size when allocating one
15:04 < ahuillet> so what's the standard procedure ?
15:05 < vegard> pimpl ? to pass only pointers around.
15:05 < penberg_home> t_grabiec: that's an interesting one.
15:06 < ahuillet> ?
15:06 < ahuillet> vegard : this means the user can't malloc the pointer himself, right?
15:07 < ahuillet> so I guess I don't have much of a solution here, but I wondered what the standard procedure was
15:07 < vegard> yes
15:07 < vegard> correct.
15:07 < vegard> or you can just export the structure
15:07 < vegard> though that makes it harder to stay compatible between versions
15:08 < vegard> if the user of the library only knows about the pointer (and you do allocation within the library) you get a lot of backward compatibility for free
15:08 < ahuillet> ok so the API they specified for me is wrong
15:08 < ahuillet> they have this int hbm_allocate(struct hbm_data *)
15:08 < vegard> heh
15:09 < ahuillet> but it needs to be hbm_data **
15:09 < ahuillet> now, how do I get an API specification changed @Bull
15:09 < ahuillet> aka. do they have a very codified protocol for this kind of things or not :)
15:10 < penberg_home> struct hbm_data *hbm_alloc()
15:10 < penberg_home> pls
15:10 < penberg_home> ;)
15:10 < ahuillet> penberg_home : oh, thanks
15:10 < ahuillet> I should have thought of it.. I knew you'd know the cleanest way
15:11 < penberg_home> heh
15:11 < ahuillet> now how to avoid conflicts between hbm_alloc and hbm_allocate
15:11 < penberg_home> conflicts?
15:12 < ahuillet> well, it's confusing to have both
15:13 < penberg_home> hbm_data_alloc()?
15:14 < ahuillet> ah well, let's see how Bull guys feel about me modifying their API spec. :)
15:14 < penberg_home> :)
15:15 < penberg_home> well
15:15 < penberg_home> the original one doesn't work
15:15 < penberg_home> :)
15:35 < penberg_home> later guys!
15:35 -!- penberg_home [n=penberg@cs149038.pp.htv.fi] has quit []
16:04 < vegard> http://pastebin.com/m41e93e0a
16:04 < vegard> slightly reduced test-case
16:04 < vegard> still crashes here
16:07 < vegard> or even http://pastebin.com/m33a2ad0e (more suitable for debugging, I suppose)
16:19 < vegard> hm
16:19 < vegard> I think this is a bug in bytecode -> HIR conversion
16:26 < vegard> yup
16:26 < vegard> it even has "mov_reg_reg r7, r9" in the LIR
16:26 < vegard> but r7 is otherwise unreferenced...
16:31 < vegard> um
16:31 < vegard> do we have a particular calling convention about %ebx ?
16:33 < t_grabiec> vegard: It's a callee saved reg, why?
16:33 < vegard> just.. it's not assigned any value in the current function
16:33 < vegard> before it is used
16:34 < vegard> (r7 = %rbx)
16:34 < vegard> sorry, %ebx
16:35 < t_grabiec> vegard: the problem might be in HIR. Check that the temporary that owns r7 is assigned a value
16:36 < vegard> yes, I thought it was in HIR
16:36 < vegard> I just checked with LIR and assembly to make sure :)
16:36 < vegard> http://folk.uio.no/vegardno/trace.txt
16:36 < vegard> I have added some inline comments
16:37 < t_grabiec> looks like [temporary reference 0x9907c18 (low)] is never assigned
16:38 < vegard> I think the store should never be there to begin with
16:38 < vegard> shouldn't it be just a single immediate (null) -> temporary store ?
16:40 < t_grabiec> I think ahuillet's mimic-stack resolution algorith inserts some stores at basic block boundaris, it could be it (not sure)
16:40 < ahuillet> mimic stack stuff does not insert stores
16:40 < ahuillet> it simply picks the right temporaries, no stores in that
16:41 < t_grabiec> right
16:41 < ahuillet> the control flow resolution algorithm in the register allocator does some mov though
16:41 < ahuillet> but it touches neither the HIR nor the LIR
16:41 < ahuillet> only the assembly
16:41 < t_grabiec> ahuillet: the point is, that the store src comes out of nowhere
16:42 < ahuillet> the source doesn't exist?
16:42 < ahuillet> mmh rightr
16:43 < vegard> I think the whole store comes out of nowhere.. ;)
16:43 < ahuillet> we use the store_dest afterwards though
16:44 < ahuillet> ok, there likely is a bug in bytecode to HIR conversion
16:44 < ahuillet> that's the most probable explanation
16:44 < vegard> as the neew "this" pointer, yes :P
16:44 -!- Eduard_Munteanu [n=edi@79.115.194.81] has joined #jato
16:44 < Eduard_Munteanu> Hi.
16:44 < vegard> Eduard_Munteanu: hello
16:44 < t_grabiec> it would work if temporary 0x9907d20 was used instead of 0x9907c18 in that store
16:45 < ahuillet> we need to check where that 07c18 comes from
16:46 < vegard> would it help to pass __func__ to temporary_expr() perhaps?
16:46 < t_grabiec> vegard: or call print_trace()
16:48 < vegard> good idea :)
16:49 < vegard> um
16:49 < vegard> they're never allocated using temporary_expr()...
16:49 < ahuillet> ?!
16:49 < vegard> or did I catch the wrong function?
16:49 < Eduard_Munteanu> t_grabiec, regarding your RFC PATCH, why do we pass a reference if the method _is_ static?
16:50 < t_grabiec> Eduard_Munteanu: because JNI spec says so
16:50 < ahuillet> vegard : ok, this could be a bug in mimic stack resolution indeed
16:50 < Eduard_Munteanu> t_grabiec, okay, it seemed odd to me because statics have no *this.
16:51 < t_grabiec> Eduard_Munteanu: yeah, JNI is different than regular java methods on that matter
16:51 < ahuillet> vegard : the mimic stack thing turns EXPR_MIMIC_STACK_SLOT into EXPR_TEMPORARY
16:51 < Eduard_Munteanu> t_grabiec, okay, will ACK the patch so Pekka can merge it.
16:51 < ahuillet> so it "creates" new temporaries without going through temporary_expr
16:55 < vegard> um
16:55 < vegard> afaict it doesn't go through mimic_stack_expr() only..
17:08 < vegard> what's this spill_expression() in bytecode-to-ir.c ?
17:09 < ahuillet> used for mimic stack stuff
17:09 < vegard>         store->store_src = &expr->node;
17:10 < vegard> I think I printed the wrong value
17:29 < vegard> ah well, going home
17:30 < vegard> figure it out if you can ;)
18:00 -!- t_grabiec [n=tomekg@avq119.neoplus.adsl.tpnet.pl] has quit [Remote closed the connection]
18:32 -!- penberg [n=penberg@91-150-53-169.customer.karistelefon.fi] has joined #jato
18:39 < penberg> aah
18:39 < penberg> patch bomb from tomek
18:48 < penberg> threading support
18:48 < penberg> nice
18:48 < penberg> we have pretty damn heavy-weight monitors too ;)
18:58 < penberg> vegard: please double-check the "classloader_mutex" thingy
18:59 < penberg> later
18:59 -!- penberg [n=penberg@91-150-53-169.customer.karistelefon.fi] has quit ["leaving"]
19:20 < ahuillet> I got my rear wheel stolen
19:20 < ahuillet> 2H and 60EUR lost
19:30 < Eduard_Munteanu> ahuillet, ouch.
--- Log closed Wed Jul 29 00:00:22 2009