--- Log opened Mon Jul 13 00:00:56 2009
00:05 < vegard> huh, what's that?
00:06 < vegard> aha.
01:15 -!- tgrabiec [n=tomekg@apn113.neoplus.adsl.tpnet.pl] has quit ["Leaving"]
10:42 -!- penberg [n=penberg@xdsl-83-150-86-196.nebulazone.fi] has joined #jato
10:42  * penberg is back
10:43 -!- mode/#jato [+o penberg] by ChanServ
11:34 -!- tgrabiec [n=tomekg@biw234.neoplus.adsl.tpnet.pl] has joined #jato
11:35 <@penberg> tgrabiec: so, you're done?
11:38 < tgrabiec> penberg: I don't think so
11:38 <@penberg> tgrabiec: ok, so what's up next?
11:38 <@penberg> great work btw ;)
11:39 < tgrabiec> penberg: I have to solve the stack traces with JNI functions problem
11:40 <@penberg> oh, okay.
11:40 <@penberg> but all the exception handling code is functional, right?
11:41 < tgrabiec> I think so, maybe I could do some optimizations
11:41 < vegard> oh, I have a request :-)
11:42 <@penberg> tgrabiec: http://jato.lighthouseapp.com/projects/29055/tickets/2-lack-of-icache-invalidation-on-code-cross-modyfication
11:42 <@penberg> :-)
11:42 < vegard> can we have a command-line option that instead of doing the null checks (and other stuff; I can do the getstatic/putstatic stuff for sure) by signals does it "manually"?
11:42 < tgrabiec> penberg: right :)
11:42 < vegard> so that we can run jato under valgrind
11:42 <@penberg> vegard: why do we want that?
11:43 <@penberg> vegard: hmmh
11:43 < vegard> just for the sake of debugging
11:43 <@penberg> hmmhm
11:43 <@penberg> no?
11:43 <@penberg> what's the _real_ problem there?
11:43 < vegard> that valgrind delivers signals differently from the kernel
11:43 < vegard> or something like that.
11:44 < vegard> afaics, both the EIP and the non-present address are reported accurately
11:44 <@penberg> so is that a bug in our code? are we depending on some behavior that we should not depend on?
11:44 < vegard> valgrind claims that we're corrupting the stack frame
11:45 < vegard> (it puts a few magic constants in there and checks them on return-from-handler iirc)
11:45 <@penberg> I am not too keen on adding stuff like this to our code generation
11:45 <@penberg> because if it's a bug in our signal handling code, we need to fix that
11:45 <@penberg> and if it's valgrind bug, we should look into fixing that instead.
11:46 <@penberg> it's usually a bad idea to let debug and production builds differ.
11:46 < vegard> ok. in either case it would be really great to have it working again ;)
11:46 <@penberg> from testing coverage point of view.
11:46 <@penberg> vegard: yes, strongly agreed.
11:46 <@penberg> tgrabiec: btw, I suspect safepoints are pretty straight-forward to do now that we have all that signal handling infrastructure in place.
11:47 < tgrabiec> penberg: probably they are
11:47 <@penberg> tgrabiec: otoh, there are some low-hanging fruits there like "wide instructions"
11:48 <@penberg> which will probably take less than a day to do
11:48 < vegard> k, I'm off, bye! :)
11:48 <@penberg> vegard: bye!
11:48 <@penberg> aren't you travelling to germany?
11:49 < vegard> yes, now :)
11:49 < tgrabiec> have a nice trip
11:49 <@penberg> oh! have a good one!
11:49 < vegard> thanks
11:49 <@penberg> vegard: did you do your gsoc stuff?
11:49 <@penberg> the evaluation thingy?
11:49 < vegard> yes
11:49 <@penberg> ok!
11:49 < vegard> submitted.
11:49 <@penberg> see ya!
11:52 < tgrabiec> penberg: I'm going to use an exception test after each JNI native call to check for exception. It seems to be the best way
11:53 <@penberg> tgrabiec: did you check what hotspot does+
11:54 <@penberg> I'm fine with that, just curious.
11:54 <@ahuillet> hello
11:54 <@penberg> seems like an awful lot of overhead, doesn't it? then again, nobody seems to like JNI ;)
11:54 <@penberg> ahuillet: salut!
11:54 < tgrabiec> penberg: I didn't. but we have to do some "catching", because exceptions can be signalled inside JNI but not "thrown"
11:55 <@penberg> tgrabiec: but isn't that what we do with our native funtions too?
11:56 <@penberg> tgrabiec: shouldn't we use the same mechanism there?
11:56 <@penberg> (there = jni)
11:57 < tgrabiec> well, we could create a stub for JNI calls, but that would add significant overhead on non-exceptional flow
11:58 < tgrabiec> I think that hotspot have two mechanisms: check-by-SIGSEGV-trigger and explicit-test-and-branch. It gathers statistics and if exceptions seem to happen often then the latter approach is injected to avoid frequent signals
11:59 <@penberg> tgrabiec: oh, interesting!
11:59 <@penberg> tgrabiec: hmm, I'm not sure I follow.
11:59 < tgrabiec> that's in general, not JNI specific
12:00 <@penberg> tgrabiec: why is JNI exception handling different from how we do it in native code?
12:00 <@penberg> aah
12:00 <@penberg> throw_from_native()
12:00 < tgrabiec> penberg: because in VM native code we can call throw_from_native() explicitly, and when we call JNI native we have no control on what's happending there
12:00 <@penberg> yeah, I forgot about that part.
12:01 <@penberg> I wonder if we should get rid of throw_from_native() too hmm hmm hmm
12:01 < tgrabiec> penberg: I was thinking about that too. It causes some problems
12:01 <@penberg> tgrabiec: I just don't like the fact that we have two slightly different exception handling mechanisms for native code.
12:02 <@penberg> tgrabiec: yup, I think we should unify the JNI and the "vm native" cases.
12:02 < tgrabiec> throw_from_native() is faster when exceptions occure, but i think that we should do something like hotspot does  to handle this
12:02 <@penberg> tgrabiec: agreed.
12:03 < tgrabiec> but we don't have code patching infrastructure yet
12:04 < tgrabiec> I really need to find out why hotspot doesn't care about that XMC CPU bug
12:21 <@penberg> bug in hotspot?-)
12:22 < tgrabiec> don't know. If it is, it would be nice to find affected machine and write a test
12:24 <@penberg> probably hard to trigger
12:27 <@ahuillet> I'll be back to work on tuesday
12:27 <@ahuillet> but only for two or three days
12:27 <@ahuillet> I expect to solve the regallocator issue within this timeframe
12:28 <@penberg> cool
12:28 <@penberg> I guess that's blocking S.o.println() at the moment?
12:28 <@ahuillet> indeed
12:28 <@ahuillet> it's not very easy to solve though
12:28 <@ahuillet> I threw away all my prototype I think
12:31 <@penberg> :)
13:12 -!- Eduard_Munteanu [n=edi@79.115.194.125] has joined #jato
13:12 < Eduard_Munteanu> Hi.
13:13 < Eduard_Munteanu> penberg, you're back :).
13:14 <@penberg> Eduard_Munteanu: yeah!
13:14 <@penberg> salut!
13:17 < Eduard_Munteanu> penberg, from the "while you were away series"... I fixed argument passing on x86-64. I still need to finish fixing argument cleanup.
13:17 < Eduard_Munteanu> and found a way to ifdef in monoburg.
13:23 <@penberg> Eduard_Munteanu: nice!
13:24 <@penberg> Eduard_Munteanu: I assume you haven't sent the series?
13:24 <@penberg> (not in my inbox, anyway)
13:24  * penberg hopes everyone has done their gsoc evaluation thingy
13:24 <@penberg> the deadline is today IIRC
13:24 < Eduard_Munteanu> penberg, no, I'll send it after I finish the args cleanup stuff.
13:24  * Eduard_Munteanu did it.
13:25 < Eduard_Munteanu> penberg, that is, so we have some results measurable in working tests.
13:26 <@penberg> yeah, that's really cool
13:30 < Eduard_Munteanu> penberg, btw, if I create .c file, the corresponding header should be split in an arch and non-arch stuff?
13:30 < Eduard_Munteanu> I mean, code meant to be called from jit/ should be declared somewhere in include/jit/ and arch stuff in arch/.../, or doesn't it matter so much?
13:35 <@penberg> well, depends.
13:36 <@penberg> sometimes we want to call arch ("arch") code from generic code ("jit")
13:36 <@penberg> and sometimes we have generic _headers_ but the implementation is always arch-specific
13:38 < Eduard_Munteanu> penberg, okay, will do my best and you decide :).
13:38 <@penberg> :)
13:54 < Eduard_Munteanu> penberg, what license comment should I copy in? Preferably the large one including the linking exception?
13:54 < Eduard_Munteanu> I see some arch code merely mentions GPLv2.
13:57 <@penberg> Eduard_Munteanu: gplv2 + linking exception
13:57 <@penberg> those with just gplv2 are there for historical reasons
13:57 <@penberg> Jato is licensed under GPLv2 + linking exception.
13:57 <@penberg> JamVM used to be GPLv2-only
14:00 < Eduard_Munteanu> penberg, ok, thanks.
14:27 <@ahuillet> Eduard_Munteanu : btw, it seems you broke make test on x86
14:28 <@penberg> ahuillet: works here.
14:29 < Eduard_Munteanu> ahuillet, penberg, the cafebabe tests are broken for me on _x86-64_
14:29 < Eduard_Munteanu> Didn't know it was an issue on x86-32, will investigate.
14:29 < tgrabiec> it fails here with lots of: "../../arch/x86/insn-selector_32.c:1084: error: too few arguments to function ‘get_var’
14:29 <@ahuillet> same here
14:30 <@penberg> ahuillet: x86?
14:30 <@penberg> 32-bit
14:30 <@ahuillet> yup
14:30 <@penberg> impossible ;)
14:31 <@penberg> aah
14:31 < Eduard_Munteanu> ahuillet, penberg, did you do a "make clean"? Sometimes the build system gets things wrong.
14:31 <@penberg> I did. it works for me.
14:31 <@penberg> there's no insn-selector_32.c in jato anymore
14:32 < Eduard_Munteanu> Right.
14:32 <@penberg> git clean -x -f (but be careful, untracked files are removed!)
14:33 < Eduard_Munteanu> It's not necessary as long as you do 'make clean'. I still have that _32.c and _64.c lying around with no issues.
14:33 <@penberg> but anyway, it's not broken.
14:33 < tgrabiec> Eduard_Munteanu: I had done make clean, and it didn't help
14:33 < tgrabiec> after penberg's advice it's ok now
14:34 < Eduard_Munteanu> Hm, sounds weird, probably the test/ Makefiles are stranger.
14:35 <@penberg> test/arch-i386/Makefile is broken
14:37 <@penberg> fixed now
16:37 -!- penberg [n=penberg@xdsl-83-150-86-196.nebulazone.fi] has quit [Read error: 113 (No route to host)]
19:20 -!- penberg_home [n=penberg@cs149038.pp.htv.fi] has joined #jato
19:28 < Eduard_Munteanu> ahuillet, whoa! http://freegamer.blogspot.com/2009/07/0-ad-now-open-source.html
20:05 < Eduard_Munteanu> Ouch, it ain't gonna be easy to coerce Jato into accepting reg params.
20:09 < Eduard_Munteanu> penberg_home, what does iload_n do? Load the nth _argument_?
20:09 < Eduard_Munteanu> If so, my job is a lot easier :)
20:10 < penberg_home> iload_n loads the nth _local variable_
20:11 < penberg_home> but arguments are passed as local variables too
20:11 < penberg_home> Eduard_Munteanu: check out the jvm instruction set for better explanation ;)
20:11 < Eduard_Munteanu> penberg_home, thanks.
20:28 < tgrabiec> penberg_home: "[PATCH] regression: introduce regression tests written in java bytecode", what do you think ?
20:28 < penberg_home> tgrabiec: looks good
20:28 < penberg_home> not sure if the "jasmin" package is required.
20:30 < tgrabiec> it's not necessary
20:35 < penberg_home> yeah, I'll probably drop that
20:35 < penberg_home> but the test is more than welcome, obviously!
20:48 < penberg_home> haha, evaluation deadline extended
20:48 < penberg_home> because not everyone has done it ;)
21:37 < Eduard_Munteanu> penberg_home, my problem is as follows: when entering a method, we find some parameters in regs, not on the stack. Any thoughts on how to "preallocate" those regs for operations?
21:37 < penberg_home> get_fixed_var() probably
21:38 < Eduard_Munteanu> penberg_home, sure, but how do we tell the insn-selector he should find those values in regs without any STMT_STORE?
21:39 < penberg_home> well, you know which arguments are in regs and which are in locals
21:39 < penberg_home> so use EXPR_VAR for the first n arguments?
21:39 < penberg_home> at fixed location?
21:39 < Eduard_Munteanu> penberg_home, EXPR_VAR?
21:40 < penberg_home> EXPR_TEMPORARY
21:41 < Eduard_Munteanu> penberg_home, yeah, I figured I should modify jit/ostack-bc.c somehow.
21:41 < penberg_home> maybe a arg_expr(int ndx) helper or something?
21:42 < Eduard_Munteanu> penberg_home, yes, and I don't think an insn-selector change will suffice.
21:42 < penberg_home> possibly
21:42 <@ahuillet> 0 AD.. I don't know this game.
21:42 <@ahuillet> I'll check it out
21:42 < Eduard_Munteanu> ahuillet, check the screens ;)
21:42 < Eduard_Munteanu> *screenshots.
21:43 <@ahuillet> looks pretty interesting
21:43 <@ahuillet> and yes, arguments in registers are going to be painful
21:43 < Eduard_Munteanu> ahuillet, probably the first "cool 3d graphics" open-source stuff.
21:43 < Eduard_Munteanu> ahuillet, oh, thanks. :)
21:43 < penberg_home> ahuillet: hmm, not sure why they would be painful.
21:45 <@ahuillet> time to go
21:45 < Eduard_Munteanu> EXPR_LOCAL doesn't give sufficient information and I probably need to fiddle with the mimic stack.
21:45 < Eduard_Munteanu> ahuillet, bye.
21:46 < penberg_home> hmhm?
21:46 < penberg_home> we use EXPR_LOCAL on 32-bit
21:46 < Eduard_Munteanu> penberg_home, yes, but on 32-bit we don't use any register values except for those get_var-ed in the insn-selector.
21:47 < penberg_home> hmm
21:47 < penberg_home> I am not sure what your problem is here.
21:47 < Eduard_Munteanu> but on x86-64 we get those pesky EXPR_LOCALs and EXPR_TEMPORARYs from the bytecode-to-ir layer.
21:48 < penberg_home> hmm hmm hmm
21:48 < tgrabiec> Eduard_Munteanu, do you know which argument index is assigned to each ARG expression ?
21:48 < penberg_home> anyway, as for _arguments_ everything is wrapped in EXPR_ARG
21:48 < penberg_home> so the _instruction selection_ part should be pretty simple.
21:48 < Eduard_Munteanu> tgrabiec, penberg_home, I already solved the argument _passing_ issue. The argument "_getting_" part is more difficult.
21:49 < penberg_home> ok, so you probably need to special-case EXPR_LOCAL
21:49 < penberg_home> if (is_local_arg_and_in_reg(..)) type of thing
21:51 < penberg_home> or something ;)
21:53 < Eduard_Munteanu> penberg_home, yeah, and I also need to generate STMT_STOREs for (EXPR_TEMPORARY, reg) or something like that.
21:53 < penberg_home> for args?
21:53 < penberg_home> why?
21:55 < Eduard_Munteanu> penberg_home, because there should be no explicit mov or store, the value should already be there in a reg.
21:55 < penberg_home> hmm
21:55 < Eduard_Munteanu> penberg_home, remember, this is about a method _recieving_ args.
21:55 < penberg_home> yes
21:55 < penberg_home> so you can just _use_ struct var_info in EXPR_TEPORARY
21:56 < penberg_home> the point is that you set ->reg1 to ->var_info for EXPR_TEMPORARY
21:56 < penberg_home> and then everyone will _use_ the reg automatically
21:56 < penberg_home> so no reg -> reg stores required
21:56 < penberg_home> look at what we do in the 32-bit insn selector.
21:57 < Eduard_Munteanu> penberg_home, hm, thanks, looks like a fine idea. Though I kinda need to research the state stuff.
21:57 < penberg_home> yup
21:57 < penberg_home> it's bit tricky
21:58 < penberg_home> but once you understand how you can "propagate" the register to the other insn selector rules via ->reg1
21:58 < penberg_home> everything makes sense all of a sudden ;)
21:58 < Eduard_Munteanu> penberg_home, ->reg1 is the src value?
21:59 < penberg_home> depends on how you have set it up
21:59 < penberg_home> but yes, that's what we do in 32-bi
21:59 < penberg_home> 32-bit
21:59 < Eduard_Munteanu> penberg_home, oh, thanks a lot :).
21:59 < penberg_home> just check out EXPR_VALUE, for example.
21:59 < penberg_home> and some rule that uses "reg"
21:59 < penberg_home> OP_ADD(reg, ...) for example
22:00 < Eduard_Munteanu> Ok, I was unsure that propagated through the tree once set up.
22:00 < penberg_home> reg:    OP_OR(reg, EXPR_LOCAL) 1
22:00 < penberg_home>         state->reg1 = state->left->reg1;
22:00 < penberg_home> ->left being "reg"
22:01 < Eduard_Munteanu> Yeah, I see.
22:02 < Eduard_Munteanu> penberg_home, btw, we now use %ifdef in the insn-selector since monoburg has a minimal preprocessor.
22:03 -!- ahuillet [n=ahuillet@171.34.83-79.rev.gaoland.net] has quit [Read error: 110 (Connection timed out)]
22:05 -!- tgrabiec [n=tomekg@biw234.neoplus.adsl.tpnet.pl] has quit [Read error: 60 (Operation timed out)]
22:08 < penberg_home> Eduard_Munteanu: sounds good
22:19 -!- tgrabiec [n=tomekg@akt29.neoplus.adsl.tpnet.pl] has joined #jato
--- Log closed Tue Jul 14 00:00:56 2009