--- Log opened Sun Aug 09 00:00:22 2009
01:23 < t_grabiec> 154248 uniqe methods invoked for HelloWorldSwing
01:23 < t_grabiec> so far
01:27 < t_grabiec> omg, HelloWorldSwing showed a titled window !!
01:27 < t_grabiec> and failed with unimplemented JNI
01:32 -!- t_grabiec [n=tomekg@aenf228.neoplus.adsl.tpnet.pl] has quit ["Leaving"]
09:46 -!- tgrabiec [n=tomekg@aenf228.neoplus.adsl.tpnet.pl] has joined #jato
09:53 < penberg_home> tgrabiec: hi!
09:53 < tgrabiec> hi
09:53 < penberg_home> tgrabiec: titled window, eh?-)
09:53 < tgrabiec> yup
09:53 < tgrabiec> I had to implement lookupswitch and a bunch of reflection JNI
09:53 < penberg_home> oh
09:53 < penberg_home> :-)
09:54 < tgrabiec> now it fails with really interesting things
09:54 < penberg_home> yeah?
09:54 < penberg_home> such as?
09:55 < tgrabiec> tetris shows a window and fails: jato: arch/x86/stack-frame.c:101: frame_locals_size: Assertion `frame->nr_local_slots >= frame->nr_args' failed.
09:56 < tgrabiec> HelloWorldSwing fails on unimplemented JNI
09:56 < tgrabiec> I'm cleaning it a bit to get rid of code redundancy
10:10 < penberg_home> tgrabiec: ok cool
10:10 < penberg_home> what's that assert about. let me have a look.
10:11 < penberg> so we have more args than we have locals.
10:13 < vegard> we have both count_arguments() and method_real_argument_count()
10:14 < vegard> both of them are half-magic
10:15 < penberg> tgrabiec: maybe we should add an assertion to alloc_stack_frame()
10:15 < penberg>                         method->args_count,
10:15 < penberg>                         method->code_attribute.max_locals);
10:15 < penberg> maybe that's buggy
10:15 < penberg> I lost track of which method to call to get the "real" count
10:15 < penberg> vegard: yeah!
10:15 < penberg> we should clean that crud
10:15 < penberg> it's a bug waiting to happen.
10:16 < penberg_home> vegard: why RFC for reg_type?
10:16 < vegard> it would be interesting to see what the method signature is, and what the actual values are (for local slots and nr args)
10:16 < penberg_home> vegard: is that patch ok? can I just go ahead and merge it?
10:16 < vegard> penberg_home: um, maybe you're planning to use it for something else in the future
10:17 < penberg_home> not really.
10:18 < vegard> I think I broke x86_64 horribly, but I wanted to wait for eduard
10:21 < penberg_home> vegard: he's offline a bit because apparently his laptop died.
10:22 < penberg_home> vegard: it would be nice to fix up those parts that we can fix.
10:22 < penberg_home> so I'll merge your patch?
10:23 < penberg> vegard: btw, did you see the bug with main(String[] args) ?
10:23 < penberg> that is, we don't support 'args' at all :-)
10:23 < penberg> that blocks SciMark2
10:23 < vegard> I knew it and was planning to fix it
10:23 < penberg> vegard: ah ok, I guess it's not too hard?
10:23 < penberg> http://pastebin.com/m78aac817
10:23 < penberg> I increased the scope of v0.01 a bit
10:24 < penberg> but we can shrink it to the bare minimum if we want.
10:26 < vegard> you think we'll be able to run tris, frozen bubble and scimark2.
10:27 < tgrabiec> that's lots of stuff to do and a lot of bugs to fix
10:27 < penberg_home> :)
10:29 < penberg> tgrabiec: SciMark2 *could* be simple enough as we support the full instruction set.
10:29 < penberg> it's probable that it doesn't use a lot of the fancy features HelloWorldSwing does, for example.
10:29 < penberg> Frozen Bubble, Tris, and HelloWorldSwing have a lot of common problems at the moment.
10:30 < penberg> tgrabiec, vegard: It's really up to you guys what you want the scope of v0.01 to be.
10:30 < penberg> That said, things like main(String[] args) just _needs_ to be fixed :-)
10:30 < penberg> it's a pretty silly limitation :)
10:30 < penberg> (for a real release)
10:30 < penberg> Jato turns 5 years old on 15 September 2009
10:31 < penberg> so I think we're going to do a release before that anyway :)
10:31 < penberg> so don't worry, there's no feature creep here, just trying to figure out what's doable and what's not
10:31 < penberg> it sure would be cool to be able to run all the ones I've listed there!
10:35 < penberg_home> wow
10:35 < penberg_home> competition
10:35 < penberg_home> http://oss.readytalk.com/avian/
10:38 < penberg> uhm
10:38 < penberg> src/compile-x86.S ...
10:39 < penberg> OK, so it's not a serious JIT.
10:39 < tgrabiec> oh, I get now the same for HelloWorldSwing as for Tetris Assertion `frame->nr_local_slots >= frame->nr_args'
10:40 < tgrabiec> ok, time to cleanup and send the patches
10:42 < penberg> tgrabiec: excellent!
10:45 < vegard> btw
10:45 < vegard> what about all those other jvms that exist
10:45 < vegard> how come they're not widely used?
10:45 < vegard> like jam vm, jikes, there were a lot of others too, I think listed on the gnu classpath site
10:45 < vegard> are they incomplete?
10:45 < penberg> vegard: Jikes is a research VM. It's not really suitable for production use.
10:46 < penberg> vegard: JamVM is interpreter only. Try it one day, it's slow as hell.
10:46 < penberg> vegard: Kaffe is just old and crappy. It has *three* JIT engines and none of them work very well.
10:46 < vegard> heh
10:46 < penberg> vegard: CACAO _is_ being used on embedded devices AFAICT.
10:46 < penberg> vegard: the code is just complete shit if you ask me.
10:47 < penberg> vegard: This "avian" thing doesn't even try to support all of Java.
10:47 < penberg> vegard: one big problem is that GNU Classpath is not 100% compatible.
10:47 < penberg> vegard: (which is why CACAO switched to OpenJDK libraries IIRC)
10:48 < penberg> vegard: and the rest are simply not complete enough to be usable
10:48 < vegard> can we support both
10:48 < penberg> vegard: OTOH, _proprietary_ VMs are being used.
10:48 < penberg> the IBM one and Oracle's JRockit, for example.
10:48 < penberg> vegard: yes we can.
10:48 < penberg> vegard: hence the runtime/classpath and runtime/openjdk thing.
10:49 < vegard> why don't we all just use hotspot?
10:49 < penberg> vegard: it didn't support PPC, for example.
10:49 < penberg> I don't think it support PPC that well now either
10:49 < penberg> vegard: it wasn't an open source codebase historically
10:49 < penberg> vegard: it's pretty heavy-weight for embedded, for example.
10:49 < penberg> (nor arm support)
10:50 < penberg> vegard: and they require copyright assignment for major patches.
10:50 < penberg> vegard: so don't expect to be able to hack on hotspot like you do with jato now :)
10:52 < vegard> so it seems
10:53 < penberg> vegard: and oh, you don't have Linux kernel hackers working on the rest :-)
10:53 < penberg> vegard: In all fairness, what we're doing is just absolutely crazy!
10:53 < vegard> the main problem with java is its standard api
10:53 < penberg> writing a JVM from scratch
10:53 < ahuillet> salut
10:53 < vegard> hey, why don't we do an OS next
10:53 < penberg> but it's fun, so why the hell not!
10:53 < penberg> ahuillet: salut!
10:54 < penberg> vegard: what do you mean?
10:54 < penberg> vegard: well, from my point of view, why write an OS from scratch when I can just send patches to Linux?
10:54 < vegard> because it's fun!
10:55 < penberg> Vegax? Pekex?
10:56 < vegard> :-p
11:24 < penberg_home> vegard: oh, nice x86-64 fixes!
11:24 < penberg_home> vegard: tested?
11:24 < vegard> um
11:25 < vegard> it doesn't make x86_64 compile
11:25 < vegard> if that's what you mean
11:25 < penberg> no, what I meant, I guess you found them on x86-64 machine?
11:27 < penberg> oh no, a patch bomb underway!
11:27 < penberg> :)
11:28 < vegard> wow.
11:29 < ahuillet> :)
11:32 < penberg> vegard: can you take a look at the getInterfaces and getSuperClasses patches?
11:32 < penberg> I'm going to apply them but I'd like you to take a peek at them
11:35 < vegard> aha
11:35 < vegard> tgrabiec: the ensure_init is not necessary, I think ?
11:35 < vegard> hm.
11:35 < vegard> I need to think about it.
11:36 < vegard> interfaces don't have initializers...
11:36 < vegard> AFAIK
11:36 < tgrabiec> vegard: it is needed
11:36 < tgrabiec> for ->object
11:37 < penberg> tgrabiec: so what is this used for:  [PATCH 12/19] vm: introduce vm_pointer_type()
11:37 < tgrabiec> penberg: in lookupswitch currently
11:37 < tgrabiec> I had this thought
11:37 < tgrabiec> that we should not allocate J_REFERENCE registers which do not hold references
11:37 < tgrabiec> cause garbage collector might use J_REFERENCE info
11:38 < penberg> tgrabiec: it _will_ use it.
11:38 < penberg> gc maps require that.
11:38 < tgrabiec> so, we need vm_pointer_size() to return J_INT or J_LONG
11:38 < penberg> tgrabiec: are you storing a _pointer_ there?
11:38 < tgrabiec> Im storing branch target, so yes, a pointer
11:38 < penberg> so we need a J_NATIVE_PTR then!
11:39 < penberg> I'll apply the patch but please clean that up.
11:39 < tgrabiec> but J_NATIVE_PTR is not a java type
11:39 < penberg> so?
11:39 < penberg> tgrabiec: +DECLARE_RELEASE_XXX_ARRAY_ELEMENTS(boolean);
11:39 < penberg> nice!
11:39 < tgrabiec> we wil have to put new cases to all those switches
11:40 < tgrabiec> penberg: I'm going to do the same trick with oither JNI
11:40 < penberg> tgrabiec: hmm, yes, so what's the problem with that?
11:41 < penberg> hmmh
11:41 < penberg> INSN_PUSH_MEMBASE seems to be missing...
11:41 < tgrabiec> hmm ?
11:41 < penberg> penberg@penberg-laptop:~/src/jato$ grep -r INSN_PUSH_MEMBASE *
11:41 < penberg> arch/x86/insn-selector.brg:	select_insn(s, tree, membase_insn(INSN_PUSH_MEMBASE, state->left->reg1,
11:41 < penberg> ok, I'm missing patch 14
11:42 < penberg> it's probably in my SPAM box :)
11:42 < tgrabiec> [PATCH 14/19] x86: add INSN_PUSH_MEMBASE
11:42 < penberg> yup
11:42 < penberg> found it
11:44 < penberg> tgrabiec: http://pastebin.com/m422f6877
11:45 < penberg> tgrabiec: pushed, thanks!
11:45 < tgrabiec> penberg: so you're blocked be the same NPE
11:46 < penberg> tgrabiec: do you see the same thing?
11:46 < tgrabiec> penberg: no, it's probably because of different classpath version.
11:46 < tgrabiec> as it was for S.o.p
11:47 < penberg> sure.
11:47 < tgrabiec> so, I'll try to install cp 96.1
11:49 < penberg> tgrabiec: I guess we need some sort of command line option for Jato where you can specify the location of GNU Classpath you want to use?
11:49 < penberg> that overrides the autodiscovery paths
11:49 < tgrabiec> penberg: we already have it -Dkey=value
11:50 < tgrabiec> -Djava.library.path=...
11:50 < tgrabiec> oh
11:50 < tgrabiec> but bootclasspath
11:50 < penberg> that's for natives.
11:50 < penberg> yup.
11:51 < penberg> Looking at the map of contributors on ohloh. We're spread around Europe quite nicely :-)
11:52 < penberg> tgrabiec: so how far do you get with your patches now?
12:07 < tgrabiec> penberg: gnu/java/awt/peer/gtk/CairoGraphics2D.setTransformImpl, and fails  the assertion `frame->nr_local_slots >= frame->nr_args'
12:07 < tgrabiec> The window is shown and stays
12:07 < tgrabiec> gtk main thread works
12:08 < penberg_home> tgrabiec: oh nice!
12:23 < tgrabiec> I must have been very tired to emit push_membase and ret instead of jmp_membase
12:24 < penberg> :-)
12:28 < penberg> hmm, gcc generates identical code for l2f and l2d.
12:33 < penberg_home> tgrabiec: does that fix the assertion?
12:33 < tgrabiec> NO
12:34 < penberg_home> aah ok
12:35 < tgrabiec> I'm building cp now from sources
12:40 < tgrabiec> (sorry for capslock in "NO", it was by mistake)
12:42 < penberg_home> tgrabiec: :)
12:45 < tgrabiec> penberg_home: ok, I get the same exception as you now
13:17 < tgrabiec> penberg_home: it was a bug in convert_ldc for TAG_CLASS
13:18 < tgrabiec> we should initalize the class, or otherwise ->object is NULL
13:18 < tgrabiec> vegard: any objections for initalizing on ldc /
13:18 < tgrabiec> ?
13:20 -!- mode/#jato [+o ahuillet] by ChanServ
13:20 -!- mode/#jato [+o penberg] by ChanServ
13:46 <@penberg> oh, l2f is just utterly crazy!
13:47 <@penberg> apparently it uses the x87 instruction set (even with -mfpumath=sse)
13:47 <@penberg> and requires a memory store + load!
13:47 < tgrabiec> isn't there any SSE instruction for that ?
13:49 <@ahuillet> penberg: you need a -msse -msse2
13:49 <@ahuillet> and it's -mfpmath not -mfpumath
13:51 <@penberg> ahuillet: sure: gcc -Os -c -msse2 -mfpmath=sse doit.c
13:51 <@penberg> is what I'm using
13:51 <@penberg> ahuillet: http://pastebin.com/m32953538
13:51 <@ahuillet> obviously adding -msse doesn't help?
13:51 <@ahuillet> oh, l2f, 64bit integer to floating point
13:51 <@ahuillet> you can't do that in SSE, even with SSE2
13:51 <@penberg> yes.
13:52 <@penberg> ahuillet: yes! :)
13:52 <@penberg> ahuillet: can you do it with sse3?
13:52 <@ahuillet> tat's why gcc doesn't do it :)
13:52 <@ahuillet> *that
13:52 <@penberg> aha!
13:52 <@ahuillet> mmh, sse3 and sse4 and friends are jokes
13:52 <@ahuillet> I don't seem to remember they add that, no
13:52 <@penberg> so anyway, how do you deal with fstps and movss?
13:52 <@ahuillet> what do you mean?
13:52 <@penberg> GCC seems to allocate a stack slot for that.
13:52 <@penberg> http://pastebin.com/m32953538
13:53 <@penberg> here's what GCC would do
13:53 <@penberg> (I emulated 64-bit value in registers with -mregparam=3)
13:53 <@ahuillet> yes
13:58 <@penberg> ok so we need INSN_FILD_MEMLOCAL_64 and INSN_FSTP_MEMLOCAL_32
14:01 <@penberg> oh we have FSTP alreayd
14:17 <@penberg> l2f done!
14:26 < tgrabiec> great!
14:26 <@ahuillet> :)
14:29 <@penberg> tgrabiec: hmm "return -1"
14:30 <@penberg> I'll change that to EINVAL
14:30 < tgrabiec> ok
14:30 < tgrabiec> oh
14:30 < tgrabiec> hmm
14:30 < tgrabiec> I think the patch 1/2 is not a proper solution
14:30 < tgrabiec> I have a better one
14:31 <@penberg> tgrabiec: ok, do you want me to drop it?
14:31 <@penberg> vegard: ping?
14:31 < tgrabiec> penberg: drop 1/2, 2/2 should be fine
14:31 <@penberg> ok
14:34 <@penberg> I can't believe we're missing only 7 bytecodes!
14:35 <@penberg> l2d seems really ugly!
14:38 < tgrabiec> I think the proper solution is to rewrite our class->object handling
14:38 < tgrabiec> ->object should be properly setup before class is initialized
14:38 < tgrabiec> the bug is expozed by the following snippet: KeyEvent.class.getFields()
14:38 < tgrabiec> KeyEvent.class should return uninitialized class
14:39 < tgrabiec> which is then initalized in getFields
14:40 <@penberg> tgrabiec: I guess we need to wait for vegard to show up?
14:40 < tgrabiec> yup. until vegards speaks up, I'll keep the "workaround"
14:43 <@penberg> tgrabiec: with your workaround I get a segmentation fault, btw.
14:45 <@penberg> gdb is useless :(
14:47 <@penberg> the last -Xtrace:invoke is [AWT-EventQueue-4] trace invoke: gnu/java/awt/peer/gtk/CairoGraphics2D.setup(J)V
14:49 <@penberg> hmmh
14:49 <@penberg> -Xtrace:invoke-verbose caused things to go even further.
14:50 <@penberg> tgrabiec: why doesn't our signal handler kick in?
14:51 < tgrabiec> penberg: I get it too
14:52 < tgrabiec> I'm debugging it and it seems to be a very nasty memory corruption
14:52 < tgrabiec> :(
14:52 < penberg_home> :-)
14:52 < penberg_home> tgrabiec: but why doesn't signal handler kick in?
14:54 < tgrabiec> penberg_home: it does. it just triggers another SIGSEGV before printing anything
15:21 < tgrabiec> the stack is awfully corrupted: http://pastebin.com/d4ece56e7
15:23 < penberg_home> tgrabiec: nice! ;)
15:25 < tgrabiec> I think I know why
15:25 < tgrabiec> what is @Override /
15:25 < tgrabiec> ?
15:26 < tgrabiec> yup
15:26 < tgrabiec> so
15:26 < tgrabiec> CairoGraphics2D.init() is native
15:27 < tgrabiec> ComponentGraphics.init() is not native
15:27 < tgrabiec> and has @Override
15:27 < tgrabiec> but jato thinks it is native (JNI) and puts jni env on stack
15:27 < tgrabiec> ComponentGraphics extends CairoGraphics2D
15:28 < tgrabiec> hmm
15:28 < tgrabiec> overriden native methods, nice
15:28 < tgrabiec> but how do we handle that ?
15:30 < tgrabiec> penberg: we need JNI stubs for that
15:31 < tgrabiec> we can not know at compilation time, whether invocation target is native, even if it is eclared to be !
15:32 < tgrabiec> natives can be overriden in subclasses, so we can not emit JNI stuff at call site. we have to emit special JNI trampolines
15:32 < tgrabiec> the good news is that the JNI crap can be removed from various parts of compiler
15:32 < tgrabiec> penberg: any thoughts ?
15:33 < tgrabiec> ACK to JNI trampolines ?
15:35 < penberg_home> tgrabiec: hmmh?
15:35 < penberg_home> why don't vtables work here?
15:36 < tgrabiec> penberg_home: they do, but we decide at run-time whether to push struct jni_env * on stack at cal site
15:36 < penberg_home> I see.
15:36 < tgrabiec> *we decide at compile-time currently
15:36 < penberg_home> hmm
15:36 < penberg_home> so
15:36 < penberg_home> hmm
15:36 < penberg_home> nasty.
15:37 < tgrabiec> so we can not decide at compile time, we need to attach a trampoline to JNI methods, which will put JNI env on stack
15:37 < penberg_home> but surely we don't need _per method_ trampolines?
15:37 < penberg_home> a generic one should suffice, no?
15:37 < tgrabiec> no, because we need to know the target
15:38 < tgrabiec> in trampoline
15:38 < tgrabiec> and trampoline will be called like any other JIT method
15:38 < penberg_home> can we figure that out somehow?
15:38 < penberg_home> after all, we know where the vtable offset is as we jump to the trampoline?
15:38 < tgrabiec> no
15:38 <@penberg> tgrabiec: why is that?
15:39 < tgrabiec> but it can be also called by invokestatic, invokespecial
15:39 < tgrabiec> and form vm_call_method
15:39 < tgrabiec> *from
15:39 <@penberg> invokestatic can't be overridden.
15:39 < tgrabiec> well, we know what is the target when we jump, but the callee doesn't know that
15:39 <@penberg> invokespecial uses the same vtables.
15:40 < tgrabiec> we would have to push that on stack, which we can not do
15:40 < tgrabiec> we could abuse some fixed register though
15:40 <@penberg> tgrabiec: yes, that's my thinking too.
15:40 <@penberg> tgrabiec: the problem here is that these "jni trampolines" can never be released.
15:41 <@penberg> can we just abuse eax, for example?
15:41 <@penberg> tgrabiec: and write the "jni trampoline" in asm?
15:43 <@penberg> tgrabiec: but yeah ACK for the approach, we obviously need to do that at run-time :(
15:44 -!- tgrabiec [n=tomekg@aenf228.neoplus.adsl.tpnet.pl] has quit [Read error: 60 (Operation timed out)]
15:53 -!- ahuillet [n=ahuillet@71.251.80-79.rev.gaoland.net] has quit ["ZNC by prozac - http://znc.sourceforge.net"]
15:55 -!- ahuillet [n=ahuillet@71.251.80-79.rev.gaoland.net] has joined #jato
16:02 -!- tgrabiec [n=tomekg@abkx62.neoplus.adsl.tpnet.pl] has joined #jato
16:04 <@penberg> ahuillet: HelloWorldSwing profile: http://pastebin.com/m5ca41bbb
16:04 <@penberg> we need to fix insert_to_list(), it's ridiculous :-)
16:04 < ahuillet> god. :)
16:05 <@penberg> ahuillet: I guess a binary search tree would help?
16:05 < tgrabiec> penberg: we need vtable to contain also vm_method pointers
16:06 < tgrabiec> so we can check if method is native, given actuall class and virtual index
16:06 < ahuillet> penberg: probably, I don't have the details in mind right now
16:06 <@penberg> tgrabiec: hmm, I'm beginning to change my mind about this
16:06 <@penberg> how about we generate a per-method stub for natives instead?
16:06 <@penberg> tgrabiec: like you suggested before?
16:07 < tgrabiec> I'm ok with that. what makes you change your mind ?
16:07 <@penberg> tgrabiec: double vtable :-)
16:07 <@penberg> and the fact that abusing a register makes the regular JIT calls slower too!
16:07 <@penberg> so for natives, it's going to be "push jni env" + "jmp", right?
16:07 < tgrabiec> unfortanetly it is not that simple
16:08 < tgrabiec> becausse we need to also cleanup the arg
16:08 <@penberg> tgrabiec: why?-)
16:08 < tgrabiec> penberg: cleanup
16:08 <@penberg> ok, so push jni env + call + pop jni env?
16:08 <@penberg> JNI sucks a lot, doesn't it?-)
16:09 < tgrabiec> yup, but we must also pop nad save original ret address before push jni_env
16:09 < tgrabiec> I talked about it to you long time ago
16:09 <@penberg> why?
16:10 < tgrabiec> the stack at trampoline entry looks like this:  RET, ARG0, ARG1. We need:   RET, JNIENV, ARG0, ARG1
16:11 < tgrabiec> and we must save the "old ret" and restore it after cleanup
16:11 <@penberg> ahuillet: actually, a priority queue might be even better!
16:12 <@penberg> tgrabiec: hmh, why?
16:12 <@penberg> yes
16:12 <@penberg> of cours e:)
16:12 <@penberg> hmmh
16:12 < tgrabiec> penberg: I'm thinking about using the per-thread JNI invocation stack for that
16:12 <@penberg> why?
16:12 <@penberg> mandated by JNI?
16:13 < tgrabiec> why what ?
16:13 <@penberg> JNIENV there
16:13 <@penberg> why can't it be after ARG1?
16:13 < tgrabiec> penberg: native JNI functions expect jni_env to be a first call argument
16:14 <@penberg> so it's impossible to generate sane code for this?
16:14 <@penberg> tgrabiec: ok, but ACK for trampolines :)
16:14 <@penberg> sorry for wasting your time again!
16:15 < tgrabiec> penberg: we have to do enter_jni() anyway, so I was thinking if we can store the old return address at the same time (before the call), and after netive returns, we read the address back from that special stack
16:16 < tgrabiec> or you have better idea where to store it ?
16:16 < tgrabiec> another option is to rewrite call arguments (you nacked on that a month ago)
16:17 <@penberg> tgrabiec: so you replace the return address with JNI env?
16:17 -!- ahuillet [n=ahuillet@71.251.80-79.rev.gaoland.net] has quit ["ZNC by prozac - http://znc.sourceforge.net"]
16:18 < tgrabiec> yes, my idea is to: save old return address, replace it with JNI env, call the method, restore old return address
16:18 <@penberg> tgrabiec: makes perfect sense.
16:18 -!- ahuillet [n=ahuillet@71.251.80-79.rev.gaoland.net] has joined #jato
16:30 <@penberg> ahuillet: ok, I'm taking a stab at implementing a priority queue and changing the register allocator to use it.
16:33 < ahuillet> I'm losing connection all the time
16:33 < ahuillet> because of the storm I think
16:34 <@penberg> ahuillet: hhm, actually, I'm going to investigate bit more.
16:34 < ahuillet> ?
16:35 <@penberg> it could be the insert_to_list() in allocate_registers(), actually.
16:36 <@penberg> hmm, does the inactive list need to be sorted?
16:36 <@penberg> no it doesn't.
16:51 < vegard> tgrabiec: "initializing on ldc"?
16:56 < tgrabiec> vegard: I'm not sure it is a correct solution. can you think of a better one ?
16:56 < vegard> ok, I read it now
16:56 < vegard> so the question is whether ldc for classes should initialize or not?
16:56 < tgrabiec> yup
16:57 < vegard> what does jvm spec say about it?
16:57 < tgrabiec> cause we might have something like this: SomeClass.class.getFileds()
16:57 < tgrabiec> I didn't find a anything in JVM spec about it
16:57 < tgrabiec> getField() is not a static method
16:58 < vegard> but .class is a static field, yes?
16:58 < tgrabiec> yes, by it is translated to pure ldc, nothing more
16:58 < vegard> then we should initialize it in ldc
16:58 < tgrabiec> ok, so tell Pekka to merge my patch :)
17:00 < vegard> you could try -1.4 switch to javac
17:00 < vegard> to see what code it generates then (with no "ldc class" instruction)
17:03 < tgrabiec> it emits putstatic to set //Field class$0:Ljava/lang/Class;, so I guess it triggers initialization
17:05 < vegard> putstatic ?
17:07 < tgrabiec> vegard: http://pastebin.com/d47a7c879
17:34 -!- ahuillet_ [n=ahuillet@165.169.66-86.rev.gaoland.net] has joined #jato
17:37 < vegard> ah
17:37 < vegard> huh
17:38 < vegard> it calls Class.forName("java.lang.Integer")
17:38 < vegard> the result... is put in Class.class ?
17:38 < vegard> Class.class = Class.forName("java.lang.Integer") ??
17:39 < vegard> oh
17:39 < vegard> class$0 ?
17:39 <@penberg> success!
17:39 <@penberg> user	0m5.746s
17:39 <@penberg> after
17:39 <@penberg> user	0m1.070s
17:39 <@penberg> HelloWorldSwing
17:40 < tgrabiec> 1m ??
17:40 < vegard> are you sure you didn't just succeed in crashing it sooner ;)
17:40 <@penberg> 1 sec!
17:40 < tgrabiec> ah, great !
17:40 < tgrabiec> there will be so much fun optimizing things
17:43 <@penberg> well, the only reason I did it was because we were spending 80% of the time in there!
17:44 <@penberg> for HelloWorldSwing.
17:44 < vegard> new profile? :)
17:45 <@penberg> vegard: http://pastebin.com/m5131a205
17:45 < vegard> kernel on top, nice :D
17:45 <@penberg> ahuillet: you might want to take a look
17:45 <@penberg> vegard: it's us
17:45 <@penberg> allocating shitloads of memory!
17:45 < vegard> that looks really nice.
17:45 < vegard> penberg: heh he
17:46 <@penberg> vegard: and libzip :-)
17:46 < vegard> mhm, I can't wait to write the patch to pack booleans :-/
17:47 <@penberg> vegard: oh sorry, that's for S.o.println
17:47 < vegard> btw, we can probably get rid of some zalloc() calls
17:47 <@penberg> vegard: http://pastebin.com/m66895c20
17:47 <@penberg> that's swing
17:47 < vegard> I noticed, for example, that sometimes we zalloc() and then initialize all the fields just afterwards anyway
17:47 <@penberg> vegard: yes, we should clean that crap up
17:48 -!- ahuillet [n=ahuillet@71.251.80-79.rev.gaoland.net] has quit [Read error: 110 (Connection timed out)]
17:48 -!- ahuillet_ is now known as ahuillet
17:51 < penberg_home> tgrabiec: so do I need to merge the ldc patch now?
17:51 < vegard> you can put an XXX there
17:52 < vegard> because it's the only way (at least I have) to remember that it should still be investigated
17:52 < vegard> but I _think_ it's correct to initialize it there
17:54 < vegard> ahuillet: when is the regalloc patch finished :-B
17:54 < ahuillet> have you tried it?
17:55 < vegard> it didn't help.
17:55 < ahuillet> I know :)
17:57 < vegard> is it hard?
17:58 < ahuillet> yes...
18:00 < penberg_home> ahuillet: http://github.com/penberg/jato/commit/6825f50cf8c5eef746c24fb6f48f101caf7d23e5
18:01 < ahuillet> penberg: y
18:01 < ahuillet> *you forgot to add pqueue.c, didn't you? :)
18:02 < penberg_home> nope
18:02 < penberg_home> ahuillet: http://github.com/penberg/jato/commit/36517886f65c889106c91b4481165bbb23f6743d
18:02 < ahuillet> where did you take the implementation from?
18:03 < penberg_home> the link is there :)
18:03 < ahuillet> I know, is that your code?
18:03 < ahuillet> ah ok
18:03 < ahuillet> sorry :)
18:03 < penberg_home> ;)
18:04 < penberg_home> vegard: I'm going to just apply the patch.
18:05 <@penberg> because it makes things work better for me.
18:06 <@penberg> tgrabiec: so I guess the segfault is fixed by the natives patch you're working on?
18:07 <@penberg> vegard: we're hitting strcmp() like crazy from classloader_load().
18:07 < vegard> yup
18:07 < vegard> hashtable :)
18:08 <@penberg> vegard: makes sense.
18:08 <@penberg> vegard: I can see it in the HelloWorldSwing perf report.
18:08 <@penberg> vegard: there's a nice call-graph thingy in perf
18:08 <@penberg> if you do perf record -g and perf report -g
18:09 <@penberg> vegard: http://pastebin.com/m3571f5cf
18:09 <@penberg>      3.52%     jato  /home/penberg/bin/jato                   [.] cafebabe_constant_info_utf8_compare
18:09 <@penberg> curious
18:11 <@penberg> hmm vm_class_get_field() has a loop too. hmm.
18:14 < vegard> Exception in thread "main" java/awt/AWTError: Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit
18:14 < vegard> is what I get for frozen bubble :)
18:15 < vegard> ah
18:15 < vegard> Caused by: java/lang/UnsatisfiedLinkError: Native library `gtkpeer' not found (as file `libgtkpeer.so') in gnu.classpath.boot.library.path and java.library.path
18:16 < penberg_home> how did you install the thing?
18:16 <@penberg> classpath that is
18:16 < vegard> by scp from my ubuntu machine
18:16 <@penberg> :-)
18:16 < vegard> but I forgot -r so it skipped directories
18:17 <@penberg> vegard: it crashes hard here and with tomek
18:17 <@penberg> because there's a _native_ method that's overriden by non-native method in classpath!
18:18 <@penberg> vegard, tgrabiec: http://pastebin.com/m26bf33aa
18:18 <@penberg> I ran tetris a few times in a row
18:18 <@penberg> most of the crashed hard, but I saw that one time
18:18 < vegard> hm
18:18 <@penberg> I guess the main thread was able to run before the event thread crashed.
18:19 <@penberg> convert_new: warning: unable to resolve class
18:19 < vegard> I didn't realize we could override non-native with native
18:19 <@penberg> so that was the root cause.
18:19 <@penberg> vegard: I don't think anyone did :-)
18:19 <@penberg> apparently you can!
18:20 <@penberg> vegard: http://pastebin.com/m75ed63a3
18:20 <@penberg> was not able to find java/util/Random?
18:22 <@penberg> vegard: what are you working on now?
18:23 < vegard> hm
18:23 < vegard> dinner.
18:23 <@penberg> aha!
18:23 <@penberg> vegard: I'd appreciate a main(String[] args) patch!
18:23 < vegard> oh, you didn't write it yet?
18:23 <@penberg> so I can test SciMark2 :-)
18:23 <@penberg> vegard: no!
18:23 <@penberg> -ETOOHARD.
18:29 < vegard> I want to finish the field reordering/compression
18:29 < vegard> so that we don't need 8 bytes per object
18:30 < penberg_home> vegard: ok
18:30 < vegard> and actually, we're using just 4 now, for anything smaller than long and double
18:31 < vegard> so this should already be an improvement in memory usage
18:32 < vegard> oh
18:32 < vegard> and gc maps
18:32 < vegard> I almost forgot.
18:33 <@penberg> :)
18:39 <@penberg> tgrabiec, vegard: http://github.com/penberg/jato/commit/968c1c4f8e9a99ce7201b385e4b0bb04aa2156ed
18:41 <@penberg> I wonder why we need to keep basic blocks around ...
18:41 <@penberg> (otherwise we'll crash)
18:47 < vegard> penberg: http://pastebin.com/m26bf33aa
18:47 < vegard> this was your paste
18:47 < vegard> there are missing native functions there..
18:48 <@penberg> in the stack trace?
18:50 <@penberg> vegard: ok, so how do I create an array of strings?
18:51 < vegard> vm_object_alloc_array()
18:51 < vegard> with vm_java_lang_String as first arg, probably
18:51 <@penberg> vm_object_alloc_array()?
18:51 <@penberg> yes
18:51 <@penberg> and strings from ASCIIz?
18:52 < vegard> vm_object_alloc_string_from_{c,utf8}
18:52 < vegard> from_c you should use.
18:52 <@penberg> yes
18:52 < vegard> the utf8 is a bit of a misnomer, since it means "the restricted kind of utf8 that we use internally in class files"
18:52 <@penberg> putting the string to the array?-)
18:53 < vegard> ((struct vm_object *) array->fields)[index] = string
18:53 < vegard> maybe ?
18:54 <@penberg> array_set_field_ptr() ?
18:54 <@penberg> ...vegard!
18:54 < vegard> ah
18:54 < vegard> that's true.
18:54 <@penberg> hmm, I wonder how I can now pass it to main()
18:54 <@penberg> hmm
18:54 < vegard> why is it _ptr and not _object ?
18:54 <@penberg> aah, I know!
18:54 < vegard> just modify the trampoline signature
18:54 <@penberg> vegard: dunno
18:56 <@penberg> I hate this const crap
18:57 <@penberg> Just leads to useless casting :(
18:57 <@penberg> reminds me of c++...
18:57 < vegard> where?
18:58 <@penberg> alloc_from_c
18:58 < vegard> there's no casting there?
18:59 <@penberg> nope, I am an idiot
18:59 <@penberg> cool it works!
18:59 <@penberg> no it doesnt
19:00 < vegard> use -Xtrace:invoke-verbose :)
19:03 <@penberg> vegard: http://pastebin.com/m36db60a6
19:04 <@penberg> vegard: http://pastebin.com/m10f0f7d2
19:05 <@penberg> penberg@penberg-laptop:~/testing/jato$ ./scimark
19:05 <@penberg> mono_burg_emit: EXPR_CONVERSION_TO_FLOAT: no conversion from 5 to 8
19:05 <@penberg> scimark fails like that now :)
19:05 < vegard> um
19:05 < ahuillet> isn't that l2f?
19:05 < vegard> can I see patch too? :p
19:05 <@penberg> #
19:05 <@penberg> [main]     J_REFERENCE : 0xa5884e0 SIGSEGV at EIP 080701d4 while accessing memory address 29621690.
19:06 <@penberg> ahuillet: 8 is double. :)
19:06 < ahuillet> oh.
19:06 < ahuillet> l2d, then?
19:07 <@penberg> ahuillet: yes
19:07 <@penberg> vegard: http://pastebin.com/m7e8291c8
19:07 <@penberg> ahuillet: not implemented.
19:08 <@penberg> penberg@penberg-laptop:~/src/jato$ jato PrintArgs
19:08 <@penberg> Exception in thread "main" java/lang/RuntimeException: object is not an array at PrintArgs.main(PrintArgs.java:3)
19:10 < vegard> I think you might have to pass an array class to array alloc
19:11 <@penberg> true
19:11 <@penberg> vegard: which is...?
19:11 < vegard> oh
19:12 <@penberg> nope
19:12 <@penberg> oh
19:12 <@penberg> vm_array_of_java_lang_reflect_Field,
19:14 <@penberg> native_vmstackwalker_getclasscontext is busted too
19:16 <@penberg> vegard: works!
19:17 <@penberg> penberg@penberg-laptop:~/src/jato$ jato PrintArgs hello vegard nossum!
19:17 <@penberg> hello
19:17 <@penberg> vegard
19:17 <@penberg> nossum!
19:18 < vegard> :D
19:19 <@penberg> so we're missing long to double.
19:19 <@penberg> for scimark
19:20 <@penberg> vegard: http://github.com/penberg/jato/commit/20616ec4d4d1635735d97a65196abce8f38a9969
19:25 < penberg_home> vegard: http://ellcc.org/wiki/index.php/ELLCC
19:25 < penberg_home> they claim to compile a bootable Linux kernel.
19:26 < tgrabiec> penberg: free_lookupswitch_list(cu) --- don't do this ! it's used at runtime
19:26 < tgrabiec> same for tableswitch
19:27 < penberg_home> :(
19:27 <@penberg> I wonder why no test crash :(
19:28 < tgrabiec> dunno, but probably valgrind would complain
19:29 <@penberg> tgrabiec: fixed.
19:29 <@penberg> we are too memory hungry
19:30 < tgrabiec> so you didn't succeed to free basic blocks and instructions ?
19:30 < penberg_home> nope
19:31 < tgrabiec> oh, fixup_site uses struct insn *
19:31 < tgrabiec> that needs fixing
19:33 < tgrabiec> we should operate on raw memory pointers
19:33 < penberg_home> yup
19:34 < tgrabiec> I'm struggling with JNI tramps now, it's not that painless
19:34 < penberg_home> tgrabiec: :)
19:35  * penberg_home hides
19:35 < penberg_home> tgrabiec: any specific problem?
19:37 < tgrabiec> Assertion `trace_classloader_level >= 0' failed
19:37 < tgrabiec> seems like memoroy corruption, I've seen this before
19:37 < tgrabiec> I don't want to bother you
19:37 < penberg_home> :)
19:43 < tgrabiec> oh, I remember when I saw this, it happens if vm_leave_jni() is called too many times. fixed
19:43 < tgrabiec> and it works!
19:44 < penberg_home> cool!
19:44 < tgrabiec> now I get this for HwlloSwing: Assertion `frame->nr_local_slots >= frame->nr_args' failed.
19:46 < vegard> penberg_home: why do you make the argument to the trampoline void * instead of struct vm_object * ?
19:46 < penberg_home> vegard: dunno
19:46 < penberg_home> I guess I am just dying to get a cleanup patch from someone special...
19:47 < vegard> penberg_home: uhr
19:47 < vegard> and the vm/preload.c hunk
19:47 < penberg_home> vegard: what's the problem?
19:47 < vegard> hm.
19:48 < vegard> it's not sorted alphabetically anymore
19:48 < penberg_home> never was
19:48 < vegard> well, not that it was before either..
19:48 < penberg_home> yes
19:48 < vegard> but it's nice to do it ;)
19:48 < penberg_home> yup
19:48 < penberg_home> why is nobody voting up my answers on stackoverflow.com
19:48 < penberg_home> bastards!
19:48 < vegard> huh?
19:51 < vegard> btw
19:51 < vegard> Caused by: java/lang/UnsatisfiedLinkError: Native library `gtkpeer' not found (a
19:51 < vegard> s file `libgtkpeer.so') in gnu.classpath.boot.library.path and java.library.path
19:51 < vegard> this is a lie
19:51 < vegard> we can actually find it
19:51 < vegard> but we can't load it
19:51 < vegard> (because it has some dependencies of its own which are missing)
19:51 < penberg_home> aha
19:51 < penberg_home> can we fix that somehow?
19:52 < vegard> don't think so.
19:52 < vegard> I think it's Runtime.loadLibrary() that throws
19:54 < tgrabiec> yup, it's classpath's fault
19:56 < vegard> penberg_home: gc/stack maps.
19:56 < vegard> we have one bitmap for each gc safepoint
19:57 < vegard> the bitmap tells if a register/stack slot contains a valid reference?
19:58 < vegard> penberg_home: should I try to fix up your safepoints code first and make a patch for jato?
20:04 < penberg_home> vegard: probably yes
20:04 < penberg_home> because then you can make a gc map patch and just print the roots
20:04 < penberg_home> (to see if you found all of them)
20:04 < penberg_home> and the third patch then adds the actual scanning & gc
20:05 < penberg_home> vegard: and I guess you could bother tgrabiec on the thing too.
20:05 < penberg_home> as the sighandler expert :)
20:06 < tgrabiec> vegard: I guess we will need to cope somehow with our "fake reference" in VMClass.vmdata ?
20:06 < vegard> tgrabiec: yes.
20:06 < vegard> maybe we can omit it somehow from the object gc map
20:07 < tgrabiec> yup
20:26 < vegard> what does MEMLOCAL mean?
20:26 < vegard> I want to use this instruction: "TEST r/m8, imm8" for our guard pages
20:27 < vegard> but I'm not sure what to call the r/m8 part in our emitter
20:27 < tgrabiec> vegard: test_membase_reg ?
20:27 < vegard> oh
20:27 < vegard> test_membase_imm then?
20:27 < tgrabiec> yes
20:27 < vegard> but I don't want a membase?
20:28 < tgrabiec> memlocal is when base register is %ebp
20:28 < penberg_home> vegard: MEMLOCAL means ebp + offset
20:28 < penberg_home> yup
20:28 < vegard> ah
20:28 < vegard> so "testb $0x0,0x12345678" (gas) is membase for the second?
20:28 < tgrabiec> memdisp
20:28 < vegard> ah right
20:28 < vegard> thanks
20:30 < tgrabiec> penberg: hmm, the EXPR_CONVERSION_TO_FLOAT: 5 to 8 thing - I think EXPR_CONVERSION_TO_DOUBLE should kick in here
20:32 < tgrabiec> otherwise we have a bug
20:32 < penberg_home> nope
20:32 < penberg_home> TO_FLOAT is fine
20:32 < penberg_home> we should just check for J_DOUBLE there.
20:33 < penberg_home> remember, it's about register classes, not types.
20:33 < penberg_home> freg is for J_FLOAT and J_DOUBLE
20:33 < penberg_home> reg is for the rest.
20:33 < penberg_home> look how we handle J_LONG
20:34 < tgrabiec> penberg_home: but look at convert_conversion() in jit/typeconv-bc.c
20:34 < tgrabiec> if (to_type == J_DOUBLE)	conversion_expression = conversion_to_double
20:34 <@penberg> heh
20:35 <@penberg> 0e990dcd include/jit/expression.h (Tomek Grabiec             2009-08-06 22:14:30 +0200  35)     EXPR_CONVERSION_FROM_DOUBLE,
20:35 <@penberg> 0e990dcd include/jit/expression.h (Tomek Grabiec             2009-08-06 22:14:30 +0200  36)     EXPR_CONVERSION_TO_DOUBLE,
20:35 <@penberg> I don't think it's needed.
20:35 < tgrabiec> penberg: it's all about naming
20:35 < tgrabiec> we definitely need CONVERSION_FLOAT_TO_DOUBLE
20:36 < tgrabiec> and CONVERSION_FROM_FLOAT would be misleading
20:36 <@penberg> hmmh
20:36 <@penberg> it's a mess.
20:36 < tgrabiec> we could call it CONVERSION_FROM_FLOATINGPOINT
20:36 <@penberg> ;)
20:36 <@penberg> We have CONVERSION
20:36 <@penberg> which is int -> long, long -> int etc.
20:37 <@penberg> so I guess we need
20:37 <@penberg> FLOAT_CONVERSION
20:37 <@penberg> which is float -> double, double -> float
20:37 <@penberg> 21633db7 include/jit/expression.h (Arthur HUILLET            2009-07-03 12:59:51 +0200  33)     EXPR_CONVERSION_FROM_FLOAT,
20:37 <@penberg> 21633db7 include/jit/expression.h (Arthur HUILLET            2009-07-03 12:59:51 +0200  34)     EXPR_CONVERSION_TO_FLOAT,
20:37 <@penberg> these should be probably renamed to EXPR_INT_TO_FLOAT and EXPR_FLOAT_TO_INT
20:37 <@penberg> tgrabiec: but the point stands, EXPR_CONVERSION_TO_DOUBLE needs to go
20:38 < tgrabiec> penberg: they can handle LONG -> FLOAT too
20:38 <@penberg> tgrabiec: yes.
20:38 <@penberg> so AFAICT, we only need four expressions:
20:39 <@penberg> EXPR_INT_CONVERSION, EXPR_FLOAT_CONVERSION, EXPR_INT_TO_FLOAT and EXPR_FLOAT_TO_INT
20:39 < tgrabiec> what about char ?
20:40 < tgrabiec> is it in  'INT' ?
20:40 < penberg_home> yes
20:41 < penberg_home> int = integer and float = decimal
20:41 < tgrabiec> names are identical to java types
20:43 < penberg_home> hey, if you can come up with better ones, lets use them
20:43 < penberg_home> I'm happy with my suggestion ;)
20:46 < tgrabiec> I'm ok with that
20:46 < tgrabiec> but I didn't mention this because of this problem, I mentioned the thing because it seems to be a bug
20:46 < tgrabiec> if to_type is double, we should not try EXPR_CONVERSION_TO_FLOAT
20:47 < penberg_home> yup
20:47 < penberg_home> if you fix it, please clean it up while at it
20:47 < penberg_home> it's bit of a mess now
20:51 < tgrabiec> penberg_home: I know that current JNI trampoline is a bit heavy, but I don't want to optimize it until the solution is proven to be good
20:52 < penberg_home> tgrabiec: heh
20:52 < penberg_home> I was just about to mention that
20:52 < penberg_home> but yeah, makes sense
20:53 < penberg_home>  11 files changed, 97 insertions(+), 284 deletions(-)
20:53 < penberg_home> speaks for itself!
20:55 <@penberg> tgrabiec: pushed, nice work!
20:56 <@penberg> ok I see this too:
20:56 <@penberg> jato: arch/x86/stack-frame.c:101: frame_locals_size: Assertion `frame->nr_local_slots >= frame->nr_args' failed.
20:56 <@penberg> vegard, tgrabiec: are you guys able to use gdb?
20:56 <@penberg> I just get SIGSEGV
20:56 < vegard> penberg: c
20:56 < vegard> penberg: just continue
20:56 <@penberg> aah
20:57 < tgrabiec> you can issue: handle SIGSEGV nostop
20:58 <@penberg> aah!
20:58 <@penberg> it's crazy how far we get ;)
20:59 < vegard> penberg: can you make an activity graph for jato?
20:59 <@penberg> vegard: how?
20:59 <@penberg> [AWT-EventQueue-2] trace invoke: gnu/java/awt/peer/gtk/CairoGraphics2D.setTransformImpl(Ljava/awt/geom/AffineTransform;)V
20:59 <@penberg> jato: arch/x86/stack-frame.c:101: frame_locals_size: Assertion `frame->nr_local_slots >= frame->nr_args' failed.
20:59 < vegard> penberg: I mean the commit history
20:59 <@penberg> vegard: github?
21:00 <@penberg> vegard: http://github.com/penberg/jato/graphs/punch_card
21:03 < vegard> but history
21:03 <@penberg> java/awt/geom/AffineTransform.getMatrix
21:03 <@penberg> vegard: I don't undestand what you want me to do!
21:04 < vegard> a big graph from start to finish
21:04 < vegard> with number of commits / week or so
21:04 <@penberg> vegard: how do I do that?
21:04 <@penberg>   public void getMatrix(double[] d)
21:04 <@penberg>   {
21:04 <@penberg>     d[0] = m00;
21:04 <@penberg>     d[1] = m10;
21:04 <@penberg>     d[2] = m01;
21:04 <@penberg>     d[3] = m11;
21:04 <@penberg>     if (d.length >= 6)
21:04 <@penberg>       {
21:04 <@penberg>         d[4] = m02;
21:04 <@penberg>         d[5] = m12;
21:04 <@penberg>       }
21:04 <@penberg>   }
21:04 <@penberg> double arrays hmm
21:11 <@penberg> so we need dastore/daload anyway
21:11 < tgrabiec> should not be hard to do
21:12 < tgrabiec> are you going to do it ?
21:12 <@penberg> tgrabiec: and there's something wrong with how we pass double arrays to methods apparently...
21:12 < tgrabiec> double arrays are passed like any other objects, just the pointer
21:14 <@penberg> tgrabiec: try it!
21:14 <@penberg> just make an empty public void getMatrix(double[] d) method
21:14 <@penberg> and try to pass a double array to it
21:14 <@penberg> and see the assertion trigger!
21:15 <@penberg> 1 2
21:15 <@penberg> jato: arch/x86/stack-frame.c:102: frame_locals_size: Assertion `frame->nr_local_slots >= frame->nr_args' failed.
21:15 < tgrabiec> yes, I can see it, hmm
21:16 <@penberg> ok, so
21:16 <@penberg>                 cu->stack_frame = alloc_stack_frame(
21:16 <@penberg>                         method->args_count,
21:16 <@penberg>                         method->code_attribute.max_locals);
21:16 <@penberg> is just completely busted :)
21:16 <@penberg> ->args_count is _not_ "normalized" whereas .max_locals is
21:16 <@penberg> so any method that has no local variables
21:17 <@penberg> hmmh
21:17 <@penberg> actually
21:17 <@penberg> why does it think there are two args?
21:17 <@penberg> cafebabe bug?
21:18 < tgrabiec> penberg: method->args_count is the machine word args count
21:18 < tgrabiec> so one word for this and one for argument
21:18 <@penberg> it's static.
21:18 <@penberg> in my test case.
21:18 <@penberg> hhhhmmmm
21:18 < tgrabiec> hhm
21:18 <@penberg> skip_type()
21:19 <@penberg> in vm/types.
21:19 <@penberg> yup
21:19 <@penberg> double arrays and long arrays are busted.
21:20 < tgrabiec> yup
21:20 -!- ahuillet [n=ahuillet@165.169.66-86.rev.gaoland.net] has quit [Read error: 104 (Connection reset by peer)]
21:21 <@penberg> tgrabiec: http://pastebin.com/m4c484e16
21:21 <@penberg> ok to commit?
21:21 <@penberg> (it fixes the problem for me)
21:22 < tgrabiec> seems ok
21:22 <@penberg> ok I see a hard crash here:
21:22 <@penberg> [AWT-EventQueue-2] trace invoke: gnu/java/awt/peer/gtk/GdkFontPeer.setupMetrics()V
21:22 <@penberg> (nothing is printed)
21:22 <@penberg> tgrabiec: I guess we ought to make our stack trace printing more robust?
21:25 < tgrabiec> penberg: heh http://pastebin.com/d22fd9800
21:25 <@penberg> :-)
21:27 < tgrabiec> penberg: it seems to go not as far as before
21:27 <@penberg> tgrabiec: hmm.
21:27 <@penberg> maybe the fix is buggy then?
21:28 < tgrabiec> maybe
21:28 < tgrabiec> or the bug caused that we choosed the wrong path
21:28 <@penberg> :)
21:28 <@penberg> I'll commit it anyway with a test case
21:29 <@penberg> because it fixes an obvious bug.
21:29 < tgrabiec> setupMetrics uses double arrays
21:30 <@penberg> tgrabiec: pushed.
21:31 <@penberg> cafebabe hmm
21:31 <@penberg> tgrabiec: btw
21:31 < vegard> hm?
21:31 <@penberg> I saw that double array store/load didn't crash
21:31 <@penberg> so maybe the bug is just that we generate wrong code for that?
21:32 <@penberg> vegard: we're seeing a hard crash at address 0xcafebabe :)
21:32 < vegard> oh really.
21:33 < vegard> git grep? :)
21:33 < tgrabiec> penberg: apparently I implemented double array store/load
21:33 < tgrabiec> when I was adding double support
21:33 < tgrabiec> I'll try to write a regression test
21:33 <@penberg> aha!
21:34 -!- ahuillet [n=ahuillet@15.169.66-86.rev.gaoland.net] has joined #jato
21:35 < tgrabiec> it seem to work
21:36 <@penberg> tgrabiec: ok
21:36 <@penberg> tgrabiec: well, have fun with debugging the crash :-)
21:36 <@penberg> I'm off!
21:36 < tgrabiec> heh
21:36 <@penberg> I'll update the bytecode matrix first though
21:37 < vegard> I'm working on the gc safepoints now
21:38 <@penberg> vegard: nice!
21:38 <@penberg> Maybe we'll do a release tomorrow
21:38 <@penberg> tris, frozen bubble, and scimark running :)
21:39 < penberg_home> later!
21:39 < tgrabiec> see ya
21:56 < tgrabiec> vegard: any idea where can this come from: SIGSEGV at EIP bebafeca while accessing memory address bebafeca ?
22:07 < tgrabiec> hmm, seems to be a regalloc bug
22:10 < tgrabiec> oh, no it's not
22:24 < tgrabiec> ok, so HelloWorldSwing does not fail. It executes without error, but the label doesn't show up
22:25 <@penberg> tgrabiec: http://pastebin.com/m7e65a1d9
22:25 <@penberg> tgrabiec: pushed, good night!
22:26 < tgrabiec> yes, I've seen this for tetris
22:26 < tgrabiec> :)
22:26 <@penberg> oh helloworldswing works here too!
22:27 <@penberg> Yeah, I don't see the label either.
22:27 <@penberg> That's going to be fun to debug :-)
22:27 < tgrabiec> UIDefaults.getUIError: failed to locate UI class:LabelUI
22:27 <@penberg> true.
22:27 < tgrabiec> yeah, fun :)
22:29 < penberg_home> tgrabiec: probably classloader doesn't work
22:29 < penberg_home> tries to load some resources
22:29 < penberg_home> getResource() or whatever it's called
22:30 < penberg_home> fonts probably.
22:30 < penberg_home> good night! (this time for real)
22:31 < tgrabiec> I think I'll take a break from debugging for the rest of the evening
--- Log closed Mon Aug 10 00:00:22 2009