--- Log opened Mon Aug 17 00:00:46 2009
01:05 -!- tgrabiec [n=tomekg@bdg11.neoplus.adsl.tpnet.pl] has quit [Remote closed the connection]
03:43 < Eduard_Munteanu> Can someone take a look at arch/x86/unwind_32.S? I think we modify %ecx erroneously.
03:44 < Eduard_Munteanu> By the time we reach unwind, %ecx is no longer saved on stack, so modifying it is bound to cause errors.
03:45 < Eduard_Munteanu> Blah, sorry, forget about that, it's not saved on x86-32 :)
03:45 < Eduard_Munteanu> No problem, false alarm.
03:58 < pippijn> :-)
05:16 -!- Eduard_Munteanu [n=edi@188.25.244.71] has quit ["Lost terminal"]
08:04 -!- Eduard_Munteanu [n=edi@188.25.244.71] has joined #jato
08:04 < Eduard_Munteanu> Hi.
08:07 < Eduard_Munteanu> Hm, we have a problem with enter/exit monitors on x86-64. The register that holds *this gets clobbered by the time we reach the exit monitor.
08:08 < Eduard_Munteanu> Use-def doesn't help, since it's not insn-selected code.
08:08 < Eduard_Munteanu> Perhaps we could generate STMT_MONITOR_EXIT for every method at the end?
08:09 < Eduard_Munteanu> *every synchronized method
08:11 < Eduard_Munteanu> We'd also get rid of emit_lock() et al. AFAICS.
08:16 -!- penberg [n=penberg@sidedoor.reaktor.fi] has joined #jato
08:16 < Eduard_Munteanu> penberg, hi.
08:16 < penberg> Eduard_Munteanu: hi
08:16  * Eduard_Munteanu repeating myself...
08:16 < Eduard_Munteanu> Hm, we have a problem with enter/exit monitors on x86-64. The register that holds *this gets clobbered by the time we reach the exit monitor.
08:16 < penberg> Eduard_Munteanu: yeah?
08:16 -!- penberg [n=penberg@sidedoor.reaktor.fi] has quit [Client Quit]
08:17 < Eduard_Munteanu> Could we generate STMT_MONITOR_EXIT for every method at it's end? We'd also get rid of emit_lock() et al.
08:18 < Eduard_Munteanu> Damn :)
08:18 -!- penberg [n=penberg@sidedoor.reaktor.fi] has joined #jato
08:18 < penberg> Eduard_Munteanu: mhm, lost connectio
08:18 < Eduard_Munteanu> penberg, oh.
08:18 < penberg> Eduard_Munteanu: we can't save and restore it in prolog?
08:19 < penberg> Eduard_Munteanu: (penberg_home is physically _at_ home, so I don't see it now)
08:19 < Eduard_Munteanu> penberg, mm, yeah, but I'd rather not do things in prolog that need to be cleaned up by some other code.
08:19 < Eduard_Munteanu> penberg, but could we generate STMT_MONITOR_* for every synced method?
08:20 < Eduard_Munteanu> That way we get rid of emit_lock and all that stuff I think.
08:20 < Eduard_Munteanu> The trouble is we lose *this because the clobbering is not solved by use-def, since that exit monitor isn't selected per se.
08:21 < penberg> Eduard_Munteanu: I am fine with that if it doesn't break 32-bit
08:21 < penberg> Eduard_Munteanu: you might want to talk to tomek about it
08:21 < penberg> Eduard_Munteanu: it's probably okay
08:21 < Eduard_Munteanu> penberg, okay, thanks. I was making sure there's no 1-to-1 mapping to bytecode policy for the tree statements.
08:22 < penberg> Eduard_Munteanu: oh, no, we already do "complex statements and instructions"
08:22 < Eduard_Munteanu> I see.
09:00 -!- penberg [n=penberg@sidedoor.reaktor.fi] has quit ["Lost terminal"]
09:02 -!- penberg [n=penberg@sidedoor.reaktor.fi] has joined #jato
09:16 -!- tgrabiec [n=tomekg@biz139.neoplus.adsl.tpnet.pl] has joined #jato
09:18 < Eduard_Munteanu> tgrabiec, hi.
09:18 < tgrabiec> hi
09:19 < Eduard_Munteanu> tgrabiec, I was talking to penberg about generating STMT_MONITOR_* statements instead of call emit_lock_this() et. al directly. On x86-64, since those are not selected, I get the *this reg clobbered.
09:20 < Eduard_Munteanu> tgrabiec, for now I solved it by modifying the prolog/epilog. Could stay that way, but it's a bit less elegant I think. What's your take on this?
09:20 < Eduard_Munteanu> s/selected/insn-selected/
09:21 < tgrabiec> Eduard_Munteanu: I'm perfectly fine with selecting STMT_MONITOR_, but we must solve the exit block - currently exit block is not connected to any blocks, so liveness analysis and other do not work there
09:22 < tgrabiec> it will probably require modification in liveness analysis
09:22 < tgrabiec> but we should do this
09:22 < tgrabiec> putting this into prolog/epilog was a lazy solution to avoid problems some time ago
09:22 < Eduard_Munteanu> tgrabiec, hm, I think I noticed that myself when I inserted a superfluous insn in the attempt of making the insn selector care about my *this.
09:23 < Eduard_Munteanu> tgrabiec, well, this is x86-64 specific, since we get *this in %rdi. It's not a general issue.
09:24 < Eduard_Munteanu> Well, I think I'll just leave it at prolog/epilog then.
09:24 < tgrabiec> I think we need to connect exit block, if we want callee saved registers to be restored there basing on liveness analysis
09:24 < tgrabiec> we want to get rid of explicit save/restore
09:25 < Eduard_Munteanu> tgrabiec, I don't think we can. The <arch> ABI won't allow it and it will botch external code calling our code (JNI).
09:26 < tgrabiec> hmm, what do you mean?
09:27 < tgrabiec> the idea is to only save when register is actually scratched in method
09:27 < Eduard_Munteanu> tgrabiec, a() calls b() which calls c(). b() can't selectively save regs because: 1. it doesn't know what a() expects; 2. it doesn't know what c() modifies.
09:28 < tgrabiec> b() might expect that c() will not scratch calee saved regs
09:29 < tgrabiec> so if b() does not modify edi, then it can skip saving/restoring it, because c() is not allowed to scratch it
09:29 < Eduard_Munteanu> tgrabiec, oh, yes, if it happens locally to everybody, it applies globally. I get the idea now.
09:30 < Eduard_Munteanu> So if everybody behaves, yes, everything works :)
09:31 < Eduard_Munteanu> tgrabiec, then I'll leave it to the prolog to handle it. Thanks.
09:32 < tgrabiec> well, for the time being, there is no other way. we must fix CFG first.
09:33 < tgrabiec> Eduard_Munteanu: is there a problem in  arch/x86/unwind_32.S ?
09:34 < tgrabiec> ah, false alarm
09:34 < Eduard_Munteanu> tgrabiec, yes, false alarm. Though there were problems in unwind_64.S, fixed that.
09:34 < Eduard_Munteanu> (which was my code)
10:04 < Eduard_Munteanu> tgrabiec, how does the valgrind bug manifest itself? Bogus errors, malfunction or what should I expect?
10:06 < tgrabiec> valgrind bug? it complains about accessing stack, when stack trace is constructed. then it terminates application if we modify signal handler return address, so it kills application after first exception thrown from SIGSEGV
10:07 < Eduard_Munteanu> I see, thanks.
10:19 < tgrabiec> vegard: ping
10:41 < penberg> tgrabiec:
10:41 < penberg> +       if (vm_type == J_CHAR || vm_type == J_BYTE ||
10:41 < penberg> +           vm_type == J_SHORT || vm_type == J_BOOLEAN)
10:41 < penberg> can we get a helper function for this?
10:41 < penberg> and a regression test for the fix?
10:41 < tgrabiec> sure
10:42 < tgrabiec> any suggestions for the helper name ?
10:43 < penberg> tgrabiec: mimic_stack_type() ?
10:43 < penberg> that does the conversion?
10:43 < tgrabiec> sounds good
11:30 < Eduard_Munteanu> FWIW, I think that goes well with a switch-case fallthrough, especially if there are other cases.
11:49 < penberg> tgrabiec: I'll just squash all the patches together?
11:56 < CIA-56> Pekka Enberg master * rff14b74 / (6 files in 6 dirs): (log message trimmed)
11:56 < CIA-56> jit: fix expression type for EXPR_INVOKE*
11:56 < CIA-56> When method returns char, byte, boolean or short then int value should
11:56 < CIA-56> be pushed on mimic stack. Primitive types listed above do not occur
11:56 < CIA-56> in java stack. They are always converted to int implicitly.
11:56 < CIA-56> This caused failed assertion for the following method:
11:56 < CIA-56> jato: jit/typeconv-bc.c:56: convert_truncation: Assertion failed `from_expression->vm_type == J_INT'.
11:58 < penberg> ahuillet: I was reading the register allocator *paper* last night
11:58 < penberg> ahuillet: To allow ranges that do not extend to the next instruction, the instruction numbers are always incremented by 2, i.e. only even numbers are used. Therefore, the ranges from 16 to 17 do not interfere with the allocation of i4 starting at 18. Additionally, the numbering by two allows the allocator
11:58 < penberg> to insert spill loads and stores at odd positions between two instructions.
11:58 < penberg> is that a problem for us?
11:59 < penberg> ahuillet: also, range.end is *exclusive* so I think we need something like this: http://pastebin.com/m6a0d1dbc
11:59 < penberg> ahuillet: also2, I don't think we put anything on the inactive list
11:59 < penberg> ahuillet: something like this http://pastebin.com/m27a496dc could work
11:59 < penberg> ahuillet: (I think it didn't work, though, when I tried it last night)
12:07 -!- tgrabiec [n=tomekg@biz139.neoplus.adsl.tpnet.pl] has quit [Read error: 110 (Connection timed out)]
13:12 -!- Eduard_Munteanu [n=edi@188.25.244.71] has quit ["Lost terminal"]
13:38 -!- tgrabiec [n=tomekg@aemw69.neoplus.adsl.tpnet.pl] has joined #jato
14:42 < tgrabiec> penberg: ping
14:42 <@ahuillet> mmh
14:43 <@ahuillet> I learnt about Bull's recruitment methods
14:43 <@ahuillet> now my motivation is below zero
14:43 < tgrabiec> ahuillet: share with us
14:44 <@ahuillet> so, where to start
14:44 <@ahuillet> my mentor leads a ~10 people team
14:44 <@ahuillet> but he only takes care of the technical aspects and his boss does the project management
14:45 <@ahuillet> anyway what they want to hire somebody they ask higher management
14:45 <@ahuillet> which says "ok, you can hire someone this fortnight"
14:45 <@ahuillet> but if it takes you more than 14 days you may or may not be able to hire the guy after that
14:45 <@ahuillet> so they have two weeks to pick a guy, every time
14:45 <@ahuillet> and apparently they have no resume archive of e.g. past interns
14:46 <@ahuillet> so if they see someone good, it's no easy for them to hire him
14:46 <@ahuillet> (that's what worries me a bit, given that my career plan includes a few years at Bull for starters)
14:46 <@ahuillet> now, when they hire someone, they don't do it directly
14:47 <@ahuillet> but it goes through computer engineering service companies (rough translation)
14:47 <@ahuillet> we call them "meat boxes"
14:47 <@ahuillet> basically those companies rent employees
14:47 <@ahuillet> as a result, they mostly get not-too-competent people
14:47 <@ahuillet> because the competent guys don't go to these companies
14:47 <@ahuillet> and mmh
14:48 <@ahuillet> I don't know, I'm kind of unstructured here
14:48 < tgrabiec> sounds bad
14:48 <@ahuillet> the point is 1-the policy seems to be a disaster 2-my chances of being hired are low, not because of my profile but because of their policy
15:00 < penberg> tgrabiec: pong
15:01 < tgrabiec> penberg: what do you think about reusing VM instance for all regression tests? class dependencies slow down tests greatly
15:01 < tgrabiec> as the number of classes increases
15:01 < penberg> tgrabiec: we can do that, sure
15:01 < penberg> OTOH, vm startup time is relevant anyway
15:01 < penberg> so I wonder if we should look into optimizing that instead?
15:01 < penberg> like ahead-of-time compilation for preloaded classes?
15:02 < penberg> reusing the vm instance just hides the real problem.
15:02 < penberg> ahuillet: heh, big corporations and all that :)
15:02 <@ahuillet> penberg : big corporations usually have good skill tracking of job applicants etc.
15:02 <@ahuillet> here they just throw resumes in the trash can
15:03 <@ahuillet> then they cry that they can't find more than three applicants for a job
15:03 <@ahuillet> and they all hire them through a meat box
15:13 < penberg> ahuillet: not my experience FWIW
15:13 < penberg> ahuillet: big corporations suck at most things
15:13 < penberg> because of all the red tape
15:13 <@ahuillet> red tape?
15:13 < penberg> bureaucracy
15:14 <@ahuillet> well, many companies don't just throw away resumes :)
15:14 <@ahuillet> ST Microelectronics did call me back three months after they heard of me
15:14 < penberg> :)
15:14 <@ahuillet> it was another branch at a different location, and their proposition was not interesting
15:14 <@ahuillet> but at least they knew about me
16:01 -!- penberg [n=penberg@sidedoor.reaktor.fi] has quit ["leaving"]
16:55 < penberg_home> ahuillet: hey did you see my comments on the register allocator?
16:55 < pippijn> good morning
16:56 < penberg_home> ahuillet: http://pastebin.com/m6f6933dd
16:56 < penberg_home> ahuillet: I'm going out for jogging now, will be back in a hour or so
16:56 < pippijn> how are things going?
16:56 < penberg_home> pippijn: hiya
16:56 < penberg_home> pippijn: fine thanks, gotta run! later
16:56 < pippijn> okay, cya
16:56 < pippijn>  22 files changed, 431 insertions(+), 126 deletions(-)
16:56  * pippijn tests
16:58 < pippijn> okay
16:58 < penberg_home> pippijn: btw, your bind.jar loops in bb_last_insn() (the loop there looks fishy)
16:58  * penberg_home is off for real now!
16:58 < pippijn> ah
20:24 < penberg_home> tgrabiec: ouch, I am blind :)
20:31 < CIA-56> Tomek Grabiec master * r23c3597 / (7 files in 5 dirs):
20:31 < CIA-56> vm: introduce per vm_class access flags.
20:31 < CIA-56> We need to assign access flags for arrays and primitive classes which
20:31 < CIA-56> have no corresponding cafebabe_class. Therefore ->access_flags field is
20:31 < CIA-56> introduced for struct vm_class.
20:31 < CIA-56> Signed-off-by: Tomek Grabiec <tgrabiec@gmail.com>
20:31 < CIA-56> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi> - http://bit.ly/YSAeh
20:39 < tgrabiec> penberg_home: the method resolving failure bug which I posted today on list is a blocker for JDarkRoom and JPC
20:39 < penberg_home> tgrabiec: oh yeah, let me have a look at that
20:39 < penberg_home> I wonder where vegard went.
20:40 < penberg_home> tgrabiec: javap generates invokeinterface for the test, right?
20:40 < tgrabiec> it is kinda tricky bug. we try to resolve a method which is inherited from interface by an abstarct class, which provides no implementation for it
20:41 < penberg_home> tgrabiec: is it invokeinterface or invokevirtual?
20:41 < tgrabiec> penberg_home: nope, invokevirtual
20:41 < tgrabiec> that's the point
20:41 < penberg_home> hmm?
20:41 < penberg_home> abstract class A implements X {
20:41 < penberg_home> so do we have the method in A vtable?
20:41 < tgrabiec> we don't, because A does not provide implementation
20:42 < tgrabiec> I think we should create one
20:42 < tgrabiec> but I'm not sure it is the only and the best option
20:42 < tgrabiec> once A inherits X, method x() should be given a vtable slot
20:44 < penberg_home> tgrabiec: what does the spec say?
20:44 < tgrabiec> I didn't find anything that could help
20:45 < penberg_home> AFAICT, invokeinterface instruction description should tell us what to do
20:45  * penberg_home is reading.
20:45 < tgrabiec> it seems, that once interface X gets inherited by A, method x() becomes a part of A, and is invoked via invokevirtual
20:45 < penberg_home> tgrabiec: I'd just like to see the relevant text in the jvm spec.
20:46 < tgrabiec> sure
20:46 < tgrabiec> let's find one
20:46 < penberg_home> tgrabiec: maybe it's a classloading bug?
20:46 < penberg_home> I just want to understand what the JVM specification thinks should happen here.
20:46 < penberg_home> so we an figure out how to fix it
20:47 < penberg_home> vegard: feel free to drop into the discussion go and change your code :)
20:48 < penberg_home> 2.10 ("Methods") says: A class inherits from its direct superclass (?2.8.3) and any direct superinterfaces (?2.13.2) all the accessible methods of the superclass and superinterfaces, with one exception: if a name is declared as a method in the new class, then no method with the same signature (?2.10.2) is inherited.
20:49 < penberg_home> tgrabiec: so how do we deal with normal inheritance now wrt. vtables?
20:50 < penberg_home> AFAICT, we just need to add a "go through interfaces" and put them on the _vtable_ as well?
20:50 < tgrabiec> penberg_home: if non abstract class inherits an interface, then it _must_ declare all methods
20:51 < penberg_home> tgrabiec: sure
20:51 < penberg_home> but AFAICT
20:51 < penberg_home> setup_vtable() should just walk the known superinterfaces _after_ all the methods have been traversed
20:52 < penberg_home> and add interface methods that are not implemented to the vtable.
20:52 < penberg_home> sure would be nice to hear from vegard
20:52 < penberg_home> but AFAICT, that's the proper way to fix this
20:52 -!- tgrabiec [n=tomekg@aemw69.neoplus.adsl.tpnet.pl] has quit [Read error: 60 (Operation timed out)]
21:08 -!- tgrabiec [n=tomekg@bue232.neoplus.adsl.tpnet.pl] has joined #jato
21:18 < penberg_home> tgrabiec: I think there could be some memory corruption in struct insn
21:18 < penberg_home> I see a totally crazy ->lir_pos
21:18 < penberg_home> tgrabiec: with pippijn's bind.jar
21:22 < tgrabiec> penberg_home: I've lost connection, after reading the logs I must say, that I thought about the same solution you proposed. But I think vegard should implement it because it is kinda invasive
21:23 < penberg_home> tgrabiec: maybe, yeah
21:23 < penberg_home> tgrabiec, ahuillet: the whole bb_last_insn() seems fishy and dangerous
21:24 < penberg_home> we keep checking ->lir_pos which have never been assigned...
21:24 < penberg_home> because compute_positions() happens before we start inserting spill and reload insns.
21:24 <@ahuillet> :/
21:24 < penberg_home> there could be some memory corruption going on too as ->lir_pos is initialized to zero
21:24 < penberg_home> but I see bb_last_insn() reading a totally crazy *big* value.
21:25 < penberg_home> anyway, simple to reproduce with bind.jar from pippijn
21:25 < penberg_home> I'm not completely sure why the loop is there, it seems we should be tracking the "last insn" manually in struct basic_block.
21:27 < penberg_home> oh well, time for me to review some more register allocator code and then get some sleep
21:27 < pippijn> the jewelvm guy answered
21:28 < penberg_home> tgrabiec: we can wait for vegard to fix it but he seems to be missing in action
21:28 < penberg_home> tgrabiec: so you can also just fix it up
21:28 < pippijn> he's very positive
21:28 < pippijn> which is surprising
21:28 < tgrabiec> penberg_home: I think I'll wait one day more or so
21:28 < penberg_home> tgrabiec: yeah, makes sense.
21:32 < tgrabiec> bind.jar takes ages to execute here, it's running over a minute here and printed just "Hi there!", no crash so far
21:34 < penberg_home> tgrabiec: yes it spins like crazy in bb_last_insn()
21:35 < penberg_home> tgrabiec: print out ->lir_pos in the loop and you'll see what I mean.
22:03 < pippijn> tgrabiec: does it even finish?
23:15 < tgrabiec> pippijn: I didn't wait for it to finish, I killed it
23:15 < pippijn> yeah
23:15 < pippijn> so did I
23:15 < pippijn> assuming it was an infinite loop
23:28 -!- tgrabiec [n=tomekg@bue232.neoplus.adsl.tpnet.pl] has quit ["Leaving"]
--- Log closed Tue Aug 18 00:00:46 2009