--- Log opened Sat Aug 08 00:00:22 2009
09:36 -!- tgrabiec [n=tomekg@abro203.neoplus.adsl.tpnet.pl] has joined #jato
09:48 < penberg_home> heh heh
09:48 < penberg_home> people talking about JITs in slashdot
09:56 < ahuillet> hey guys
09:56 < ahuillet> let me share with you this great moment: http://paste.pocoo.org/show/133126/
09:57 < penberg_home> :-)
10:01 < vegard> hhuh?
10:02 < ahuillet> some poor guy who thinks that uucpssh.org forwards all its mails to the french government
10:02 < ahuillet> what he does not understand is that if uucpssh.org does it, the french ISPs probably do it already
10:02 < ahuillet> a moron who wants some attention.
10:04 -!- penberg [n=penberg@cs146249.pp.htv.fi] has joined #jato
10:06 < penberg> vegard: can invokeinterface targets be ACC_NATIVE?
10:07 < vegard> good question, I have no idea :)
10:07 < penberg> hmmh
10:07 < vegard> I would guess so.
10:07 < penberg> OTOH, I'm mostly interested in VM natives now, not JNI.
10:08 < penberg> so I guess we only do invokevirtual now?
10:08 < vegard> hm?
10:08 < penberg> well
10:08 < tgrabiec> penberg: I think it is possible
10:08 < penberg> I am removing throw_from_native()
10:09 < penberg> tgrabiec: oh I didn't see you!
10:09 < penberg> the jni + vm native code is hairy in insn selector :-)
10:09 < tgrabiec> well, yes
10:09 < penberg> tgrabiec: so I'm going to leave invokestatic and invokeinterface alone now
10:10 < penberg> only fix up places that have vm_method_is_vm_native()
10:10 < tgrabiec> hmm
10:10 < penberg> regression tests pass, so it's all good :-)
10:10 < vegard> make sure you try SOP as well
10:10 < penberg> I don't think we handle the other cases properly anyway?
10:10 < penberg> vegard: surely we have a regression test for that too.... ;-)
10:10 < tgrabiec> penberg: other cases are handled properly
10:10 < penberg> tgrabiec: yeah?
10:11 < vegard> penberg: we do? did we change PrintTest to use .println instead of .write now?
10:11 < tgrabiec> why do you think we don't ?
10:11 < penberg> tgrabiec: vm natives and invokeinterface?
10:11 < penberg> vegard: S.o.println() works just fine.
10:11 < penberg> tgrabiec: _jni_ and invokeinterface probably works.
10:11 < vegard> penberg: sure, but it should be part of 'make regression'
10:11 < penberg> tgrabiec: because I don't see any vm_method_is_vm_native() checks in invokestatic nor invokeinterface.
10:11 < penberg> vegard: sure.
10:12 < tgrabiec> penberg: the check is in method initialization
10:12 < tgrabiec> what are we talking about?
10:12 < tgrabiec> invokestatic and invokespecial are handled in invoke() in insnselector
10:13 < penberg> tgrabiec: ok, I just don't understand the code, I guess?
10:13 < penberg> http://www.laughingpanda.org/~penberg/0001-vm-Use-exception-test-for-VM-natives.patch
10:13 < penberg> this works for me, I think I'll push it.
10:13 < tgrabiec> 	if (vm_method_is_jni(method) || vm_method_is_vm_native(method))
10:14 < tgrabiec> this could be reduced to vm_method_is_native(method)
10:14 < penberg> k
10:14 < penberg> will fix
10:15 < tgrabiec> oh, we're missing exception check in invokevirtual
10:15 < penberg> tgrabiec: if you reload, you'll see the latest patch
10:18 < penberg> tgrabiec: if you don't have complaints, I'll push
10:18 < tgrabiec> I don't, it's good !
10:19 < vegard> hm
10:19 < vegard> [unknown]  [<0806a198>] native     : <unknown>
10:19 < penberg> I guess we're all surprised that I was able to write a patch?-)
10:19 < vegard> $ addr2line -e jato -i 0806a198
10:19 < penberg> vegard: yes! I've seen that too!
10:19 < vegard> jato/vm/class.c:162
10:19 < vegard> but
10:19 < vegard> [unknown]  [<0806b3ab>] native     : vm_class_link+484
10:20 < vegard> this one (the next one) shows up just fine
10:20 < penberg> tgrabiec: wow, crazy looking patch :-)
10:20 < tgrabiec> hmm
10:20 < penberg> tgrabiec: I think you just sent monoburg binary too?-)
10:21 < tgrabiec> penberg: your patch renamed it, some how it sneaked when I did commit -a
10:21 < penberg> heh
10:21 < tgrabiec> penberg: can you just leave the first hunk ?
10:22 < penberg> sure
10:22 < tgrabiec> thanks :)
10:24 < penberg> PrintTest.class.getSimpleName()
10:24 < penberg>   REGRESSION
10:24 < penberg> Exception in thread "main" java/lang/UnsatisfiedLinkError: java/lang/VMClass.isAnonymousClass(Ljava/lang/Class;)Z
10:24 < penberg>    at java.lang.VMClass.isAnonymousClass(Native Method)
10:24 < penberg>    at java.lang.VMClass.getSimpleName(VMClass.java:299)
10:24 < penberg>    at java.lang.Class.getSimpleName(Class.java:1470)
10:24 < penberg>    at jvm.PrintTest.main(PrintTest.java:33)
10:26 < penberg> OK, throw_from_native() is gone now.
10:26 < penberg> I guess we're all pretty surprised that I was able to put together a patch.
10:26 < vegard> I am so thrilled to have experienced it!
10:27 < vegard> a once-in-a-lifetime happening!
10:27 < penberg> Well, it was slightly painful so I'm not sure I ever want to do that again.
10:27 < penberg> the whole "git commit" thing seems weird
10:27 < penberg> I like "git am" better.
10:28 < penberg> vegard: I added S.o.println() test too.
10:28 < vegard> cool.
10:28 < penberg> vegard: so do we track "class is anonymous" somewhere?
10:28 < vegard> class->kind = VM_CLASS_KIND_{PRIMITIVE|ARRAY} perhaps ?
10:28 < tgrabiec> penberg: how did you trigger that exception?
10:28 < vegard> what is an anonymous class?
10:28 < penberg> tgrabiec: PrintTest.class.getSimpleName()
10:29 < penberg> I think I'll add a VMClass test now.
10:29 < penberg> and implement a VM native!
10:29 < penberg> how exciting is that?
10:29 < vegard> omgomg
10:30 < vegard> penberg: btw, I think we're going to be a bit slower when we have the verifier in place
10:31 < penberg> vegard: sure.
10:31 < penberg> vegard: are you looking forward to implementing it?
10:31 < vegard> I am dreading it, because it sounds awfully boring.
10:31 < vegard> well, I'll enjoy writing the tests for it
10:31 < penberg> :-)
10:32 < vegard> randomly corrupting classes and attempting to load them
10:32 < vegard> seeing all the jato crashes...
10:32 < penberg> :-)
10:33 < penberg> That's probably a pretty powerful way to make Jato more robust.
10:33 < vegard> introducing single-bit errors is pretty fun.
10:33 < tgrabiec> can you guys look at is_on_heap() in jit/method.c and tell me if it is good and why it is wrong?
10:34 < tgrabiec> cause I get lots of  random *** pointer not on heap *** for references returned by VM natives
10:35 < tgrabiec> allocated with vm_object_alloc() and such
10:35 < vegard> looks ok to me
10:36 < tgrabiec> can malloc() returns this pointer? 0xa65004f0
10:36 < tgrabiec> isn't it in kernel ?
10:37 < vegard> kernel is 0xc0000000 and up iirc on 3G/1G split
10:37 < tgrabiec> ok, so it's not in kernel. but it's not on heap either
10:37 < vegard> I'm struggling with *** glibc detected *** ../jato: malloc(): memory corruption: 0x091dfaa0 ***
10:37 < vegard> myself :)
10:38 < tgrabiec> vegard: what's your test case ?
10:38 < vegard> the old PrintTest, but I'm working on field reordering
10:38 < tgrabiec> mhm
10:39 < tgrabiec> I miss valgrind
10:39 < vegard> hehehe
10:40 < penberg> vegard: _anonymous_ classes!
10:41 < vegard> new Thread(new Runnable() { ... }).start() ?
10:41 < penberg> yes.
10:41 < penberg> I guess we don't support that?
10:41 < vegard> I thought javac just made those into inner classes?
10:41 < penberg> maybe
10:42 < penberg> but apparently VMClass.isAnonymousClass() needs to be implemented by the VM!
10:42 < vegard> try to figure out what it's supposed to do :-p
10:42 < tgrabiec> penberg: look at classpath sources
10:43 < tgrabiec> in most of cases the comments are helpfull, but this time they aren't so don't bother
10:43 < penberg> never mind that, I am unable to even get the vm native to run!
10:44 < vegard> lol ;)
10:44 < penberg> blah
10:44 < penberg> I wrote
10:44 < penberg> isNativeClass
10:44 < penberg> ...
10:44 < penberg> bloody hell!
10:44 < penberg> this programming thing is just too much for me
10:46 < penberg> hmmh
10:47 < tgrabiec> penberg: any idea why malloc() can return address which is larger than sbrk(0) ?
10:47 < vegard> mmap()
10:47 < penberg> yup
10:47 < vegard> malloc uses mmap for larger requests
10:47 < penberg> tgrabiec: don't assume malloc() uses sbrk().
10:48 < tgrabiec> so is_on_heap() is actually broken
10:48 < vegard> no
10:48 < tgrabiec> right
10:48 < tgrabiec> it just isn't on heap
10:48 < vegard> it's just that malloc doesn't always allocate from the heap :-p
10:48 < tgrabiec> hmm
10:48 < tgrabiec> too bad
10:48 < penberg> vegard: hmmh?
10:48 < penberg> so what do you call the "mmap area"?
10:48 < penberg> "mmap area"?-)
10:49 < vegard> we should have had a is_malloc_addr()
10:49 < vegard> penberg: :-p
10:49 < tgrabiec> vegard: can you write one ?
10:49 < penberg> hold your horses.
10:49 < penberg> we use mmap() for JIT text too.
10:49 < penberg> is that going to be a problem?
10:49 < ahuillet> <vegard> it's just that malloc doesn't always allocate from the heap :-p
10:49 < ahuillet> ?!?!?!!
10:50 < vegard> ahuillet: well, mmaped memory _isn't_ the heap
10:50 < tgrabiec> sneaky bastard that malloc
10:50 < ahuillet> it depends on where it's virtually mapped
10:50 < penberg> hmm?
10:50 < ahuillet> anyway does malloc use mmap?
10:51 < penberg> ahuillet: yes.
10:51 < ahuillet> I thought calloc() did for big blocks
10:51 < penberg> I'm guessing calloc() uses malloc() internally.
10:51 < penberg> or _int_malloc() or whatever glibc calls it.
10:51 < penberg> because that's what the kernel does :-)
10:51 < vegard> man 3 malloc
10:51 < penberg> vegard: so lets talk JIT + mmap()?
10:52 < penberg> problem: ( ) yes, ( ) no
10:52 < vegard> well, what do we use the is_on_heap() for anyuway?
10:52 < penberg> yup, my thinking too
10:52 < penberg> maybe we can get rid of it.
10:53 < tgrabiec> vegard: for debugging
10:53 < tgrabiec> so it is not a huge problem anyway
10:54 < penberg> tgrabiec, vegard: maybe glibc has a function for this?
10:54 < penberg> so why is class->name NULL?
10:54 < tgrabiec> penberg: where ?
10:55 < penberg> I'm writing VMClass.isAnonymousClass()
10:55 < penberg> it's NULL for all classes.
10:55 < penberg> that's struct vm_class
10:55 < vegard> signatures, please.
10:56 < penberg> signatures?
10:56 < vegard> method signature, native function signature
10:56 < penberg> aha
10:56 < penberg> so you're taking the "newbie writing code" card
10:56 < penberg> fine
10:56 < penberg>   static native boolean isAnonymousClass(Class klass);
10:56 < penberg>  static int32_t
10:56 < penberg> +native_vmclass_is_anonymous_class(struct vm_class *class)
10:57 < tgrabiec> wrong
10:57 < vegard> that should be struct vm_object *
10:57 < penberg> haha
10:57 < penberg> see?
10:57 < tgrabiec> penberg: look at other vmclass natives
10:57 < penberg> it's much better for you to write code.
10:57 < penberg> tgrabiec, vegard: thnx
10:58 < penberg> (yes, I saw those when I copy-pasted my function but ripped the "crap" out, heh, heh)
10:58 < penberg> vm_class_get_class_from_class_object()
10:58 < penberg> can we squeeze one more "class" in there somewhere?
10:58 < penberg> :)
10:58 < vegard> maybe one at the end?
10:58 < penberg> so why do some check for NULL
10:59 < vegard> every second word is "class" :-p
10:59 < vegard> penberg: all should
10:59 < penberg> get_name or something doesn't
11:00 < vegard> -ENOPATCH
11:01 < penberg> heh heh
11:01 < penberg> I just hate our process
11:01 < penberg> when it turns on me.
11:01 < penberg> grmbl
11:02 < tgrabiec> we should also check if (!vm_object_is_instance_of(object, vm_java_lang_Class))
11:02 < penberg> why?
11:03 < vegard> hm. I realized it won't work as well as I'd hoped. because when we inherit fields, we can't mix parent and child fields, so the gc will have to scan multiple areas (one for each class)
11:03 < penberg> the _verifier_ needs to take care of that
11:03 < vegard> hm. for some reasaon, I don't think that's true @ penberg
11:04 < tgrabiec> penberg: how can verifier verify that without executing the code ?
11:04 < penberg> tgrabiec: that's why we have static typing :-)
11:04 < tgrabiec> penberg: but we have casting
11:05 < tgrabiec> hmm
11:05 < penberg> hmhm?
11:05 < tgrabiec> nevermind
11:05 < penberg> VMClass.isAnonymousClass(Class)
11:05 < penberg> tgrabiec: :-)
11:05 < tgrabiec> penberg: still we need that check, think of JNI
11:05 < vegard> do we have likely/unlikely ?
11:06 < penberg> vegard: nope.
11:06 < tgrabiec> it can put any crap it wants as call arguments
11:06 < penberg> tgrabiec: true.
11:07 < vegard> but we can't defend against that
11:07 < penberg> sure we can.
11:07 < vegard> it could put (void *) 0xdead too, and checking the class of that won't help much
11:08 < penberg> vegard: do we have vm_class_is_inner() ?
11:08 < tgrabiec> penberg, ahuillet: what do you think of connecting basic blocks with exit block ?
11:08 < vegard> penberg: no
11:09 < ahuillet> tgrabiec : ?
11:09 < penberg> vegard: The InnerClasses Attribute
11:09 < tgrabiec> ahuillet: currently our basic blocks do jump to exit block, but it does not appear in successor list
11:09 < penberg> I guess cafebabe needs some loving?
11:09 < ahuillet> tgrabiec : our basic blocks don't jump to exit block do they?
11:09 < ahuillet> why would they?
11:10 < tgrabiec> ahuillet: they do
11:10 < penberg> ahuillet: they do :-)
11:10 < tgrabiec> to exit the method
11:10 < ahuillet> all our blocks do that? god
11:11 < tgrabiec> not all, but _some_
11:11 < ahuillet> and why do they need to exit the method?
11:11 < ahuillet> either it's in the CFG and it's already in the CFG
11:11 < tgrabiec> ahuillet: return
11:11 < ahuillet> or it's not in the CFG and the connection should not be here
11:11 < ahuillet> or we have a bug and have a connection that should be in the CFG :]
11:11 < ahuillet> which case is it?
11:11 < tgrabiec> ahuillet: bocks which contain return istruction jump to exit block, but it does not appear in CFG
11:12 < tgrabiec> it would be cleaner if there was a CFG edge for that
11:13 < ahuillet> well in the *real* CFG there is the edge
11:13 < ahuillet> if we don't build it, it's case 3, we have a bug
11:22 < vegard> __convert_ldc: warning: out of memory
11:22 < vegard> fun. :)
11:39 < vegard> um
11:39 < vegard> tools/monoburg/monoburg is a part of the repository now?
11:39 < penberg> vegard: yes?
11:40 < penberg> is it?
11:40 < vegard> um, why?
11:40 < penberg> I don't see it!
11:40 < penberg> :-)
11:41 < vegard> $ git log --stat 36b2cb59453100e532e39085df93f27c796d4553
11:41 < vegard>  tools/monoburg/monoburg   |  Bin 0 -> 59084 bytes
11:41 < vegard> why don't you use "git mv" ?
11:41 < penberg> I still don't see it!
11:41 < penberg> http://github.com/penberg/jato/commit/9e47d3ef1cdb7c80eac17f0a5da3d7385be06e10
11:41 < penberg> vegard: because I don't know how to operate git?
11:41 < penberg> well I do
11:41 < penberg> but just one command
11:41 < penberg> "git am"
11:41 < vegard> aha
11:42 < penberg> vegard: http://github.com/penberg/jato/commit/67478d0e3dbe042375b3542bb4a69914a878d2ab
11:42 < penberg> I blame you for not sending a patch!
11:42 < penberg> vegard: anyway thnx for the heads up, I didn't see I messed it up
11:43 < penberg> class = vm_class_get_class_from_class_object(object);
11:43 < penberg> 0
11:43 < penberg> +  assert(class != NULL);
11:43 < vegard> why don't you send your patches to the mailing list, like the rest of us ;-)
11:43 < penberg> tgrabiec, vegard: should we do something about that?
11:43 < penberg> vegard: heh heh
11:43 < penberg> vegard: Did you say something?
11:43 < penberg> I didn't see it.
11:43 < penberg> :-D
11:44 < penberg> so s/signal_exception/throw_exception/g ?
11:45 < penberg> Exception in thread "main" java/lang/UnsatisfiedLinkError: java/lang/VMClass.isArray(Ljava/lang/Class;)Z at java.lang.VMClass.isArray(Native Method) at java.lang.VMClass.getSimpleName(VMClass.java:301)
11:45 < penberg> crap
11:46 < tgrabiec> penberg: that's a simple one
11:46 < tgrabiec> vm_class_is_array_class()
11:46 < penberg> k!
11:47 < penberg> oh, I found a bug in isAnoymousClass
11:47 < penberg> crap
11:48 < penberg> I really need to fix up native stack trace printing
12:02 < penberg> vegard: assertTrue(VMClass.isPrimitive(int[].class));
12:02 < penberg> returns false
12:02 < penberg> hmmh
12:02 < penberg> is that correct?
12:03 < vegard> yes
12:03 < penberg> ok
12:03 < vegard> int[] is an array classes
12:03 < penberg> true.
12:04 < penberg> I cleaned vmclass natives a bit.
12:05 < tgrabiec> btw, shouldn't we move native to other file ?
12:05 < vegard> yes.
12:05 < vegard> I have some partial patches to do it
12:05 < vegard> but it's not entirely trivial.
12:06 < penberg> ok, Class.getSimpleName() works now.
12:06 < penberg> vegard, tgrabiec: http://github.com/penberg/jato/commit/b5bcbd473620985fd2344b99381be19bbfe8aa8d
12:09 < penberg> hmmh
12:09 < vegard> LOL
12:09 < vegard> #define align(x, y) (((x) + (y) - 1) / (y))
12:09 < vegard> who can see what's wrong?
12:10 < penberg> not me.
12:10 < ahuillet> align integer value X to a multiple of y ?
12:10 < ahuillet> that's what this does?
12:10 < vegard> ahuillet: yes.
12:11 < vegard> no, that's what it's supposed to do
12:11 < tgrabiec> aren't we missing * y there ?
12:12 < vegard> something like that, yeah. I was wondering why the vmdata field had offset 4 when the object size was 2...
12:12 < penberg> that's from jato?
12:12 < penberg> vm/system.h ALIGN, please.
12:12 < ahuillet> vegard : x + y - 1 & (~(y-1))
12:13 < ahuillet> oh, that's what penberg's macro does. :)
12:13 < penberg> I think I stole it from Linux :-)
12:13 < ahuillet> I stole it from Nouveau :)
12:13 < vegard> oh, we have it already
12:15 < penberg> I have quite impressive commit streak at the moment.
12:15 < vegard> hm
12:15 < penberg> 15 of the last 16 commits are mine
12:15 < penberg> I better stop now.
12:16 < vegard> our INSTANCE_FIELD loads 4 bytes for short/char/byte/bool
12:19 < vegard> jit/jit-test-suite.c:226: undefined reference to `test_split_interval_at'
12:19 < vegard> ?
12:25 < penberg_home> hmmh
12:25 < penberg_home> works for me (tm)
12:31 < tgrabiec> vegard: yup, all our array elements are also multiples of machine word size
12:31 < tgrabiec> feel free to send pacthes :)
12:33 < tgrabiec> vegard: vm/types.c L180
12:34 < vegard> yup
12:34 < vegard> I changed that
12:34 < vegard> but I don't think I should
12:34 < vegard> not in the first patch anyway
12:35 < tgrabiec> vegard: you shouldn't, unless you use 8-bit and 16-bit moves to store/load array elements
12:35 < vegard> yup
12:36 < tgrabiec> we definitely should use 8-bit and 16-bit stores though
12:37 < vegard> penberg: java.lang.VMClassTest.testIsAnonymousClass fails here
12:38 < penberg_home> how is that possible?
12:38 < penberg_home> can you javap -c the test case?
12:38 < vegard> java/lang/AssertionError: Expected true, but was false.
12:39 < vegard> http://folk.uio.no/vegardno/vmclasstest.txt
12:40 < penberg_home>    42:	invokespecial	#48; //Method java/lang/VMClassTest$1."<init>":()V
12:40 < penberg_home> name of the class looks ok
12:40 < penberg_home> hmmh
12:40 < penberg_home> can you send the _class_ to me?
12:41 < penberg> or add some printfs
12:41 < vegard> http://folk.uio.no/vegardno/VMClassTest.class
12:41 < vegard> http://folk.uio.no/vegardno/VMClassTest$1.class
12:43 < penberg> ecj -v?
12:43 < vegard> Eclipse Java Compiler 0.883_R34x, 3.4.1 release, Copyright IBM Corp 2000, 2008. All rights reserved.
12:43 < penberg> Eclipse Java Compiler v_774_R33x, 3.3.1, Copyright IBM Corp 2000, 2007. All rights reserved.
12:44 < penberg> ok I need $2 and $3 too
12:44 < vegard> there are none.
12:44 < penberg> $StaticClass
12:44 < vegard> it's there
12:45 < penberg> btw
12:45 < penberg> Exception in thread "main" java/lang/NoClassDefFoundError: (?c	.lang.VMClassTest$StaticClass
12:45 < penberg> nice buglet :-)
12:46 < penberg> ok I can reproduce
12:46 < penberg> Interesting!
12:46 < tgrabiec> I'll be back in few hours, see ya
12:46 < penberg> hah!
12:46 < penberg> vegard: Your ECJ doesn't set ACC_FINAL!
12:47 < vegard> ...?
12:47 < penberg> "anonymous classes are implicitly final"
12:47 < penberg> says JLS
12:47 < vegard> right
12:47 < penberg> but your ECJ doesn't set ACC_FINAL for the anonymous class!
12:47 < penberg> so I'll just nuke the damned check
12:47 < vegard> so why did they remove it in the newer ecj?
12:47 < penberg> we need class_is_inner() anyway
12:48 < penberg> compatibilty?
12:48 < penberg> dunno
12:48 < vegard> how can I generate 8- and 16-bit loads/stores?
12:50 < vegard> ah, mov with zero/sign extend?
12:50 < vegard> :q
12:50 < vegard> *k
12:53 < penberg> vegard: can you try the test again?
12:53 < vegard> did you push?
12:54 < penberg> github yes
12:55 < vegard> did you gegt my patches?
12:56 < penberg> yes.
12:57 < vegard> works now
12:57 < penberg> cool
12:58 < vegard> I still get this, though:
12:58 < vegard> jato/test/jit/jit-test-suite.c:226: undefined reference to `test_split_interval_at'
12:58 < vegard> oh
12:58 < vegard> probably need to remove a file
13:07 < vegard> movsx_8 can't be used for ESI/EDI ?
13:07 < vegard> oh
13:08 < vegard> nvm.
13:08 < ahuillet> x86... :)
13:18 < penberg> haha
13:18 < penberg> I implemented a JNI function!
13:25 < penberg> hmmh
13:25 < vegard> hm.
13:25 < penberg>   public <T> T[] toArray(T[] a)
13:25 < vegard> I wonder how we can MOV the lower part of ESI/EDI into memory
13:26 < penberg> Jato thinks a is not of array type.
13:27 < penberg>         if (class_name[0] == '[')
13:27 < ahuillet> vegard : we can't.
13:27 < penberg>                 return load_array_class(class_name);
13:27 < ahuillet> vegard : 8 bit mov for ESI EDI doesn't exist
13:27 < ahuillet> (AFAIK)
13:28 < vegard> ahuillet: how can we implement generic 8- and 16-bit field stores?
13:28 < ahuillet> vegard : 16bit is doable
13:28 < ahuillet> 8 bit is painful. :)
13:28 < penberg> native_vmclass_getcomponenttype: warning: java/util/HashMap$3
13:29 < penberg>   transient HashEntry<K, V>[] buckets;
13:29 < penberg> so AFACIT, the class_name[0] == '[' is just busted?
13:32 < penberg> mhmh
13:32 < penberg> no
13:42 < vegard> so, um. how to mov only the lower 16 or 8 bits of a reg to memory?
13:43 < vegard> do we need a new get_var() variant?
13:43 < vegard> one that doesn't give us ESI/EDI.
13:44 < vegard> I think I need to make MOV_{8,16}_REG_MEMBASE
13:46 < penberg_home> vegard: just fix get_var()
13:46 < penberg_home> actually.
13:46 < penberg_home> hmmmmmm
13:46 < penberg_home> nasty
13:46 < penberg_home> var has ->type doesn't it?
13:47 < penberg_home> I guess we need some register constraints based on type? hmm?
13:47 < penberg_home> in the register allocator
13:47 < vegard> yes.
13:47 < vegard> so for J_SHORT/J_BYTE/J_CHAR/J_BOOLEAN it won't give us ESI/EDI
13:47 < penberg_home> so pick_register needs to call some arch specific
13:47 < penberg_home> can_use_register(mach_reg, type) ?
13:48 < penberg_home> or just use get_fixed_var() ?
13:48 < vegard> what's keeping pick_register() from returning MACH_REG_XMM0 on non-xmm register requests?
13:49 < penberg_home> a check for type
13:49 < vegard>  (reg_type(i) != type) continue; ?
13:49 < penberg_home> yup
13:49 < vegard> we could just introduce a new register type?
13:49 < penberg_home> maybe you can fix reg_type?
13:49 < penberg_home> vegard: sure.
13:50 < vegard> or.. hmm..
13:50 < vegard> we want a _subtype_ actually
13:50 < penberg_home> yeah
13:50 < vegard> can we make register types be a bitset?
13:51 < vegard> um
13:52 < vegard> what's keeping pick_register() from returning ESP / EBP ?
13:52 < penberg_home> NR_REGISTERS
13:53 < vegard> ah, m.
13:55 < vegard> I'm a bit scared of introducing (even more?) hacks to register allocation
13:55 < penberg_home> why
13:55 < vegard> for 8- and 16-bit stores, we want to get EAX/EBX/ECX/EDX _only_
13:55 < penberg_home> yes
13:55 < penberg_home> why are you scared
13:56 < penberg_home> register constraints are _not_ a hack.
13:56 < penberg_home> they're part of reality.
13:56 < vegard> but for other things we want to _prefer_ EDI/ESI
13:56 < vegard> (in order to make them free for 8- and 16-bit)
13:56 < tgrabiec> vegard: i encountered the same problem for INT -> BYTE conversion
13:57 < penberg_home> tgrabiec: I did a missing JNI function for HelloWorldSwing
13:57 < vegard> tgrabiec: ah, and you use d a fixed var
13:58 < vegard> penberg_home: I don't mean that constraints is a hack
13:58 < vegard> penberg_home: but the manner of adding the logic to the register allocator should not be a hack
13:59 < ahuillet> <vegard> but for other things we want to _prefer_ EDI/ESI
13:59 < ahuillet> <vegard> (in order to make them free for 8- and 16-bit)
13:59 < penberg_home> sure
13:59 < ahuillet> the regallocator will handle that automatically
13:59 < ahuillet> just fin
13:59 < ahuillet> *fine
13:59 < tgrabiec> penberg_home: I cen see the same bug as you for HelloSwing
13:59 < penberg_home> ahuillet: how?
14:00 < penberg_home> AFAICT, "register_types" is bit too rigid
14:00 < ahuillet> penberg_home : well that's what the linear scan algorithm is about
14:00 < ahuillet> provided eax ebx ecx edx are a subtype of GPRs
14:00 < ahuillet> (ie. with a better logic)
14:00 < penberg_home> ahuillet: oh, sure.
14:00 < penberg_home> yes.
14:00 < tgrabiec> penberg_home: it seems that we call java.util.AbstractCollection.toArray() but we should call equals() !!!
14:01 < penberg_home> ahuillet: the reg_type(reg) != type is just too rigid for x86 :-)
14:01 < penberg_home> tgrabiec: oh?
14:01 < penberg_home> invokevirtual bug?
14:01 < penberg_home> interesting.
14:01 < ahuillet> penberg_home : I was just pointing out to vegard that he should not worry about the "preference" thing
14:01 < tgrabiec> dunno yet, I just came back
14:01 < vegard> ahuillet: yes, thanks
14:01 < penberg_home> ahuillet: oh, absolutely agreed
14:02 < vegard> so how can we make the reg types arch-specific? enum machine_reg_type is defined in jit/vars.h...
14:02 < penberg> reg_supports_type() ?
14:02 < penberg> vegard: we can do that.
14:02 < penberg> but you still have a problem
14:03 < penberg> because you'd then need to change get_var()
14:03 < penberg> maybe we can get rid of machine_reg_type completely
14:03 < penberg> and do an arch specific reg_supports_type() instead?
14:03 < penberg> and pass the jvm type there?
14:03 < vegard> I will try it
14:04 < vegard> thanks.
14:04 < tgrabiec> hmm
14:04 < vegard> in fact this shouldn't be hard at all
14:04 < tgrabiec> no objectsions to "jit: introduce per-edge data flow resolution blocks" ?
14:05 < penberg_home> tgrabiec: it's already merged.
14:05 < penberg_home> if ahuillet complains, we fix it up
14:05 < penberg_home> but I'm happy with it
14:05 < ahuillet> I need to look at it
14:05 < ahuillet> I want to understand why I screwed up
14:06 < ahuillet> and I'd like some litterature proving me wrong
14:06 < ahuillet> though I'm not asking you to provide it. :)
14:06 < ahuillet> tgrabiec : ping
14:06 < penberg_home> ahuillet: http://citeseer.ist.psu.edu/poletto99linear.html
14:06 < tgrabiec> ahuillet: pong
14:06 < penberg_home> the "resolution" part there
14:07 < ahuillet> tgrabiec : so you are *creating* new blocks is that it?
14:07 < penberg_home> wimmer says in he paper that the resolution is similar.
14:07 < penberg_home> ahuillet: yes.
14:07 < ahuillet> that are inserted on the edges that need resolution
14:07 < ahuillet> ok that's obviously theorically correct
14:07 < tgrabiec> ahuillet: yup
14:07 < penberg_home> the only problem there was the _generated instructions_
14:07 < ahuillet> penberg_home : AFAIK what I wrote followed wimmer's specifications.
14:07 < penberg_home> the _resolution_ algorithm is ok.
14:07 < ahuillet> oooooooooh wait
14:07 < ahuillet> except for one little thing
14:07 < ahuillet> wimmer said you had to decide whether to put the movs at the end or the beginning of the block
14:07 < ahuillet> conceptually they're "on the edge"
14:08 < penberg_home> yes.
14:08 < penberg_home> you had a small bug there
14:08 < ahuillet> but technically you have to put them at the end or at the beginning
14:08 < penberg_home> you inserted them at the end of the basic blok
14:08 < ahuillet> (or go for tgrabiec's solution)
14:08 < ahuillet> however
14:08 < penberg_home> but you forgot that execution can _continue_ in the basic block too.
14:08 < ahuillet> wimmer did not say *how* to decide where to put them
14:08 < penberg_home> so you clobbered some registers that were _in use_ in the basic block
14:08 < penberg_home> for mem -> reg resolution.
14:08 < tgrabiec> ahuillet: the point is that the register can be used in the branch instruction even
14:08 < ahuillet> so I said to myself something along the lines of "screw it, I'm sending that and they'll complain when they find a bug"
14:08 < ahuillet> so you actually ran into the bug I was thinking would appear
14:09 < penberg_home> :-)
14:09 < ahuillet> so we have tgrabiec's solution
14:09 < penberg_home> ahuillet: yeah
14:09 < ahuillet> or the less intrusive solution *not* described by wimmer
14:09 < penberg_home> right
14:09 < penberg_home> I guess wimmer generates less branches?
14:10 < penberg_home> the only downside in tomek's patch is that we need one extra branch per mem -> reg resolution edge.
14:10 < ahuillet> well, if it's easy to decide where to insert the mov
14:10 < ahuillet> I think tgrabiec's solution is overkill
14:10 < tgrabiec> I agree that it could be optimized
14:10 < ahuillet> but it's guaranteed to work so I'm in two minds
14:11 < ahuillet> let's read Poletto
14:11 < ahuillet> and see what it says
14:11 < penberg_home> tgrabiec, ahuillet: btw, should XMM use-def work now?
14:11 < ahuillet> yeah
14:11 < penberg_home> oh
14:11 < ahuillet> but we need to sanitize "use" in regalloc
14:11 < ahuillet> errr no it should not work
14:11 < ahuillet> sorry
14:11 < penberg_home> ok :)
14:21 < vegard> heh
14:21 < vegard> weirdnes!
14:21 < vegard> [MACH_REG_EDI] = GPR_32
14:21 < vegard> error: initializer element is not constant
14:21 < vegard> but [MACH_REG_EDI] = GPR_32 | GPR_16 is fine!!
14:22 < vegard> 0 | GPR_32 too.. so I'll use that.
14:23 < penberg_home> hmm
14:23 < penberg_home> what does GPR_32 look like?
14:23 < vegard> must be some gcc bug.
14:23 < vegard> it's a static const uint32_t
14:23 < penberg_home> make it a #define ?
14:33 < penberg> tgrabiec: any luck with the invokevirtual thing?
14:33 < tgrabiec> penberg: no, I'm still debugging
14:33 < penberg> ok, I though tthe JNI patch fixed it :-)
14:34 < tgrabiec> no no, I saw the JNI thing while reading you patches ;)
14:34 < tgrabiec> *your
14:34 < penberg> aah
14:34 < tgrabiec> but it was my mistake in the first place
14:35 < penberg_home> tgrabiec: I think we need to reduce duplication for those get_<primitive>_element jni functions somehow
14:35 < tgrabiec> sure. maybe the same thing as for vm_call_method_*() ?
14:39 < tgrabiec> how can I make javap use gnu classpath's classes ?
14:40 < tgrabiec> 'javap -bootclasspath /usr/local/classpath/share/classpath/glibj.zip java/util/AbstractMap' doesn't work
14:41 < penberg_home> tgrabiec: I usually unzip glibj.zip
14:41 < penberg_home> and run javap on the .class files.
14:41 < penberg_home> tgrabiec: you could also ask vegard
14:41 < penberg_home> maybe we need a helper script for that
14:42 < tgrabiec> thanks
14:50 < penberg_home> tgrabiec: oh
14:50 < penberg_home> I fixed my symbol resolution problems too!
14:50 < penberg_home> http://github.com/penberg/jato/commit/a2908926001d6f5707c0cecd6135b425e1ffe688
14:50 < tgrabiec> nice !
14:50 < penberg_home> it didn't work if you did make install
14:52 < tgrabiec> after I rebased to master, my HelloSwing doesn't work, it breaks early with weird Xserver messages
14:52 < tgrabiec> hmm
14:53 < tgrabiec> penberg: does it work for you? taht is, you get a nice exception
14:53 < penberg_home> let me see.
14:53 < penberg> yes, I get a nice exception
14:54 < penberg> tgrabiec: maybe vegard's field optimizations are busted somehow?
14:54 < penberg> wow!
14:54 < penberg> impressive
14:54 < penberg> frozen bubble already shows a window
14:55 < penberg> and then dies :-)
14:55 < tgrabiec> yeah, we're getting there !
14:55 < penberg> tgrabiec: http://pastebin.com/m24890261
14:55 < penberg> impressive!
14:55 < penberg> tgrabiec: try make clean/git clean and/or reverting vegard's patch
14:59 < tgrabiec> oh, it was because I unzipped the glib in current ;)
14:59 < tgrabiec> removing directories helped
15:02 < penberg_home> hehe
15:02 < penberg_home> that's a bug, though.
15:02 < tgrabiec> well, first things first
15:02 < penberg_home> sure
15:03 < tgrabiec> we have _invokeinterface_ bug
15:03 < tgrabiec> it should call equals() but calls toArray()
15:03 < penberg_home> vegard: invokeinterface bug alert!
15:05 < vegard> oh ?
15:06 < penberg> yes!
15:06 < penberg> vegard: tomek will tell you all about it.
15:06 < vegard> my kernel keeps crashing
15:06 < penberg> Jato is crashing, the kernel is crashing.
15:06 < penberg> Lets hope your CPU doesn't crash!
15:09 < tgrabiec> I'll tell, once I investigate it a bit
15:20 < tgrabiec> vegard: http://pastebin.com/d62780ad2
15:21 < tgrabiec> can you see anything obvious there, why we cann toArray instead of equals() ?
15:21 < tgrabiec> *call
15:35 < vegard> you can use -Xtrace:itable
15:35 < tgrabiec> thanks, will try
15:37 < vegard> hm
15:37 < vegard> this pointer is a HashMap
15:37 < vegard> oh, sorry
15:37 < vegard> HashMap$3
15:38 < tgrabiec> vegard: itable trace shows nothing from compilation of AbstractMap.equals() upto invocation of toArray()
15:38 < vegard> it should show during class loading
15:38 < tgrabiec> aha
15:39 < tgrabiec>  7: java/util/Collection.toArray([Ljava/lang/Object;)[Ljava/lang/Object;, java/util/Collection.equals(Ljava/lang/Object;)Z, java/util/Collection.contains(Ljava/lang/Object;)Z, java/util/Collection.toArray([Ljava/lang/Object;)[Ljava/lang/Object;, java/util/Collection.equals(Ljava/lang/Object;)Z, java/util/Collection.contains(Ljava/lang/Object;)Z, java/util/Set.toArray([Ljava/lang/Object;)[Ljava/lang/Object;, java/util/Set.equals(Ljava/lang/O
15:39 < tgrabiec> bject;)Z, java/util/Set.contains(Ljava/lang/Object;)Z
15:39 < tgrabiec> that's for HashMap$3
15:40 < vegard> hm. pastebin ?
15:40 < tgrabiec> http://pastebin.com/d68acb777
15:40 < vegard> ok, but
15:41 < vegard> the .toArray() has ret to AbstractMap.equals()
15:41 < tgrabiec> but it is called on HashMap$3
15:42 < tgrabiec> we should call HashMap$3.equals()
15:42 < tgrabiec> invokeinterface 0x00 0x4a 0x02 0x00 // java/util/Set.equals(Ljava/lang/Object;)Z
15:43 < vegard> er
15:43 < vegard> aren't we?
15:43 < tgrabiec> no, we call toArray() instead
15:43 < tgrabiec> there is no toArray call in there
15:45 < vegard> are you sure that these two highlighted lines really correspond?
15:45 < vegard> hm.
15:45 < tgrabiec> well, yeah. return address is AbstractMap.equals(). and this pointer is set to what entrySet() has just returned
15:46 < tgrabiec> we trace all invocation and all returns, toArray() is called immediately after entrySet returns
15:47 < vegard> hm
15:48 < vegard> btw, we have bytecode disassembly in traces now? :D
15:48 < tgrabiec> yup :)
15:48 < tgrabiec> and i've just made a patch to show method resolution after //
15:49 < tgrabiec> -Xtrace:bytecode
15:49 < tgrabiec> here is jit trace: http://pastebin.com/d29c5b4e2
15:50 < vegard> ok, let's look at the asm
15:51 < penberg_home> I'm guessing it's some bug in how we handle superinterfaces
15:52 < penberg_home> or a superclass implementing the same interface, to be exact.
15:52 < vegard> could also be a regalloc bug where we get the wrong object/class ;-)
15:53 < penberg_home> :-)
15:53 < vegard> but I knnow better than to blame the reg allocator ;)
15:53 < tgrabiec> the asm looks ok
15:53 < penberg_home> vegard: frozen bubble flashes a window already!
15:53 < vegard> penberg_home: wow ;)
15:54 < tgrabiec> who knows what happens when we fix this one
15:54 < vegard> was something wrong with my earlier patches?
15:55 < vegard> I thought I caught a glimpse of something before my kernel crashed last time
15:55 < vegard> my field reordering
15:55 < tgrabiec> I didn't see anything
15:55 < vegard> 14:51 < penberg> tgrabiec: maybe vegard's field optimizations are busted
15:55 < tgrabiec> we suspected them
15:55 < vegard> aha
15:55 < tgrabiec> but it was not it
15:56 < vegard> anyway, so, the invokeinterface is lines 333-336 of your last pastebin
15:56 < vegard> the add in 334 gives us the offset into the itable
15:57 < tgrabiec> what's a resolution stub?
15:57 < vegard> so if you take sizeof(struct vm_class) - 0xec and divide this by 4 we should get the itable index
15:57 < vegard> (can you do it with gdb?)
15:58 < vegard> resolution stub is a small "function" that will pick the right method to call in case two different methods hash to the same itable slot
15:58 < tgrabiec> how does it do it ?
15:58 < vegard> it jmps to the right function
15:58 < tgrabiec> how does it now which is right ?
15:58 < vegard> it finds the right one using a binary search of the method pointer address
15:59 < vegard> see the mov in line 335, this puts the method pointer into %eax
16:00 < tgrabiec> do you know how to easily catch JIT methods in gdb ?
16:00 < vegard> (I did the calculation and apparently we are using itable index 1)
16:00 < penberg_home> binary search, eh?
16:00 < vegard> but we should be using slot 7
16:01 < penberg_home> most people write broken binary search algorithms.
16:01 < penberg_home> btw, I asked if we can have a directory in ftp.kernel.org for a release.
16:01 < vegard> hm, or maybe not.
16:03 < vegard> no, Set.equals is also in slot 7
16:04 < vegard> tgrabiec: can you p (sizeof(struct vm_class) - 0xec) / 4 for me in gdb?
16:05 < tgrabiec> 1
16:06 < vegard> that's odd
16:06 < tgrabiec> vegard: method->itable_index is 7
16:06 < tgrabiec> I checked with printf
16:06 < tgrabiec> I don't know how to catch the bastard in gdb
16:07 < vegard> we could add -X:breakpont
16:07 < vegard> and emit an illegal innsn at the beginning of method
16:07 < tgrabiec> nice idea
16:21 < penberg> why not software breakpoints instead?
16:22 < tgrabiec> vegard: the binary search, what does it search for ?
16:22 < vegard> it searches for the right method
16:22 < tgrabiec> pointer to vm_method ?
16:22 < vegard> no
16:22 < vegard> entry point
16:22 < tgrabiec> so ->i_method is entry point ?
16:23 < vegard> no
16:23 < vegard> that's the struct vm_method *
16:24 < vegard> we map struct vm_method * -> entry point using the binary search
16:24 < vegard> this is why we load the struct vm_method * into %eax before calling the stub
16:24 < tgrabiec> what's c_method ?
16:25 < vegard> i_method = interface method
16:25 < vegard> c_method = class_method
16:25 < tgrabiec> aha
16:25 < vegard> the i_method doesn't have a body
16:26 < vegard> the c_method does
16:26 < vegard> it might be useful to print out the method address in the itable trace as well
16:27 < tgrabiec> __emit_cmp_imm_reg(buf, (long) table[m]->i_method, MACH_REG_EAX)
16:27 < tgrabiec> so we compare the struct vm_method pointer with eax right?
16:27 < vegard> yes
16:27 < vegard> eax is the "hidden parameter" which tells us which method we are searching for
16:28 < tgrabiec> well, I must say, that method pointers do not seem sorted in itable
16:28 < penberg> http://pastebin.com/m532be8d1
16:28 < tgrabiec> http://pastebin.com/d70071e57
16:28 < penberg> so when HelloWorldSwing runs AND we have 100% coverage of the instruction set AND we have a proper place for the release
16:28 < penberg> I shall tag + release.
16:29 < tgrabiec> vegard: they are not sorted, but they should be right ?
16:29 < tgrabiec> those numbers are ->i_method pointers
16:30 < vegard> tgrabiec: checkk out itable_entry_compare in vm/itable.c
16:30 < vegard> I guess I messed it up
16:31 < vegard> because it's an array of pointers
16:31 < vegard> and not an array of structs
16:31 < vegard> -       const struct itable_entry *ae = a;
16:31 < vegard> -       const struct itable_entry *be = b;
16:31 < vegard> +       const struct itable_entry *ae = *(const struct itable_entry **) a;
16:31 < vegard> +       const struct itable_entry *be = *(const struct itable_entry **) b;
16:31 < vegard> does it help?
16:32 < tgrabiec> yup :)
16:32 < tgrabiec> it helps
16:32 < vegard> bah
16:33 < penberg_home> const madness.
16:33 < vegard> no
16:33 < penberg_home> I should do s/const //g
16:33 < vegard> the problem is the reverse
16:33 < vegard> sort() is not type safe
16:33 < vegard> qsort*
16:33 < vegard> so the compiler can't warn us
16:34 < vegard> so how far does HWS go now?
16:35 < tgrabiec> well, it vomits with exceptions "java/lang/NumberFormatException: invalid character at position 2 in #000000"
16:35 < tgrabiec> and stops at java/lang/UnsatisfiedLinkError: java/lang/VMClass.getDeclaredFields(Ljava/lang/Class;Z)[Ljava/lang/reflect/Field;
16:35 < vegard> penberg_home: any idea why this doesn't work? http://folk.uio.no/vegardno/reg_supports_type.patch
16:35 < tgrabiec> so I guess the next step is to finish reflection
16:36 < vegard> tgrabiec: are you sending the patch or me?
16:36 < vegard> *or I
16:36 < penberg> vegard: depends on what "doesn't work" means
16:36 < vegard> penberg: doesn't get past the first "jit_m,agic_trampoline" line
16:36 < penberg> ->vm_type might not be reliable yet.
16:37 < vegard> oh
16:37 < penberg> what are the insn selector changes there?
16:37 < penberg> vegard: what I mean is, it's a possiblity that not everyone sets ->vm_type properly.
16:38 < penberg> it's not in widespread use yet
16:38 < vegard> ah right
16:38 < vegard> I'll look at it
16:38 < vegard> the insn-selector change is just.. um, halfway something else
16:38 < tgrabiec> vegard: you send it, just mention me
16:39 < penberg> vegard: the patch looks pretty nice and clean
16:40 < penberg> vegard: otoh, I'm not sure why that would matter
16:40 < penberg> +#define GPR_32 (1UL << J_REFERENCE) | (1UL << J_LONG)
16:40 < penberg> +#define GPR_16 (1UL << J_SHORT) | (1UL << J_CHAR)
16:40 < penberg> +#define GPR_8 (1UL << J_BYTE) | (1UL << J_BOOLEAN)
16:40 < penberg> +#define FPU (1UL << J_FLOAT) | (1UL << J_DOUBLE)
16:40 < penberg> do we cover all J_ thingies here?
16:40 < penberg> and why is that so damned ugly :-)
16:40 < vegard> hm
16:40 < vegard> not J_RETURN_ADDR
16:40 < vegard> I guess.
16:41 < vegard> sorry about the poor changelog
16:41 < penberg> add assertions for J_VOID and J_RETURN_ADDR?
16:41 < penberg> vegard: I think the insn selector changes could be the problem, actually.
16:42 < vegard> penberg: I don't even see -Xtrace:jit output
16:42 < penberg> vegard: and missing J_INT.....
16:42 < vegard> aha
16:42 < vegard> do we need that? :-(
16:42 < penberg> and btw.
16:43 < penberg> +#define GPR_32 (1UL << J_REFERENCE) | (1UL << J_LONG)
16:43 < penberg> I guess that's fine.
16:43 < penberg> the J_LONG in 32-bit is bit.
16:43 < penberg> well, you know, I think you should drop it.
16:43 < tgrabiec> J_REFERENCE is arch dependant
16:43 < penberg> no var should be J_LONG in 32-bit.
16:43 < penberg> tgrabiec: that's 32-bit code there.
16:43 < tgrabiec> aha
16:44 < vegard> yeah, so I put LONG instead of INT
16:44 < penberg> right.
16:44 < vegard> /excuse
16:46 < penberg> tgrabiec: I see a different crash: http://pastebin.com/m4e9b8cb6
16:46 < penberg> and bunch of warnings too
16:47 < tgrabiec> penberg: that's very close to where I get exceptions
16:47 < tgrabiec> so I'll just start debugging and we'll see :)
16:48 < penberg> we're executing a crazy amount of methods!
16:48 < penberg> -Xtrace:invoke.... phew!
16:51 < vegard> penberg: btw. pick_register() returns 0 by default... correct?
16:51 < tgrabiec> incorrect
16:51 < vegard> ok :)
16:51 < vegard> thanks, I put an assertion there
16:51 < tgrabiec> but I don't know how should we handle this
16:52 < tgrabiec> return _any_ sufficient register, or modify regalloc
16:52 < tgrabiec> vegard: we hit this problem for the XMM regalloc bug
16:52 < vegard> ah
16:53 < penberg_home> ok, so the register allocator bug is blocking this patch as well?
16:53 < ahuillet> ......
16:53 < ahuillet> grmbl
16:53 < ahuillet> I can't believe how much I screwed up with the regallocator
16:53 < ahuillet> there are more bugs than lines of code
16:54 < vegard> penberg_home: no, my patch SHOULD be a no-op
16:54 < vegard> in terms of what happens using the current insn-selector
16:55 < penberg_home> ahuillet: ;)
16:56 < penberg_home> hey, it's a tricky piece of code.
16:59 < vegard> penberg_home: I think do_get_var() is the only place that ever sets ->type for struct var_info
17:00 < vegard> HEHE
17:01 < vegard> compilation_unit_alloc passes GPR_VM_TYPE as enum vm_type to do_get_var
17:01 < vegard> oops.
17:02 < vegard> it IS a J_INT
17:03 < vegard> dinner!
17:06 < ahuillet> 5PM dinner. :)
17:23 < penberg_home> actually, 6PM here.
17:30 < penberg_home> so where should we announce v0.01
17:30 < penberg_home> freshmeat?
17:34 < ahuillet> sf.net
17:34 < ahuillet> website
17:34 < ahuillet> mmh
17:34 < ahuillet> lwn.net will release the announcement probably
17:34 < ahuillet> (if you send them)
17:35 < penberg_home> ahuillet: sf.net, how?
17:35 < ahuillet> well, put the release on their file release system
17:36 < penberg> ahuillet: I asked ftp.kernel.org for space to put the tarballs to.
17:36 < penberg> ahuillet: do you know where to send email for lwn.net?
17:37 < ahuillet> mmh
17:37 < ahuillet> press@lwn.net maybe
17:37 < ahuillet> I'll check that for you
17:37 < penberg> ahuillet: http://pastebin.com/m17d6b341
17:38 < ahuillet> penberg: lwn@lwn.net does work
17:39 < penberg> ok, we'll just put that in "bcc"
17:39 < ahuillet> note that they will probably copy paste the full email
17:39 < ahuillet> so don't do what I did
17:39 < ahuillet> http://lwn.net/Articles/223806/
17:39 < vegard> heh
17:39 < penberg> ahuillet: hilarious :-)
17:39 < ahuillet> #
17:39 < ahuillet> Tomek Grabiec, and Eduard-Gabriel Munteanu for making the release happend and
17:39 < ahuillet> s/happend/happen/
17:39 < ahuillet> penberg: not so much. :)
17:40 < vegard> penberg: if you wait till monday we can have gc
17:40 < penberg> vegard: oh, sure, we can do that too.
17:40 < penberg> just a matter of figuring out a new release code name :-)
17:40 < penberg> ahuillet: thnx fixed.
17:41 < penberg> so classpath list, lwn, freshmeat
17:41 < penberg> anything else?
17:41 < ahuillet> sf.net, they have a "project news" thing
17:41 < penberg> ok
17:41 < ahuillet> for freedroidRPG I use happypenguin.org too
17:41 < ahuillet> but it doesn't apply here :]
17:41 < ahuillet> maybe you can try java-rocks@sun.com or something like this
17:42 < penberg> :-)
17:42 < penberg> I was thinking of the openjdk lists
17:42 < ahuillet> announce a competitor on the list?
17:42 < ahuillet> :/
17:42 < penberg> but as we only support classpath, I don't think that's warranted
17:42 < penberg> openjdk can also be used just like classpath
17:42 < penberg> LKML?
17:43 < penberg> :-X
17:43 < ahuillet> your being a kernel developer makes it possible without getting flamed too badly
17:43 < ahuillet> but it's a terrible idea :)
17:43 < penberg> heh heh
17:43 < penberg> just kidding!
17:47 < penberg> ahuillet, tgrabiec, vegard: any features I missed?
17:47  * penberg is off for an hour or so.
18:20 < tgrabiec> it was a bug in utf8_to_char_array()
18:29 < vegard> hm
18:32 < vegard> http://folk.uio.no/vegardno/0001-jit-add-support-for-register-constraints.patch
18:32 < vegard> this is supposed to be reall easy :(
18:49 -!- t_grabiec [n=tomekg@aenf228.neoplus.adsl.tpnet.pl] has joined #jato
18:49 -!- tgrabiec [n=tomekg@abro203.neoplus.adsl.tpnet.pl] has quit [Read error: 110 (Connection timed out)]
18:57 < vegard> hm
18:58 < t_grabiec> have I missed something?
18:59 < vegard> no :)
19:02 < penberg_home> so
19:02 < penberg_home> vegard: can I have a proper fix?
19:02 < vegard> penberg_home: it doesn't work
19:02 < vegard> for some reason or another.
19:03 < t_grabiec> vegard: I saw you email
19:03 < penberg_home> vegard: i meant the utf-8 thing.
19:03 < t_grabiec> so we just remove the error() line, right ?
19:03 < penberg_home> you can see the problem in SwingHelloWorld.
19:03 < vegard> t_grabiec: not just that
19:04 < t_grabiec> vegard: try Color.decode("#000101");
19:04 < vegard> t_grabiec: there is a kind of symmetry between utf8_char_count and utf8_to_char_array
19:04 < vegard> if you take out the ++i from the utf8_to_char_array(), why shuouldn't we take it out from utf8_char_count()?
19:04 < t_grabiec> oh, I just didn't see it
19:04 < vegard> the two functions are structurally very similar, and I'm scared of breaking that
19:05 < t_grabiec> so it needs fixing too
19:05 < vegard> t_grabiec: what happens with the Color.decode() ?
19:05 < t_grabiec> vegard: it exposes the bug
19:05 < vegard> but I don't understand the problem here
19:05 < vegard> what is the byte sequence that fails?
19:06 < t_grabiec> vegard: the point is that the array in gnu/java/lang/CharData is initialized incorrectly
19:06 < t_grabiec> there is bunch of lookup tables initialized with strings
19:06 < t_grabiec> they are used to get character properties
19:06 < t_grabiec> the bug is, that the DATA[] array is initialized incorrectly, hence character '0' has wrong attributes
19:07 < t_grabiec> and decode throw exception
19:07 < vegard> I would like to see a smaller test-case
19:07 < vegard> and understand WHAT it is that goes wrong
19:07 < t_grabiec> well, it's pretty simple. look at the old utf8_to_char_array()
19:07 < t_grabiec> now
19:08 < t_grabiec> if we hit this path: if ((bytes[i] & 0xe0) == 0xc0) {
19:08 < t_grabiec> the 'i' is incremented _twice_
19:08 < t_grabiec> and when the iteration ends, we incremetn i one more time
19:08 < vegard> so why isn't the proper fix to remove the last i++ in there?
19:09 < t_grabiec> vegard: could be
19:09 < vegard> (and the other if())
19:09 < t_grabiec> but mine works just fine
19:09 < vegard> I MUCH prefer that
19:09 < vegard> because that matches the structure of utf8_char_count()
19:09 < vegard> and because ++i in the for() is the idiom
19:09 < penberg_home> vegard: you have an almost scary attitude towards "your code" :-)
19:10 < vegard> well, this has to do with readability
19:10 < t_grabiec> ok, so I shall resend it ?
19:10 < vegard> these string functions are very fragile
19:11 < vegard> t_grabiec: can you try to take out the last i++ from each of the last two if()s and see if this also fixes the problem?
19:11 < vegard> and then resend if it works :p
19:11 < t_grabiec> vegard: it probably will work as well, will o as you say
19:11 < t_grabiec> *will do
19:25 < penberg_home> vegard, t_grabiec: in all fairness, I don't like the patch either :-)
19:26 < penberg_home> for (unsigned int i = 0, j = 0; i < n;) {
19:26 < t_grabiec> ok ok
19:26 < penberg_home> this just makes my head hurt ;)
19:26 < penberg_home> the original is pretty scary as it is
19:26 < ahuillet> come on guys UTF8 rocks
19:27 < ahuillet> it's just so easy to work with, so nice, and it is a very important step towards peace in the world
19:27 < ahuillet> the encoding wars are over now thanks to unicode
19:27 < t_grabiec> vegard, penberg_home: resent (with a regression test), how about it now ?
19:27 < penberg_home> t_grabiec: I'm okay with it.
19:27 < penberg_home> vegard: you?
19:27 < ahuillet> (don't mind me)
19:28 < penberg_home> ahuillet: :)
19:30 < penberg> t_grabiec: tabs.
19:30 < penberg> fixed them
19:31 < t_grabiec> penberg: thanx!
19:31 < penberg> t_grabiec: I see this now http://pastebin.com/m6821e085
19:31 < penberg> vegard: I'm inclined to push if you don't NAK the patch real soon now.
19:32 < t_grabiec> penberg: I don;t see it, I see complains about missing reflection stuff instead
19:32 < penberg> t_grabiec: aah, we have different versions of classpath, don't we?
19:32 < vegard> sorry, I had 1 kernel crash and one net outage, looking at the patch now
19:32 < t_grabiec> penberg: yup, probably
19:32 < penberg> vegard: what's wrong with your kernels?
19:33 < t_grabiec> penberg: so I probably fix mine first, then yours
19:33 < penberg> penberg@penberg-laptop:~/testing/jato$ dpkg -l|grep classpath
19:33 < penberg> ii  classpath                                  2:0.96.1-1ubuntu3                                          clean room standard Java libraries
19:33 < ahuillet> he's adding unicode support :)
19:33 < penberg> t_grabiec: sure.
19:33 < vegard> hm
19:33 < vegard> so this is what was wrong?
19:33 < penberg> t_grabiec:
19:33 < penberg> toplevel/vm/bytecodes.o: In function `bytecode_disassemble':
19:33 < penberg> /home/penberg/src/jato/test/vm/../../vm/bytecodes.c:288: undefined reference to `vm_class_resolve_interface_method'
19:33 < penberg> /home/penberg/src/jato/test/vm/../../vm/bytecodes.c:291: undefined reference to `vm_class_resolve_method'
19:33 < ahuillet> ok, I definitely am bored, I'll let you work in peace
19:33 < vegard> no
19:33 < vegard> t_grabiec: I wanted to keep the i++ and remove the _last_ one in each if()
19:34 < vegard> oh
19:34 < vegard> but this matches utf8_char_count
19:34 < vegard> ok then I'm happy!
19:34 < vegard> thanks, acked-by
19:34 < penberg> vegard: thanks
19:34 < t_grabiec> penberg: oops
19:35 < t_grabiec> want me to fix that ?
19:35 < penberg> I think I can just add the stubs to vm tests?
19:35 < t_grabiec> yup
19:36 < vegard> penberg: my kernels crash because of the mobile broadband modem
19:36 < vegard> penberg: apparently it doesn't like it so well when I hot-unplug it
19:36 < ahuillet> mobile broadband ?
19:36 < vegard> is a usb device, so it should be fine. but this is 2.6.27-something-something-f10 so more or less ancient.
19:36 < ahuillet> you did say something about having had some mobile internet access, but I don't remember more
19:36 < vegard> yup, using it now
19:37 < vegard> a bit unstable atm, but it was really great earlier and yesterday.
19:37 < vegard> get 200 KB/s down, so it's pretty good. typing in ssh is noticably laggy, but it's also fine (good enough for irc).
19:38 < ahuillet> 200KB/s is good
19:38 < penberg> vegard: where are you located now?
19:38 < ahuillet> that's pretty much what we have @Bull
19:38 < vegard> penberg: next to my grandma's house
19:39 < ahuillet> (no kidding... my employer really has the worst internet connection I've seen in a company)
19:39 < penberg> vegard: aah
19:39 < vegard> ahuillet: wow. btw, in germany I used the TU darmstadt internet, and I got something like 10 MB/s to my university
19:42 < penberg> t_grabiec: btw, _all_ tests fail with the same error:
19:42 < penberg> Caused by: java/lang/NullPointerException at java.awt.AWTKeyStroke$2.run(AWTKeyStroke.java:129)
19:43 < t_grabiec> penberg: what do you mean by _all_ ?
19:43 < t_grabiec> tetris and frozenbuble ?
19:43 < penberg> t_grabiec: yes and swing too.
19:44 < t_grabiec> ok, so.. debugging :]
19:44 < penberg> I am trying SciMark2!
19:45 < penberg> haha
19:45 < penberg> http://pastebin.com/m6a79a2fc
19:45 < penberg> http://math.nist.gov/scimark2/download_java.html
19:45 < t_grabiec> heh
19:45 < penberg> I guess we don't pass args properly :)
19:45 < t_grabiec> he's right
19:46 < t_grabiec> we don't pass them at all, the pointer is random value
19:46 < penberg> :-)
19:46 < penberg> cool
19:47 < penberg> anyway, scimark is really easy to run
19:47 < penberg> a console app
19:47 < penberg> and a benchmark.
19:47 < penberg> part of my test suite now :-)
19:48 < vegard> I'm choking as soon as we try to request a J_FLOAT
19:48 < vegard> or rather, jato is
19:48 < vegard> my patched jato.
19:49 < ahuillet> what's scimark?
19:50 < t_grabiec> vegard: do we initialize interface classes somewhere ?
19:50 < t_grabiec> ok, never mind
19:52 < penberg_home> ahuillet: http://math.nist.gov/scimark2/download_java.html
19:52 < penberg_home> "SciMark 2.0 is a Java benchmark for scientific and numerical computing."
19:52 < ahuillet> oh.
19:52 < ahuillet> great thing to test register allocator improvements then
19:52 < ahuillet> and optimizations in general
19:53 < penberg_home> :)
19:55 < penberg_home> ahuillet: it's not that good apparently
19:55 < penberg_home> http://www.azulsystems.com/events/javaone_2009/session/2009_J1_Benchmark.pdf
19:55 < penberg_home> search for "scimark" there
19:57 < vegard> so um
19:57 < penberg_home> ahuillet: http://www.cs.man.ac.uk/~irogers/flumps/p70-tartara.pdf
19:57 < ahuillet> penberg: I'm reading the whole thing
19:57 < penberg_home> ahuillet: 4.2 Instruction selection
19:57 < penberg_home> explains what they do
19:57 < vegard> t_grabiec: can you tell me some more about pick_register() and the ret which is initialized to 0 by default
19:57 < penberg_home> the papers are unrelated :)
19:58 < ahuillet> 3-letter-company "spammed" it by replacing with
19:58 < ahuillet>  intrinsic doing a CompareAndSwap (CAS)
19:58 < ahuillet> that would be AMD in 3Dnow+
19:58 < ahuillet> IIRC
19:58 < penberg_home> vegard: the default zero is bogus value
19:59 < penberg_home> AFAICT, pick_register() should always find a register.
19:59 < vegard> but apparently it happens a lot
19:59 < vegard> ?
20:00 < vegard> it happens for mainline
20:00 < penberg_home> that would be a bug.
20:00 < ahuillet> pick_register cannot not find anything
20:00 < ahuillet> it's not possible
20:01 < vegard> http://pastebin.com/ma894b8c
20:01 < vegard> so you see it doesn't get very far..
20:01 < ahuillet>         if (pos > max_pos) {
20:01 < ahuillet> try with >= instead
20:02 < vegard> much better
20:02 < ahuillet> or initialize max_pos to -1
20:02 < vegard> thanks
20:02 < ahuillet> otherwise it cannot work
20:02 < vegard> well this crashes after a while too
20:02 < ahuillet> bc06c419 (Pekka Enberg      2008-05-23 11:28:08 +0300  83)      unsigned long max_pos = 0;
20:02 < ahuillet> bc06c419 (Pekka Enberg      2008-05-23 11:28:08 +0300  92)              if (pos > max_pos) {
20:02 < ahuillet> heheh :]
20:03 < ahuillet> vegard : yes, but at least one bug is fixed
20:03 < vegard> Exception in thread "main" java/lang/NoClassDefFoundError: java/lang/System
20:03 < penberg> ahuillet: :-)
20:03 < vegard> but it gets really far...
20:03 < penberg> vegard: yeah, we want that assert in.
20:04 < ahuillet> penberg: you can prove statically that the condition will always be true
20:04 < ahuillet> with >=
20:05 < penberg> what do you mean?
20:05 < penberg> http://pastebin.com/ma894b8c
20:05 < penberg> is absolutely correct
20:05 < penberg> we _can't_ return a default value zero
20:05 < ahuillet> definitely
20:05 < penberg> because that's broken for fpu regs for starters
20:05 < ahuillet> and it's also useless with the >= thing
20:05 < vegard> http://pastebin.com/m755fbeb8
20:05 < ahuillet> vegard : ACK on that anyway
20:06 < vegard> but it breaks all our regression tests :)
20:06 < vegard> so we need to FIX it too.
20:06 < ahuillet> wtf?
20:07 < vegard> (note: that "we" really means "you", since I have no idea what the code is supposed to be doing anyway ;-))
20:07 < penberg> should we _break_ when we find a register?
20:07 < ahuillet> penberg: no, we want the one that's used the latest
20:07 < penberg> ahuillet: ok.
20:07 < ahuillet> hence the max_pos thing
20:07 < penberg> vegard: ship it in when regression tests pass again :-)
20:07 < ahuillet> if all registers are used at 0
20:07 < ahuillet> max_pos = 0 and > test is a bug
20:07 < penberg> ahuillet: yeah, the fix makes tons of sense.
20:08 < penberg> ahuillet: agreed.
20:10 < vegard> hm
20:10 < vegard> I think I might have messed up something else
20:12 < vegard> ok it works
20:12 < vegard> thanks
20:12 < ahuillet> mmh?
20:12 < vegard> no need to submit a patch
20:12 < ahuillet> vegard : that one patch can't break regression tests
20:12 < vegard> because I'm changing it anyway
20:12 < ahuillet> or something is seriously screwed
20:12 < ahuillet> anyway please submit the >= thing because it's a bug fix
20:13 < penberg_home> vegard: you might have fixed the infinite loop thing.
20:13 < penberg_home> http://jato.lighthouseapp.com/projects/29055/tickets/5-sse-registers-are-saved-and-registered-unconditionally#ticket-5-1
20:14 < vegard> no, ahuillet did it
20:14 < penberg_home> yes
20:14 < ahuillet> I actually thought that this happened
20:14 < penberg_home> please send the patch!
20:14 < ahuillet> but said to myself that pick_register could not be wrong
20:14 < ahuillet> therefore not even reading it
20:14 < ahuillet> (because it's so simple etc.)
20:15 < ahuillet> "put micro trust in a micro benchmark"
20:15 < ahuillet> hahahaha
20:17 < vegard> bleh
20:17 < penberg_home> the author of those slides (cliff click) worked on the hotspot JVM
20:17 < vegard> it doesn't fix the problem when I also apply my patch :)
20:17 < penberg_home> :(
20:19 < vegard> I noticed that most of our patches don't have descriptions these days. or were those all mine?
20:23 < penberg_home> vegard: most of them are pretty simple.
20:24 < vegard> ah.
20:26 < vegard> so what happens is apparently that somebody requests get_var(J_CHAR)
20:26 < vegard> before, that might give back ESI or EDI and now it can't
20:27 < penberg_home> vegard: for example, [PATCH 1/2] vm: implement VMClass.getComponentType()
20:27 < penberg_home> dunno why that needs more description
20:28 < vegard> so convert_array_load() calls get_var() with type == J_CHAR
20:37 < vegard> hm
20:38 < vegard> Exception in thread "main" java/lang/Error: java/io/IOException: file descriptor already initialized
20:43  * vegard cries with happiness
20:45 < ahuillet> ?
20:46 < vegard> it finally worke
20:46 < vegard> d
20:46 < vegard> it was another patch in my queue causing the grief
20:49 < vegard> hm. apparently needs a bit more love.
20:50 < vegard> if I don't make ESI + EDI available for J_{SHORT,CHAR,BYTE,BOOLEAN}, we get an infinite loop somewhere and my machine crashes with OOM
20:52 < penberg_home> buy more ram!
20:59 < ahuillet> best release codename ever :)
21:01 < vegard> hm
21:01 < vegard> target_method: [0xac93d80 'java/lang/VMClassLoader.getPrimitiveClass(C)Ljava/lang/Class;']
21:01 < vegard> arg_expression: [value int 0x49]
21:01 < vegard> so the argument is a char, but the HIR says "value int"
21:01 < vegard> does this matter?
21:03 < vegard> I think we have a serious problem
21:03 < penberg> vegard: yes?
21:04 < vegard> since a "call" instruction
21:04 < vegard> only esi and edi are ever allocated
21:05 < penberg> yes, that sounds serious :-)
21:06 < vegard> so it seems that we are starved on registers
21:07 < vegard> and when denying ESI/EDI to types smaller than INT
21:07 < vegard> crash
21:09 < vegard> http://folk.uio.no/vegardno/trace.txt
21:10 < vegard> in fact, seems that e{a,b,c,d}x are never given out except to fixed regs
21:10 < vegard> ?
21:10 < penberg> hmm
21:11 < penberg> well, don't look at me, I've had a glass of wine already!
21:11 < vegard> edx/ecx/eax are fixed in pos 8-25(29 for eax)
21:11 < penberg> why
21:12 < penberg> vegard: it could be our fixed var unification thingy?
21:12 < penberg> commit d09b2523d8f08d200ea1da0cb05754e4a82b1fd8
21:12 < penberg>     jit: Preallocate struct var_infos for fixed registers
21:12 < penberg> vegard: that said, it shouldn't be a problem as we should be splitting the intervals
21:14 < vegard> but most of them are fixed from position 8
21:14 < vegard> which is a call_rel
21:14 < vegard> DECLARE_INFO(INSN_CALL_REL, USE_NONE | DEF_xAX | DEF_xCX | DEF_xDX)
21:14 < ahuillet> http://paste.pocoo.org/show/URIiRuFxlwpV2Wz4czso/
21:14 < ahuillet> this patch is supposed to help about your current problem vegard
21:14 < ahuillet> but it needs more work
21:14 < vegard> so it's a known thing?
21:23 < ahuillet> yup
21:23 -!- Eduard_Munteanu [n=Simi@93.112.61.241] has joined #jato
21:23 < Eduard_Munteanu> Hi.
21:24 < penberg_home> Eduard_Munteanu: hi!
21:24 < penberg_home> did you enjoy the seaside?
21:24 < Eduard_Munteanu> penberg, penberg_home, I've had and I still have issues with my laptop, so I couldn't be online.
21:24 < penberg_home> Eduard_Munteanu: oh :(
21:24 < Eduard_Munteanu> penberg_home: will bb on monday morning.
21:24 < penberg_home> Eduard_Munteanu: well don't worry, we changed everything and I think x86-64 is busted again :)
21:24 < penberg_home> Eduard_Munteanu: S.o.println() works on 32-bit!
21:25 < Eduard_Munteanu> penberg_home: fortunately I could plug my hdd into a friend's laptop.
21:25 < Eduard_Munteanu> penberg_home: wow, nice :)
21:25 < penberg_home> Eduard_Munteanu: oh, so your laptop is completely busted?-(
21:26 < Eduard_Munteanu> penberg_home: yeah, something along those lines. It won't power on, tried everything. Will change it when I get back in my city
21:27 < penberg_home> right
21:27 < penberg_home> well I hope you don't lose any data.
21:27 < penberg_home> that sucks big time.
21:27 < Eduard_Munteanu> penberg_home: no, the HDD is okay, I plugged in a friend's laptop to work.
21:27 < Eduard_Munteanu> s/in/it in/
21:28 < penberg_home> aah ok
21:29 < Eduard_Munteanu> penberg_home: I fixed EXPR_INSTANCE_FIELD (which I was bugging tgrabiec about), that sizeof() stuff is completely broken. I replaced it with offsetof(). Could've been affecting 32-bit as well.
21:29 < penberg_home> Eduard_Munteanu: ok, be careful though, there's plenty of updates to insn selector
21:30 < penberg_home> Eduard_Munteanu: and oh, we do SSE2 double precision floating points now
21:30 < penberg_home> should be straight-forward to reuse for 64-bit
21:30 < penberg_home> hmm, github is down.
21:31 < vegard> ahuillet: changing the > to >= busts test_allocates_different_registers_for_overlapping_intervals()
21:33 < Eduard_Munteanu> penberg_home: unfortunately I can't get the internet connection working on Linux when I move the hdd around, so I'll try to send the patches another way. Sorry for being out :)
21:34 < penberg_home> Eduard_Munteanu: by snail mail?-)
21:34 < Eduard_Munteanu> :))
21:35 < Eduard_Munteanu> Perhaps I can export the patches, copy them to another HDD and send them from Vista.
21:35 < penberg_home> what's the problem with internet connection btw?
21:36 < penberg_home> missing driver or something?
21:37 < Eduard_Munteanu> penberg_home: it's a darn Zapp modem over GPRS. Now I'm speaking from a Vista.
21:39 < penberg_home> :(
21:39 < penberg_home> http://www.zappmobile.ro/data/en-drivers.html
21:39 < penberg_home> there's a shell script with romanian comments :)
21:41 < vegard> penberg: I sent a patch series
21:41 < vegard> penberg_home: it doesn't serve its purpose yet but at least it doesn't break anything
21:41 < penberg_home> vegard: right
21:42 < Eduard_Munteanu> penberg_home: wow, it's worth a shot. Thanks. I only googled for the modem model number and Linux and I couldn't set it up using what I found.
21:42 < penberg_home> Eduard_Munteanu: cool
21:42 < penberg_home> vegard: ok, I'll merge those suckers!
21:43 < penberg> vegard: I guess that breaks 64-bit?
21:44 < Eduard_Munteanu> penberg_home: anyway, I'm back on Monday morning. Hopefully my work on the current tree snapshot will be okay once I fetch.
21:44 < penberg> I'm pretty sure there will be merge conflicts :-)
21:45 < penberg> and new breakage too.
21:45 < penberg> Eduard_Munteanu: we're not doing it on purpose, honest! :-)
21:46 < penberg> vegard: pushed.
22:00 < ahuillet> +		/* XXX: We can't access the lower nibbles of these registers,
22:00 < ahuillet> +		 * so they shouldn't have GPR_16 or GPR_8, but we need it for
22:00 < ahuillet> +		 * now to work around a reg-alloc bug. */
22:00 < ahuillet> need it for correctness?!
22:12 < t_grabiec> vegard: is your vm_type_size() going to replace current get_vmtype_size() ?
22:13 < vegard> oh
22:13 < vegard> t_grabiec: sorry, I didn't realize that had sneaked in
22:14 < vegard> t_grabiec: I wrote it first without knowing we had one
22:14 < vegard> t_grabiec: and then I forgot to remove it probably
22:14 < vegard> yes, it seems to be unused
22:14 < t_grabiec> ok
22:15 < t_grabiec> anyway, you can rename it to vm_type_size() if you want
23:25 -!- Eduard_Munteanu [n=Simi@93.112.61.241] has quit [Read error: 54 (Connection reset by peer)]
23:35 < t_grabiec> wow, error: unknown bytecode opcode: 0xab
23:36 < t_grabiec> time for lookupswitch
23:40 < vegard> :D
23:40 < vegard> what are you running?
23:40 < t_grabiec> HelloWorldSwing
23:40 < t_grabiec> it goes pretty far
23:40 < vegard> can  you see any components? :D
23:41 < t_grabiec> not yet
23:41 < vegard> um I guess it has only a JLabel
23:41 < t_grabiec> and JFrame
23:41 < t_grabiec> I'm stuck on javax/swing/JLayeredPane.getObjectForLayer
23:42 < vegard> remember the regalloc problem
23:42 < vegard> or rather
23:42 < vegard> we have a few different outstanding issues ;)
23:43 < t_grabiec> which issues ?
23:44 < vegard> hm.
23:44 < vegard> I guess we fixed them :D
23:44 < vegard> but like you said, unknown opcode.
23:45 < vegard> we also have still missing jnis and natives
23:46 < t_grabiec> yeah, my work is like doing: JNI, JNI, JNI, native, JNI, regallocbug, JNI, JNI, JNI, somebug, ...
23:46 < vegard> :-p
23:46 < vegard> well, time to sleep
23:47 < t_grabiec> good night
--- Log closed Sun Aug 09 00:00:22 2009