--- Log opened Mon Jun 29 00:00:02 2009
00:16 < tgrabiec> vegard: i think this patch is working: http://pastebin.com/d1c68536b
00:17 < ahuillet_> mmh
00:17  * tgrabiec must go get yet another bottle of wine
00:19 < ahuillet_> oh, you're not just a bit drunk then? :)
00:20 < tgrabiec> i must say that the whole bottle of wine have already evaporated from me, i'm completly sober
00:21 < tgrabiec> thus need a new one :)
00:21 < ahuillet_> hehe :)
00:21 < ahuillet_> I have trouble following what you guys have done today
00:21 < ahuillet_> we're still working on initializing classes?
00:30 < tgrabiec> ahuillet_: i think so. i think vegard needs some kind of lazy class initialization on putstatic/getstatic etc.
00:31 < tgrabiec> so we do it using an indirection table with traps triggering sigsegv when class is not initialized
00:31 < tgrabiec> (long story short)
00:31 < ahuillet_> whow.
00:31 < tgrabiec> well not 'we', actually vegard is doing
00:31 < tgrabiec> i was just fixing dome install_signal_bh() bug
00:31 < tgrabiec> *some
00:37 < ahuillet_> how did he "need" this lazy init?
00:37 < ahuillet_> as in, necessary to make things work?
00:37 < ahuillet_> or necessary to comply with an obscure point of the spec?
00:38 < tgrabiec> i think it's necessery. i don't know the details however
00:39 < tgrabiec> i can imagine that we need lazy initialization to avoid initizalization loop, but i'm not sure
00:39 < tgrabiec> anyway, it's part of the VM spec too
00:39 < ahuillet_> k
00:40 < ahuillet_> 'cause I'm kind of stuck on the println front for now
00:40 < tgrabiec> if your bored, you can write bytecode offset in HIR printing ;)
00:40 < tgrabiec> *your're
00:41 < tgrabiec> i think vegard will solve the issue soon
00:54 < ahuillet_> ok so
00:54 < ahuillet_> get_var() is an architecture independant function
00:54 < ahuillet_> now, I want to add to virtual registers a notion of type
00:54 < ahuillet_> so for example we can do get_fpu_var()
00:55 < ahuillet_> are register types architecture independant?
00:55 < tgrabiec> what do you mean by register types, regular/fpu ?
00:56 < ahuillet_> well, that's the only types I have in mind
00:56 < ahuillet_> GPR and FPU
00:56 < ahuillet_> though on PPC I believe there are several conditions register
00:56 < ahuillet_> *+s
00:56 < ahuillet_> anyway I'll go for register types -> architecture independant
00:57 < ahuillet_> with a bit of luck, we'll have basic FPU going in a few hours.
00:57 < tgrabiec> really? don't you need a sleep ?
00:57 < ahuillet_> oh, yes, that
00:57 < ahuillet_> anyway a few hours does count the sleep, for a large enough value of "a few" :)
00:58 < tgrabiec> right
00:59 < ahuillet_> that said it's gonna be more difficult than I'm saying
00:59 < ahuillet_> I won't use x87 you see
00:59 < ahuillet_> but SSE
01:00 < ahuillet_> the problem with SSE is that you can do scalar computations but you might have to zero out the rest of the register
01:00 < ahuillet_> I need to check if addss is SSE or SSE2
01:00 < tgrabiec> so SSE registers don't interfere with x87 fpu stack ?
01:01 < tgrabiec> mmx regs do
01:01  * tgrabiec knows hardly anything about sse
01:01 < ahuillet_> SSE ... not sure, it's not like we care
01:01 < ahuillet_> we aren't going to use x87 anyway. :)
01:01 < tgrabiec> oh don't we ?
01:01 < ahuillet_> mmh no, it looks like SSE registers are separate.
01:02 < ahuillet_> tgrabiec : no, since we have SSE
01:02 < ahuillet_> x87 is stack based
01:02 < ahuillet_> you tell me how you implement that into jato easily
01:03 < tgrabiec> no thanks
01:04 < ahuillet_> now, we can do very funny things to "spill" SSE registers
01:04 < ahuillet_> we've got 8 of them, but if that's not enough
01:04 < ahuillet_> since we use them as scalars
01:04 < ahuillet_> we can simply shift the reg 32bits to the left
01:05 < ahuillet_> and we have three spill slots per register
01:05 < ahuillet_> then, we start using the stack
01:05 < ahuillet_> :]
01:46 < ahuillet_> FPU register allocation: done
01:48 < ahuillet_> EXPR_FVALUE almost ready to go
01:48 < ahuillet_> time to sleep
01:48 -!- ahuillet_ [n=user@79.83.34.239] has quit ["Leaving"]
02:05 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has quit [Remote closed the connection]
08:37 -!- penberg [n=penberg@xdsl-83-150-86-196.nebulazone.fi] has joined #jato
08:38 -!- mode/#jato [+o penberg] by ChanServ
09:06 <@penberg> vegard: it turns out you're right about the include "foo" vs <foo> thing.
09:16 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has joined #jato
09:17 <@penberg> tgrabiec: hey, vm/stack-trace.c uses INST_DATA, ARRAY_LEN, etc. macros from JamVM
09:17 <@penberg> tgrabiec: I'm pretty sure they don't work properly.
09:18 < tgrabiec> penberg: yes, i know, i didn't touch that yet
09:18 <@penberg> tgrabiec: I am removing include/vm/vm.h crud and noticed that.
09:18 <@penberg> tgrabiec: ok, as long as you know about it, it's fine.
09:19 < tgrabiec> penberg: about expr_is_pure(). a t first i thought we should check whether a particular expression is pure. but then i realized that it is most probably an error to make multiple references to certain _types_ of expressions
09:19 < tgrabiec> because when they come to convert_* we do not check what they contain
09:23 < tgrabiec> that's why i check left & right children _only_ for EXPR_ARRAY_DEREF
09:28 < tgrabiec> and i have this idea to rewrite most of the code that creates statements inside convertion code to use something like get_pure_expr() which will perform the expr_dup() only when it's necessary
09:29 < tgrabiec> but i won't do that untill convert_* unit tests are gone ;)
09:30 <@penberg> tgrabiec: ok.
09:30 <@penberg> I'm not sure convert_*() tests will be removed.
09:31 <@penberg> _instruction selector_ tests will be.
09:39 < tgrabiec> ok, i'm not going to work on this now as everything seems to work and i have some GSoC project to finish :)
09:40 < tgrabiec> vegard: ping
09:40 <@penberg> tgrabiec: ;)
09:41 <@penberg> tgrabiec: I am pretty good at ruining people's plans and side-tracking them on working unrelated things, aren't I?-)
09:43 <@penberg> vegard: http://github.com/penberg/jato/commit/880f38041e2dc4002fc02fe8ccdfd2ba95e8f940
--- Log opened Mon Jun 29 09:57:26 2009
09:57 -!- jato-irc-logger [n=vegard@cm-84.209.125.101.getinternet.no] has joined #jato
09:57 -!- Irssi: #jato: Total of 6 nicks [2 ops, 0 halfops, 0 voices, 4 normal]
09:57 -!- Irssi: Join to #jato was synced in 5 secs
09:59 < vegard> ping
09:59 <@penberg> ping or pong
09:59 <@penberg> and tho whom
09:59 <@penberg> packet lost.
09:59 < vegard> broadcast address
10:00 <@penberg> pong
10:00 <@penberg> vegard: I removed most of the crud from include/vm/vm.h
10:00 <@penberg> vegard: what's the story of T_BOOLEAN and friends?
10:01 < vegard> I figured out that T_INT != J_INT
10:01 <@penberg> ok, but what the hell is T_BOOLEAN?
10:01 <@penberg> something from the jvm spec?
10:02 <@penberg> cafebabe should have those constants somewhere?
10:02 < vegard> one of them is from jvm spec
10:03 < vegard> http://www.j2ee.me/docs/books/jvms/second_edition/html/ClassFile.doc.html#20080
10:03 < vegard> we have CAFEBABE_CONSTANT_TAG_* mnemonics
10:04 <@penberg> vegard: not the same
10:04 <@penberg> no boolean, for example.
10:05 <@penberg> The atype operand of each newarray instruction must take one of the values T_BOOLEAN (4), T_CHAR (5), T_FLOAT (6), T_DOUBLE (7), T_BYTE (8), T_SHORT (9), T_INT (10), or T_LONG (11).
10:05 <@penberg> 4.8 Constraints on Java Virtual Machine Code
10:06 <@penberg> yup, part of "anewarray" bytecode specification.
10:07 < vegard> oh ok, you found it
10:09 <@penberg> vegard: we need to move those to cafebabe somewhere
10:09 <@penberg> suggestions?
10:10 < vegard> hm. I don't think we necessarily have to do that.
10:10 <@penberg> vegard: yeah?
10:10 < vegard> remember, we don't provide bytecode mnemonics or parse bytecodes at all in cafebabe
10:11 <@penberg> vegard: true, but it is part of _classfile_ too
10:11 <@penberg> vegard: I could just move them to vm/object.c?
10:11 < vegard> don't they need to be in a header? where do we use them?
10:11 <@penberg> vegard: only in vm/object.c
10:12 <@penberg> I think they ought to be in cafebabe
10:12 <@penberg> in any case, I'd like to get rid of include/vm/vm.h
10:12 <@penberg> so we should move the somewhere.
10:12 < vegard> hehe, yes.
10:12 < vegard> in case they go to cafebabe, they'll also get a new name
10:13 <@penberg> vegard: CAFEBABE_T_BOOLEAN?-)
10:15 <@penberg> vegard: I have been wondering if we should turn cafebabe in a proper library.
10:16 <@penberg> not now, but maybe in future.
10:16 <@penberg> like libzip
10:17 < vegard> oh, so you want that now?
10:20 <@penberg> vegard: not _now_
10:20 <@penberg> but maybe in the future I can do "apt-get install libcafebabe"
10:20 <@penberg> then we could switch.
10:21 <@penberg> but yes, I am beginning to open up for the idea that we grow cafebabe in jato and set it free at some point in time.
10:21 <@penberg> I wonder if we should restructure the git repository to reflect that
10:21 <@penberg> so the top-level would be
10:21 <@penberg> jato/
10:21 <@penberg> cafebabe/
10:21 <@penberg> but anyway.
10:22 <@penberg> otoh, if we put cafebabe on git.kernel.org, maybe the submodule thing is fine as well.
10:22 <@penberg> alternatively, cafebabe/src becomes cafebabe and cafebabe/include/cafebabe becaomes include/cafebabe
10:23 < vegard> we might be able to git mv them in place
10:23 < vegard> and git merge will still figure it out
10:24 <@penberg> right.
10:24 <@penberg> but anyway, I think the best place for cafebabe to grow is in jato right now.
10:24 < vegard> yes :)
10:24 <@penberg> but I am beginning to like the library approach.
10:33 < tgrabiec> vegard: did you see the reworked patch i sent after you left ?
10:33 < tgrabiec> pls tell me if it's working for you
10:36 < vegard> oh, I didn't
10:36 < tgrabiec> here it is http://pastebin.com/d1c68536b
10:36 < tgrabiec> seems to work here
10:37 < vegard> will try it in a moment
10:52 -!- ahuillet_ [n=user@79.83.34.239] has joined #jato
10:52 -!- ahuillet_ [n=user@79.83.34.239] has quit [Read error: 104 (Connection reset by peer)]
10:56 -!- mode/#jato [+o ahuillet] by ChanServ
10:56 <@ahuillet> hi
11:16 < vegard> hi!
11:17 <@penberg> salut
11:18 < vegard> tgrabiec: can I still use __builtin_return_address(0) with that patch?
11:18 < tgrabiec> vegard: the return address is passed as argument to bh handler
11:18 < vegard> aah, cool
11:19 < vegard> I am so close to doing the fixup thing, all I have to do now is the actual fixup :)
11:19 < tgrabiec> i think i will make it this way: bh handler will return the address to which signal_bh_trampoline should return - this solves the issue with return address overwriting when doing throw_from_native()
11:20 < tgrabiec> vegard: don't overwrite return address to previous instruction ?
11:20 < tgrabiec> *don't you overwrite
11:21 < vegard> let's see... no, not anymore
11:21 < vegard> not if I can use the MEMDISP thing :)
11:22 < tgrabiec> aha
11:22 < vegard> yes, that's beautiful.
11:27 < vegard> yup, works here
11:28 < vegard> did you send me the memdisp patch too?
11:29 < vegard> yes, found it. thanks
11:31 < vegard> will you submit them to pekka?
11:32 < tgrabiec> vegard: yes, i will rework the bh patch a bit
11:32 < tgrabiec> now that i'm not drunk ;)
11:32 < vegard> great!
11:33 <@ahuillet> tgrabiec : so, was my prediction right? did you throw away the whole thing and start again?
11:34 <@ahuillet> or will you simply rename oh_god_I_miss_you_so_much() and friends? :)
11:38 < tgrabiec> ahuillet: well, I can't say it's that bad, I just made one assembly function, which needs only a little "tweaking" ;)
11:39 < vegard> tgrabiec: in monoburg, do I use imm_reg_insn(INSN_MOV_MEMDISP_REG, ...) ?
11:39 < tgrabiec> yes
11:39 < vegard> k.
11:40 < vegard> mov    0x9ad6000,%edx
11:40 < vegard> that's what it produces
11:41 < vegard> if it had been mov imm, it would have $ in front of the number, right?
11:41 < vegard> yep.
11:42 < tgrabiec> yes
11:43 < vegard> I wonder how to make this race-free...
11:47 <@ahuillet> penberg : so, what about some FPU support today? ;)
11:48 <@penberg> ahuillet: yes please!
11:48 <@ahuillet> I'm gonna need a bit of help for the cleanup of the patch
11:48 <@ahuillet> nothing big
11:49 <@ahuillet> I have XMM register allocation going, the patch is like 30 lines
11:49 <@ahuillet> vegard : will EXPR_FVALUE work now?
11:49 <@ahuillet> do you properly load floating point values from the constant pool?
11:49 < vegard> oh.. nope
11:49 <@ahuillet> heh :)
11:49 < vegard> you can do it if you want...
11:50 <@ahuillet> sure, but is it doable for me?
11:51 <@ahuillet> what's it about?
11:51 <@penberg> ahuillet: i think it is.
11:51 <@ahuillet>     return cafebabe_stream_read_uint32(s, &f->bytes);
11:51 <@ahuillet> that's what cafebabe_constant_info_float_init currently does
11:52 < vegard> I think it's probably easiest if you just do it in jit/load-store-bc.c
11:53 < vegard> in __convert_ldc() you have a switch on the type of the constant pool entry
11:53 < vegard> so you need to look at CAFEBABE_CONSTANT_TAG_FLOAT and _DOUBLE
11:54 < vegard> the cp->float_.bytes is just a uint32_t
11:54 -!- ahuillet_ [n=user@239.34.83-79.rev.gaoland.net] has joined #jato
11:55 < vegard> there is also cp->double_ has .high_bytes and .low_bytes (both uint32_t)
11:55 < vegard> definition of those structs you can see in cafebabe/include/cafebabe/constant_pool.h
12:02 < vegard> IT WORKS!!!! :D
12:02 < ahuillet_> ?
12:02 < vegard> my back-patching
12:06 < vegard> tgrabiec: do we have mov_reg_memdisp as well?
12:06 < vegard> or... I can try to implement that
12:06 < vegard> looking at your patch for memdisp_reg
12:15 < tgrabiec> vegard: we don't but it's easy to do in the simmilar way :)
12:15 < vegard> jato: jit/spill-reload.c:39: last_insn: Assertion `ret != ((void *)0)' failed.
12:15 < vegard> what's this?
12:20 <@penberg> vegard: empty basic block?
12:20 <@penberg> ahuillet will know all about it.
12:20 <@penberg> it's "his code" again :-)
12:20 < vegard> http://pastebin.com/m715b11c5
12:21 < vegard> that's my test case. I don't think I changed anything that messes with basic blocks.
12:21 <@penberg> vegard: try to narrow it down a bit more.
12:22 < vegard> can you reproduce it? :)
12:22 <@penberg> vegard: is the 'end' value sane in last_insn() ?
12:22 <@penberg> vegard: I'm bit busy atm, sorry.
12:22 < vegard> oh, sure, ok :)
12:28 < vegard> http://pastebin.com/m1f0544a3
12:28 < vegard> #
12:28 < vegard>    0 (pos: 2147483647-17):      EAX     non-fixed       no spill        reload
12:28 < vegard> that's a very large "pos"
12:30 < tgrabiec> register #19 is accessed used before def, and reg #20 is defined but never used
12:30 <@penberg> vegard: hmm, liveness analysis bug?
12:30 < tgrabiec> or register allocator
12:30 <@penberg> looks like MAX_INT
12:30 < vegard> it's probably my EXPR_CLASS_FIELD changes to insn-selector_32.brg :-/
12:31 <@penberg> possibly.
12:31 < tgrabiec> vegard: can you show the insn selector code for fields ?
12:32 <@penberg> vegard: interval->range.start = ~0UL;
12:32 < ahuillet_> vegard : show the code.
12:32 < vegard> http://pastebin.com/m7a4d8741
12:33 < tgrabiec> vegard: line 26, base is assigned a value that is never used ?
12:33 < ahuillet_> what he says.
12:34 < vegard> base is the target register?
12:34 < tgrabiec> you allocate 2 registers in lines 13 and 13
12:34 < tgrabiec> the state->reg1 is the expr result
12:34 < tgrabiec> which never assigned
12:34 < tgrabiec> i think you meanst state->reg1 = base
12:34 < tgrabiec> *meant
12:35 < vegard> hm.
12:36 < vegard> should I just remove the state->reg1 = get_var() line?
12:37 < tgrabiec> you should assign something to state->reg1 (it should point to a register which holds the expression result)
12:38 < tgrabiec> the point is that now you assign a new register to state->reg1 in line 12 but you never set this register's value
12:38 < tgrabiec> you are doing a MOV to 'base' register, but you never use that register
12:38 < vegard> ah.
12:39 < vegard> ok, it works now :)
12:39  * tgrabiec is going to cook some lunch
12:39 < ahuillet_> that said it should not have crashed like this
12:40 < ahuillet_> tgrabiec : so what's on the menu?
12:40 < tgrabiec> "brown potatoes" i think.
12:41 < tgrabiec> mashed potatoes with onion milk and eggs, fried
12:42 < tgrabiec> of course with KEFIR
12:42 <@ahuillet> oh, sounds nice
12:44 -!- ahuillet_ [n=user@239.34.83-79.rev.gaoland.net] has quit ["Leaving"]
12:46 < vegard> hm
12:46 < vegard> the LIR always looks like this: mov_memdisp reg r1, r2; mov_reg_reg r2, r3
12:46 < vegard> how can I output directly to the right register?
12:49 <@ahuillet> don't emit the second move and output directly to the right register :)
12:50 < vegard> I'm only outputting one instruction
12:50 < vegard> that's the imm_reg_insn()
12:50 < vegard> sorry, imm_reg_insn(INSN_MOV_MEMDISP_REG, )
12:53 <@penberg> vegard: hmm, use-def bug?
12:53 <@penberg> missing a insn type?
12:54 < vegard> I don't understand :)
12:54 <@penberg> arch/x86/use-def.c
12:54 <@penberg> if it doesn't have one of the INSN_xxx you are using
12:54 <@penberg> liveness analysis goes nuts
12:55 < vegard>         DECLARE_INFO(INSN_MOV_IMM_MEMBASE, USE_DST),
12:55 < vegard> oh, sorry
12:55 < vegard>         DECLARE_INFO(INSN_MOV_MEMDISP_REG, USE_NONE | DEF_DST),
12:56 <@penberg> USE_NONE, is that true?
12:56 <@penberg> tgrabiec: ?
13:14 < vegard> THREAD_LOCAL_MEMDISP_REG has it too
14:06 < vegard> if MEMDISP_REG uses imm_reg_insn(), what does REG_MEMDISP use?
14:07 <@penberg> DST
14:07 <@penberg> oh sorry
14:08 <@penberg> SRC
14:08 < vegard> no, I mean the imm_reg_insn() / reg_insn() / branch_insn() / ...
14:08 <@penberg> well imm_reg is probably wrong
14:08 <@penberg> for MEMDISP_REG
14:09 <@penberg> it should be imm_memdisp_reg() and the other one imm_memdisp_reg()
14:09 <@penberg> vegard: did you figure out the pos bug?
14:09 < vegard> yes
14:09 < vegard> THREAD_LOCAL_MEMDISP_REG uses imm_reg_insn() too..
14:10 <@penberg> tgrabiec: any reason there's no memdisp_reg() ?
14:13 < vegard> it's the same
14:13 < vegard> but I can add it
14:16 < vegard> ok, works
14:16 < vegard> I added everything that is needed for REG_MEMDISP :D
14:19 <@penberg> cool
14:21 <@penberg> http://teaseme.sourceforge.net/
14:21 <@penberg> crazy
14:21 < vegard> haha ;)
14:26 < tgrabiec> i'm back. so you guyes fixed everything or there's something for me ?
14:27 < tgrabiec> penberg: I gues I used imm_reg_insn() instead of creating memdisp_reg_insn() for MOV_MEMDISP_REG because I was too lazy
14:29 <@penberg> tgrabiec: ok, that's what I thought. just wanted to make sure there wasn't some problem there.
14:30 < vegard> hm, it's really a pity about valgrind.
14:33 < tgrabiec> penberg: don't you think that get_cu_from_native_addr() should rather be called get_cu_from_jit_addr() ?
14:36 < vegard> YAY! getstatic/putstatic worksssss and they call the <clinit> if it hasn't been initialized already and they patch the code afterwards :D:D:D
14:36 < tgrabiec> vegard: splendid :D
14:36 < vegard> oh. I forgot to remove the patch-sites from the list, though.
14:37 <@penberg> tgrabiec: jit_lookup_cu(addr) maybe?
14:38 < tgrabiec> yeah, better
14:38 < vegard> penberg: don't you think that include/vm/list.h should go in include/lib/list.h ?
14:38 <@penberg> vegard: Yes, I do think they should go there.
14:39 <@penberg> vegard: and we should start use #include "lib/list.h" instead
14:40 <@penberg> otherwise we might collide with namespaces in /usr/include
14:40 <@penberg> _all_ jato header should be #included with "foo" rather than <foo>
14:40 < vegard> :D
14:40 < vegard> yup. what made you see the light? :)
14:40 <@penberg> I realized that today on the bus.
14:40 <@penberg> when I thought about moving things to include/lib
14:41 <@penberg> but anyway
14:41 < vegard> well, I am glad you agree :D
14:41 <@penberg> I am not that good in userspace programming, it seems.
14:41 <@penberg> vegard: not a huge issue
14:41 < vegard> of course not :p
14:41 <@penberg> but we should probably encourage "foo" in new code.
14:41 < vegard> btw, we have REG_EAX conflict
14:41 <@penberg> vegard: how so?
14:42 < vegard> the uc_mcontext.gregs[REG_IP] stuff
14:42 <@penberg> true.
14:42 < vegard> REG_ constants are defined both by us (for reg alloc) and system headers
14:43 <@penberg> REGISTER_EAX ?
14:43 < vegard> it's not a huge problem, but I noticed it ;)
14:43 < vegard> that's hardly any better _in principle_ (it's better in practice, of course).
14:43 < vegard> JATO_REG_EAX, I think.
14:44 < vegard> hm. actually I am partly wrong.
14:44 <@penberg> heh
14:44 < vegard> I am in two minds :)
14:44 <@penberg> there's not much sense to prefix everything with JATO_ or jato_
14:45 <@penberg> REGISTER_EAX is better because it avoid the conflict.
14:45 <@penberg> but anyway
15:01 < tgrabiec> sent reworked signal bh patch on list
15:06 < tgrabiec> vegard: was there anything wrong about INSN_MOV_MEMDISP_REG patch or can i go ahead and send it too ?
15:07 < vegard> please go ahead and send it
15:07 < vegard> I will send the REG_MEMDISP on top of it
15:07 < tgrabiec> k
15:16 <@penberg> hugetlbfs
15:16 <@penberg> what a mess.
15:16 <@penberg> if you want to mmap() a huge page, you need to _mount_ a hugetlbfs
15:17 < vegard> INVOKESTATIC works.
15:17 <@penberg> otoh, if you use shmget(SHM_HUGEPAGE), you need to belong to a group set in /proc/sys/vm/hugetlb_shm_group
15:17 <@penberg> horror
15:18 < tgrabiec> penberg: oh you remined me - we talked about 4KB page size assumption on x86 which it allows me to reduce exception test code - i cannot use alloc_page() because it cannot allocate per-thread pages
15:20 <@penberg> right.
15:20 <@penberg> tgrabiec: lets not simplify the code though
15:20 <@penberg> we want to use it on x86-64, probably
15:20 < tgrabiec> k
15:20 <@penberg> vegard: does x86-64 support 8K pages?
15:22 < vegard> 8k? never heard of it
15:23 < vegard> there's 4k, 2m, 4m afaik
15:23 <@penberg> on 64-bit as well?
15:23 <@penberg> tgrabiec: is that code x86 specific btw
15:23 <@penberg> tgrabiec: I mean, I'm sure it is now
15:23 <@penberg> tgrabiec: but would simplification affect future generification
15:24 < tgrabiec> penberg: well it is architecture specific. if some architecture won't allow us to do such trick, we will do it another way
15:24 <@penberg> hmm, trick
15:25 <@penberg> that's a black-listed word in my patch review dictionary
15:25 <@penberg> ;)
15:25 <@penberg> tgrabiec: vm: fix bug in signal bottom half mechanism
15:25 <@penberg> doesn't seem to apply
15:25 < tgrabiec> penberg: i had another idea, to use directly the kernel mechanism that is used to handle __thread variables, but i need to read about it more
15:26 <@penberg> nvm
15:26 <@penberg> just some fuzz
15:26 < vegard> penberg: about that string signedness/unsignedness issue you mentioned. we need two different functions. the first one takes specially-encoded utf8, not normal utf8. the one that takes C strings should use const char *
15:26 <@penberg> I wonder why git am is so sensitive.
15:26 <@penberg> vegard: I'm fine with that.
15:26 < vegard> so the problem solves itself.
15:27 <@penberg> yup
15:30 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has quit [Remote closed the connection]
16:14 < vegard> ahuillet: know how to set data breakpoints in gdb?
16:20 < vegard> oh they're called "watch"
17:41 < vegard> argh.
17:41 < vegard> just spent about half an hour chasing down a bug
17:42 < vegard> turns out I was passing a field instead of a class
17:42 < vegard> gcc even warned about it
17:42 <@penberg_home> :)
17:42 <@penberg_home> rule number 1: pay attention to warnings.
17:42 <@ahuillet> watchpoints don't always work well
17:43 < vegard> yeah, I was completely overlooking the warning
17:44 < vegard> I saw it, I knew about it
17:44 < vegard> I was overlooking it on purpose, thinking I knew what it was
17:51 <@ahuillet> :]
17:52 < vegard> hm, do we have a regression in IntegerArithmeticTest?
17:56 < vegard> I'll rebase and see what happens.
18:19 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has joined #jato
18:25 < vegard> tgrabiec: I rebased to latest mainline and now getstatic/putstatic don't work anymore :(
18:25 < tgrabiec> vegard: let me chaeck that
18:25 < vegard> (what) did you change (anything) from the patch that you sent me separately?
18:25 < tgrabiec> i've got Tests OK
18:26 < tgrabiec> vegard: yes,  now bottom half handler is supposed to return the address that trampoline should return to
18:26 < vegard> ahhh, really?
18:26 < tgrabiec> yes, i think i mentioned it
18:27 < vegard> oh
18:27 < vegard> oops, sorry, that didn't register.
18:27 < vegard> ok, but that should explain it :)
18:27 < tgrabiec> so you need to do return the same address that handler gets as argument to return to faulting instruction
18:27 < vegard> yup.
18:28 < vegard> WOW!!!
18:28 < vegard> all tests passed...
18:28 < tgrabiec> nice :)
18:29 < vegard> actually, PutfieldTest failed. but I can figure it out.
19:30 < tgrabiec> i managed to make invokevirtual code shorter of 1 mov_membase_reg instruction
19:35 < vegard> patch bomb about to take off :)
19:36 < vegard> and nice :)
19:36 < vegard> how? :)
19:37 < tgrabiec> vegard: we do not have to pop the objectref from stack because code for call arguments is selected before EXPR_INVOKEVIRTUAL, and we can get the information which register was allocated to objectref before it was pushed on stack
19:37 < tgrabiec> and if objectref expression is EXPR_VALUE, then we simply perform mov imm,reg for it
19:37 < vegard> aha.
19:42 <@penberg_home> tgrabiec: nice patch ;)
19:43 <@penberg_home> vegard: excellent
19:44 <@penberg_home> vegard: shouldn't patch 8 come before 5-7?
19:45 < vegard> um, you decide
19:45 < vegard> the regression tests in 5-7 fail without patch 8
19:46 <@penberg_home> yes
19:46 <@penberg_home> so I'll reorder them
19:46 <@penberg_home> unfortunately, I don't have my laptop with me
19:46 < vegard> ok, no problem. that's the way I initally had them.
19:46 <@penberg_home> so I'll merge tomorrow morning
19:46 <@penberg_home> series looks good to me
19:46 < vegard> ok good :)
19:58 < vegard> BTW
19:58 < vegard> regarding "text gc"
19:59 < vegard> 2.17.8 has something to say about class unloading
19:59 < vegard> "A class or interface may be unloaded if and only if its class loader is unreachable."
19:59 < vegard> so I guess we should make one big text area per classloader?
20:00 < vegard> also: "The bootstrap class loader is always reachable; as a result, system classes may never be unloaded."
20:00 < vegard> so we could make the bootstrap class loader use a really big area (like we do now)
20:00 < vegard> and maybe use smaller areas for other class loaders?
20:26 < vegard> hm
20:27 < vegard> something strikes me as odd with the PrintTest HIR...
20:27 < vegard> the PrintTest itself is just: System.out.write(4);
20:29 < tgrabiec> vegard: does this code work with your patches http://pastebin.com/d6ab1952e ?
20:29 < tgrabiec> (i have problems amending your patches)
20:30 < tgrabiec> the question is: does it crash (because of stackoverflow) ?
20:30 < vegard> it throws java/Lang/UnsatisfiedLinkError
20:30 < vegard> java/lang/UnsatisfiedLinkError: java/lang/VMObject.getClass(Ljava/lang/Object;)Ljava/lang/Class;
20:31 < tgrabiec> ah right, you don't have it
20:31 < tgrabiec> thanks :)
20:31 < vegard> so we need to register a native with VMObject.getClass()
20:31 < tgrabiec> yes, i have it and i have also VMCLass.getName()
20:31 < tgrabiec> the problem is that it recursively calls this:
20:32 < tgrabiec> jit_magic_trampoline: ret0=0xa7d1d08d, ret1=0xa7d20834: java/lang/Object.toString #3
20:32 < tgrabiec> jit_magic_trampoline: ret0=0xa7d1d11d, ret1=0xa7d20fa9: java/lang/Object.getClass #6
20:32 < tgrabiec> jit_magic_trampoline: ret0=0xa7d2036d, ret1=0xa7d20414: java/lang/VMObject.getClass #1
20:32 < tgrabiec> jit_magic_trampoline: ret0=0xa7d1d7fd, ret1=0xa7d20fc0: java/lang/Class.getName #34
20:32 < tgrabiec> jit_magic_trampoline: ret0=0xa7d204dd, ret1=0xa7d207e4: java/lang/VMClass.getName #5
20:32 < tgrabiec> get class name java/lang/String
20:32 < tgrabiec> jit_magic_trampoline: ret0=0xa7d1d08d, ret1=0xa7d20834: java/lang/Object.toString #3
20:32 < tgrabiec> jit_magic_trampoline: ret0=0xa7d1d11d, ret1=0xa7d20fa9: java/lang/Object.getClass #6
20:32 < tgrabiec> jit_magic_trampoline: ret0=0xa7d2036d, ret1=0xa7d20414: java/lang/VMObject.getClass #1
20:32 < tgrabiec> jit_magic_trampoline: ret0=0xa7d1d7fd, ret1=0xa7d20fc0: java/lang/Class.getName #34
20:32 < tgrabiec> jit_magic_trampoline: ret0=0xa7d204dd, ret1=0xa7d207e4: java/lang/VMClass.getName #5
20:32 < tgrabiec> get class name java/lang/String
20:32 < tgrabiec> jit_magic_trampoline: ret0=0xa7d1d08d, ret1=0xa7d20834: java/lang/Object.toString #3
20:32 < tgrabiec> jit_magic_trampoline: ret0=0xa7d1d11d, ret1=0xa7d20fa9: java/lang/Object.getClass #6
20:32 < tgrabiec> jit_magic_trampoline: ret0=0xa7d2036d, ret1=0xa7d20414: java/lang/VMObject.getClass #1
20:32 < tgrabiec> jit_magic_trampoline: ret0=0xa7d1d7fd, ret1=0xa7d20fc0: java/lang/Class.getName #34
20:32 < tgrabiec> jit_magic_trampoline: ret0=0xa7d204dd, ret1=0xa7d207e4: java/lang/VMClass.getNam
20:32 < tgrabiec> oops, sorry, i thought it will paste a link: http://pastebin.com/d31b1c769
20:32 <@penberg_home> :)
20:32 <@penberg_home> I was wondering how much you were going to paste here
20:33 < tgrabiec> i've got plenty :)
20:38 < vegard> hm
20:39 < vegard> how can this happen?
20:39 < vegard> I mean, wouldn't it fix up the calls to Object.toString() for example?
20:39 < vegard> so that you don't see them in the trace?
20:39 < tgrabiec> oh, i disabled call fixing to see the whole picture
20:40 < vegard> ahhhh!!!
20:40 < vegard> and you don't tell me how it can be done too!!!
20:40 < vegard> so
20:41 < vegard> what's in your VMClass.getName() ?
20:41 < tgrabiec> http://pastebin.com/d6074983e
20:41 < vegard> and your VMObject.getClass() ?
20:42 < tgrabiec> http://pastebin.com/d3401314a
20:43 < vegard> this looks new: object->java_lang_Class_class :)
20:43 < tgrabiec> i have this in vm_class_init(): vmc->object->java_lang_Class_class = vmc;
20:45 < vegard> hm. wouldn't it be the same as vmc->object->class->object ?
20:45 < vegard> no...
20:48 < vegard> can you try to start it under gdb, interrupt it, and get the backtrace?
20:49 < vegard> it seems that the recursion should stop in one of the VMClass/VMObject
21:00 < tgrabiec> hmm, java/lang/String.valueOf() does not have a trampoline ?
21:01 <@penberg_home> ahuillet: is fpu giving you a headache?-)
21:03 <@penberg_home> hmm
21:03 <@penberg_home> github down
21:03 < tgrabiec> vegard: this is weird:  in java/lang/Object.toString() we call o.getClass().getName().valueOf(), and in java/lang/String.valueOf() we call java/lang/Object.toString()
21:04 < vegard> heh
21:04 < vegard> tgrabiec: that's from gnu classpath sources?
21:04 < tgrabiec> well, i deducted that from JIT trace
21:05 < vegard>   public static String valueOf(Object obj)
21:05 < vegard>   {
21:05 < vegard>     return obj == null ? "null" : obj.toString();
21:05 < vegard>   }
21:05 < vegard>   public String toString()
21:05 < vegard>   {
21:05 < vegard>     return getClass().getName() + '@' + Integer.toHexString(hashCode());
21:05 < vegard>   }
21:06 < tgrabiec> i don't know who put that valueOf to the getName() ?
21:06 < vegard> the compiler, probably?
21:06 < vegard> ah
21:07 < vegard> static vs. non-static valueOf()
21:07 < vegard> um, nvm.
21:08 < tgrabiec> i'll have a look at bytecode sources
21:12 < tgrabiec> oh i know where is the problem: in java/lang/String.valueOf it is INVOKEVIRTUAL call to toString() which in case of a String object should call String.toString() which returns this, but it is calling Object.toString()
21:12 <@penberg_home> interesting
21:12 <@penberg_home> hmm
21:13 <@penberg_home> hmm
21:13 <@penberg_home> vtable is per class
21:13 <@penberg_home> so the class of the reference is wrong?
21:13 < tgrabiec> penberg_home: target_method of invokevirtual exoression is resolved incorrectly
21:14 <@penberg_home> tgrabiec: hmm?
21:14 <@penberg_home> tgrabiec: isn't the whole point of invokevirtual that you don't know the receiver?
21:14 < tgrabiec> I mean it shows: target_method: [0x806c528 'java/lang/Object.toString()Ljava/lang/String;' (3)]
21:15 < tgrabiec> hmm, interesting
21:15 <@penberg_home> tgrabiec: yes, but that should be fine, shouldn't it?
21:15 <@penberg_home> if you do object.toString() but the receiver type is String
21:15 < tgrabiec> oh, right
21:15 <@penberg_home> we should invoke String.toString()
21:15 <@penberg_home> which means that vtables are not working as expected
21:15 <@penberg_home> and AFAICT, the only way that can happen is because object.class is wrong?
21:16 < tgrabiec> obj->class is correct, in my trace it prints java.lang.String as object's class name
21:16 <@penberg_home> so then the _vtable_ is set up improperly?
21:17 < tgrabiec> probably, investigating now
21:17 <@penberg_home> the vtable should have a trampoline to String.toString()
21:23 < tgrabiec> i thing setup_vtable() in vm/class.c is wrong
21:23 < tgrabiec> it never overwrites superclass's vtable entries
21:23 < tgrabiec> vegard: ?
21:26 < tgrabiec> it seems to create a new vtable entry for every method in the class
21:29 < tgrabiec> here's the simple test case http://pastebin.com/d60ff075a
21:46 < vegard> ahh
21:46 < vegard> so that's what vtables are for
21:46 < vegard> erm, did I just write that?
21:47 < vegard>  did you fix it already, or? :D
21:48 < tgrabiec> vegard: no, i'm trying to figure out how methods are resolved
21:49 < tgrabiec> i don't think I'll fix it today, because I am appointed at 10pm ;)
21:49 < vegard> fwiw, that probably explains what's wrong with PrintTest as well.
21:49 < tgrabiec> possibly. vegard, i think it's the top priority now to fix :)
21:50 < vegard> yes, definitely.
21:50 < vegard> like you say, it's probably setup_vtable() + the end of vm_link_class
21:52 < vegard> ah, no, just setup_vtable() I think
21:58 < vegard> I'll write an InvokeVirtualTest
22:00 <@penberg_home> vegard: there's MethodInvocationTest
22:00 <@penberg_home> I wonder why that doesn't catch this.
22:00 < vegard> ah
22:01 < vegard> btw
22:02 < vegard> I'd prefer smaller test classes
22:02 < vegard> because it's easier to figure out what fails
22:03 <@penberg_home> thats ok
22:03 <@penberg_home> just saying we already have one
22:03 <@penberg_home> you can write new one
22:03 <@penberg_home> maybe remove the old one
22:04 < vegard> it works; it fails
22:04 < vegard> http://pastebin.com/m142ef15c
22:05 <@penberg_home> vegard: cool
22:05  * penberg_home is off to zzz land.
22:12 < vegard> night!
22:53 < vegard> vtable works :)
22:53 < vegard> well... my test case works
22:53 < vegard> dunno if this is completely by the book...
22:59 < tgrabiec> vegard: can you show the patch ?
22:59 < vegard> yep, just e-mailed it
23:00 < vegard> you were on Cc
23:00 < vegard> I thought you had an appointment :)
23:00 < vegard> probably this patch is still slightly wrong; for example I don't check for abstract/final/private/protected/etc. flags
23:01 < vegard> but it should be an overall improvement.
23:02 < tgrabiec> well, "appointment" is probably not the best word... i'm at home drinking shampane with my wife ;)
23:06 < vegard> ahh
23:06 < vegard> and on irc at the same time? :p
23:06 < vegard> I didn't know you were married!
23:07 < tgrabiec> well i just dropped by for a moment ;)
23:22 < vegard> do we need a vtable for fields as well?
23:22 < vegard> hm, I guess not. they are just accumulated, aren't they?
--- Log closed Tue Jun 30 00:00:16 2009