--- Log opened Fri Jun 26 00:00:44 2009
00:01 < tgrabiec> A class or interface has at most one class or interface initialization method and is initialized (§2.17.4) by invoking that method. The initialization method of a class or interface is static and takes no arguments. It has the special name <clinit>
00:01 < tgrabiec> ^-- that was a quotation from VM spec
00:27 < tgrabiec> i think it's enough for me today, good night :)
00:27 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has quit ["Leaving"]
02:34 -!- ahuillet_ [n=user@239.34.83-79.rev.gaoland.net] has quit ["Leaving"]
08:45 <@penberg> vegard: vm/jato.c:native_vmruntime_println()
08:45 <@penberg> we need some field accessors
08:45 <@penberg> field_get_int32() or something.
08:45 <@penberg> the open-coded casts almost made me blind
08:46 < vegard> ah
08:46 < vegard> I think tgrabiec was working on splitting that out in a separate function, vm_string_to_cstr
08:47 < vegard> so I won't touch it for now
08:47 <@penberg> opk
08:47 < vegard> what do you propose, a macro?
08:48 <@penberg> vegard: static inline.
08:48 <@penberg> int32_t vm_field_get_int32()
08:48 <@penberg> vegard: btw, isn't it nice how well ahuillet and tgrabiec took all the breakage we caused?
08:48 <@penberg> and started helping out.
08:48 <@penberg> almost brought a tear to my eye ;)
08:48 < vegard> ...lol
08:48 <@penberg> what a friendly and helpful development team!
08:49 < vegard> #define vm_object_get(obj, field, type) *(type *) &obj->fields[field->offset];
08:49 <@penberg> compare that to LKML ;)
08:49 <@penberg> so
08:49 <@penberg> what's wrong with a static inline?
08:49 < vegard> um, C doesn't have templates
08:49 < vegard> so we have to create a separate static inline for each type
08:49 <@penberg> yes, so? it's not as if there's thousands of different cases
08:49 <@penberg> lets avoid macros.
08:50 <@penberg> they cause more problems than they solve.
08:50 < vegard> fields can be primitive types or object references
08:50 <@penberg> use sed to generate the damned accessors
08:50 < vegard> heh, ok
08:50 <@penberg> yes, so then you return "struct object *"
08:50 <@penberg> it's not as if you're ever going to return any actual type
08:50 <@penberg> except for string maybe
08:50 <@penberg> but that's it.
08:50 < vegard> any thoughts on whether we should name them after the java types or the C type equivalents?
08:51 < vegard> so .._int32 or _int
08:51 <@penberg> well, I have been thinking of
08:51 <@penberg> jint
08:51 <@penberg> jlong
08:51 <@penberg> and so on
08:51 <@penberg> typedefs.
08:51 < vegard> yeah, good idea!
08:51 <@penberg> but!
08:51 <@penberg> I do like int32 a lot
08:51 <@penberg> because it explicitly spells out the size.
08:52 <@penberg> so I dunno.
08:52 <@penberg> and lets not use underscore as a prefix!
08:52 <@penberg> this is userspace.
08:52 < vegard> heh, yeah :)
08:52 < vegard> it was a suffix (in my q.)
09:20 <@penberg> so
09:20 <@penberg> is float always guaranteed to be 32-bit
09:20 <@penberg> and double 64-bit?
09:21 <@penberg> do we have C typedefs for jfloat and jlong?
09:40 < vegard> don't know.
09:40 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has joined #jato
09:41 <@penberg> vegard: I think I'd prefer to stay away from the "jint" and "jlong" typedefs, actually.
09:42 <@penberg> I am fantasizing of implementing a CLR (that's .NET) front-end one day.
09:42 <@penberg> so I'd like to keep the vm as instruction set agnostic as possible.
09:42 <@penberg> (except for the _java_ parts, of course)
09:42 < tgrabiec> penberg: it's not my patch's fault that regression fails. It just shows that there is exception thrown and that's why this patch is so important
09:43 <@penberg> tgrabiec: aah?
09:43 <@penberg> is there a fix for that?
09:43 <@penberg> I'm not merging anything that makes "make regression" fail out-of-the box. So if you don't have fix for the test cases, then you should disable them and add a FIXME comment there.
09:43 < tgrabiec> penberg: something is broken after vegard's merge, many tests start to throw NullPointerException
09:44 <@penberg> ok
09:44 <@penberg> vegard: can you please take a look at that with tgrabiec ASAP?
09:44 <@penberg> tgrabiec: I'd really prefer your patch came with a fix for the problem it exposes ;)
09:45 <@penberg> but like I said, if you must, then disable the broken tests.
09:45 <@penberg> but never ever make "make regression" fail by default.
09:45 <@penberg> because then I won't be able to detect breakage when I apply a patch.
09:45 <@penberg> new breakage, that is.
09:46 < tgrabiec> i didn't think about that, you're right :)
09:47 <@penberg> I really rely on make regression heavily.
09:47 <@penberg> to try to make sure we don't _regress_ without knowing about it.
09:47 <@penberg> it's not a perfect system obviously (because vegard's breakage snuck in)
09:48 <@penberg> but it's better than keeping our eyes closed and entering long debugging marathons trying to figure what the hell happened ;)
09:48 <@penberg> tgrabiec: did you look at the bug at all?
09:49 < tgrabiec> penberg: not yet
09:49 < tgrabiec> i'll take a look asap
09:49 < vegard> I'm going to a funeral, will be back in some hours
09:50 <@penberg> vegard: ok.
09:54 <@penberg> tgrabiec:
09:54 <@penberg> vm/stack-trace.c:62: warning: init_stack_trace_printing not implemented
09:54 <@penberg> jit/object-bc.c:470: warning: convert_instanceof not implemented
09:54 <@penberg> compile_error: Failed to compile method `testIsInstanceOf' in class `jvm/ObjectCreationAndManipulationTest', error: -22
09:54 <@penberg> jvm.ObjectCreationAndManipulationTest FAILED. Expected 0, but was: 1.
09:54 <@penberg> convert_instanceof
09:54 <@penberg> NOT_IMPLEMENTED
09:54 <@penberg> pretty bad ;)
09:57 <@penberg> I am fixing it.
10:05 <@penberg> ok, fixed one regression test ;)
10:05 < tgrabiec> nice :)
10:07 <@penberg> jvm.ObjectCreationAndManipulationTest has some more breakage
10:07 <@penberg> as does ExceptionTest
10:08 <@penberg> testMultiANewArray
10:09 <@penberg> array load/store looks to be busted
10:12 <@penberg> hgmm
10:12 <@penberg> array = new Object[5][4] results in 'null'
10:13 < tgrabiec> ExceptionTest fails because array_store_check is not implemented
10:14 <@penberg> hmm
10:14 <@penberg> I figured out the multianewarray one...
10:15 <@penberg> vm_object_alloc_multi_array() always returns NULL
10:15 < tgrabiec> yes, that's weird
10:16 <@penberg> no, that's broken ;)
10:16 < tgrabiec> yes, definetely
10:16 < tgrabiec> :)
10:18 <@penberg> well, unfortunately that exposes the new bugz ;)
10:18 <@penberg> yup
10:18 <@penberg> array load/store up next.
10:19 < tgrabiec> oh, and ExceptionsTest fail because vm_class_is_assignable_from() is not implemented, hence we can catch only exceptions of identical class
10:20 <@penberg> tgrabiec: well, you know what's on the top of your ToDo list ;)
10:21 <@penberg> Unforutnately I don't have the time to fix more bugs now.
10:21 <@penberg> tgrabiec: but you're more than welcome to do that ;)
10:22 <@penberg> vegard: http://github.com/penberg/jato/commit/36bcd6987548948a260da3f4b119a465323e254e
10:22 <@penberg> vegard: http://github.com/penberg/jato/commit/5ba85f26dd031f201c247f91ae568678a2cb3b96
10:22 <@penberg> tgrabiec: feel free to send a version of your patch that makes main() fail if exception occured
10:22 <@penberg> that also disables the broken regression tests
10:22 <@penberg> see my second patch for details how to do that ;)
10:28 <@penberg> tgrabiec: http://github.com/penberg/jato/commit/1ce2b33f5ff6b73fd0005ca0015c17d558f427cf
10:28 <@penberg> I don't know why no one sent me a patch to do that
10:28 <@penberg> so I did it myself
10:28 <@penberg> hopefully it works!
10:29 < tgrabiec> oh, i forgot about that ;)
10:33 < tgrabiec> i have to go now, i'll sent the patch this afternoon probably
10:34 <@penberg> ok
10:41 <@penberg> vegard, tgrabiec: so array load/store is broken because arraycheck is broken somehow.
12:01 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has quit [Remote closed the connection]
12:07 <@penberg> vegard: ok, so object->class is NULL.
12:09 <@ahuillet> hi
12:09 <@ahuillet> I have a two line patch that removes lib/ from the Makefile
12:10 <@ahuillet> it seems to still work, though it's probably a side effect of before I guess
12:11 <@penberg> ship it in.
12:11 <@penberg> did you double check you're not running against a compiled lib though?
12:12 <@penberg> vegard: http://github.com/penberg/jato/commit/85d16d96051c2d9a246aa427405c003d13ba9ef8
12:13 <@penberg> vegard: a proper fix is to initialize ->class
12:13 <@ahuillet> penberg : my point exactly
12:13 <@penberg> vegard: but I'll leave all that to you
12:13 <@penberg> right.
12:14 <@penberg> because we need some of the classes
12:14 <@penberg> anyway
12:14 <@penberg> the "proper thing" to do is just nuke lib/ and take the reference implementation from gnu classpath
12:14 <@ahuillet> btw guys, the shitload of perf-*.map files in /tmp
12:14 <@ahuillet> does it come from jato ?
12:14 <@penberg> yes.
12:15 <@penberg> ahuillet: maybe we should add a -Xperf command line option
12:15 <@penberg> and not do perf_map() open unless it's enabled?
12:15 <@ahuillet> sounds good.
12:16 <@penberg> vegard's command line parsing code is f*ugly ;)
12:19 <@penberg> ahuillet: fixed.
12:19 <@penberg> (the perf thing)
12:23 <@penberg> ahuillet: btw, I think PrintTest is broken now.
12:23 <@penberg> ahuillet: probably because some static fields are not initialized.
12:23 <@penberg> ahuillet: because we don't use jamvm anymore to do that.
12:24 <@ahuillet> yeah, tgrabiec told me this
12:24 <@ahuillet> this is hardly my fault though
12:24 <@penberg> yes
12:25 <@penberg> I've been fixing some of the fallout from the cafebabe merge.
12:25 <@penberg> but just saying that we regressed a bit for S.o.println() ;)
12:25 <@ahuillet> penberg : I don't think I can fix it
12:26 <@penberg> maybe
12:26 <@penberg> but we should try to help poor vegard as much as we can
12:26 <@penberg> so he doesn't burn out
12:26 <@penberg> I'll probably grab my laptop with me for the weekend
12:26 <@penberg> and do some debugging to help
12:27 <@ahuillet> I'll be happy to "initialize static fields"
12:27 <@penberg> most of the ones I've fixed work were pretty simple
12:27 <@ahuillet> but I'll have to learn about what a static field is and every other notion built on top of that
12:28 <@penberg> yup
12:28 <@penberg> it's probably better to let vegard fix the issue
12:28 <@penberg> but figuring out the root cause will save some time from him
12:29 <@penberg> ahuillet: ok so System.out is not initialized as I suspected.
12:29 <@penberg> either we don't do it at all
12:29 <@penberg> or compilation of the static initializer fails.
12:30 <@penberg> ahuillet: it's probably possible for you to rewind back to the commit before I merged cafebabe
12:30 <@penberg> if you want to continue working on other aspects of S.o.println()
12:31 <@penberg> although I highly recommend we just deal with the breakage and move on
12:36 <@ahuillet> the other aspect of S.o.println is the implementation of the native methods
12:36 <@ahuillet> but I think I'm gonna need some infrastructure before I can do it
12:36 <@penberg> Yeah.
12:40 <@ahuillet> so I guess I can send a patch that removes lib/ completely, now
12:43 <@penberg> yup
12:43 <@penberg> remember to use git format-patch -M too!
12:43 <@ahuillet> -M ?
12:43 <@penberg> it detects the deletion
12:44 <@penberg> and produces a nice diff
12:44 <@penberg> rather than a monster one
12:44 <@penberg> try it out!
12:44 <@penberg> I will be off-line for an hour or so
13:43 < vegard> I'm back
13:50 < vegard> right, ok
13:50 < vegard> so the class->object thing I fixed
14:02 <@penberg> vegard: did you send a patch=
14:02 < vegard> I sent the wrong one last night
14:02 < vegard> I need to update it a bit
14:02 <@penberg> ahuillet: I think you forgot to -M
14:03 <@penberg> because that's one crazy diff
14:03 <@penberg> oh well, I'll apply it anyway
14:04 < vegard> ah.
14:04 < vegard> I already had that in my remove-jamvm branch
14:04 < vegard> but it doesn't hurt I suppose...
14:06 <@penberg> vegard: well
14:06 <@penberg> I can also not apply the patch
14:06 <@penberg> whichever you prefer?
14:06 < vegard> no, just go ahead
14:06 <@penberg> I'd rather take on big patch to remove anything
14:06 <@penberg> everything
14:06 <@penberg> ok
14:06 <@penberg> applied
14:06 <@penberg> will test before pushing
14:07 <@penberg> ahuillet: i think you need to upgrade your git
14:08 <@ahuillet> done
14:09 <@ahuillet> but yeah, in my previous git version -M did not exist
14:10 <@penberg> right
14:10 <@penberg> i applied it anyway
14:10 <@penberg> thnx
14:10  * ahuillet starts a fight with MESA guys
14:10 <@ahuillet> https://bugs.freedesktop.org/show_bug.cgi?id=21227
14:10 <@ahuillet> I want this backported into 7.4
14:10 <@penberg> nice: "Increasing year-over-year development activity" at ohloh.net ;)
14:10 <@ahuillet> hahaha :)
14:11 <@penberg> ahuillet: the fun part
14:11 <@penberg> it used to say "decreasing ..."
14:11 <@ahuillet> I don't like this kind of tools
14:11 <@penberg> i think it's tgrabiec's fault ;)
14:11 <@penberg> ahuillet: you don't?
14:11 <@ahuillet> it's funny, but not very accurate nor good for motivation
14:12 <@penberg> what do you mean?
14:12 <@penberg> I am ranked 3000th out of 300,000 :-)
14:12 <@ahuillet> well, if you're a developer and see "decreasing activity"
14:12 <@penberg> heh heh
14:12 <@ahuillet> it's not gonna have a positive impact on your motivation to work on this project
14:14 <@ahuillet> then again jato has the best motivation factor ever
14:14 <@ahuillet> GSoC
14:14 <@penberg> oh
14:14 <@penberg> I thought it was the opportunity to work with me
14:14 <@penberg> :)
14:15 <@ahuillet> seriously, I appreciate it a lot
14:15 <@ahuillet> I would not be here otherwise :)
14:15 < vegard> penberg: two patches sent
14:16 <@ahuillet> vegard : anything I can do to help you out?
14:16 <@ahuillet> vegard : if you can get me started on the native method thing, with maybe a .c skeleton or what
14:16 <@ahuillet> maybe I can start implementing theùm
14:16 <@ahuillet> *them
14:16 <@ahuillet> it seems easier than static field initialization
14:16 < vegard> static field initialization? we don't have that?
14:17 <@ahuillet> (I'm saying that just because of the name... "so what are you doing this summer ?" "static field initialization")
14:17 < vegard> haha
14:17 <@ahuillet> vegard : penberg suspects that System.out is not properly initialized
14:17 <@ahuillet> and this would explain the PrintTest breakage
14:17 < vegard> ah right, so PrintTest is borked?
14:18 <@ahuillet> NullPointerException
14:18 < vegard> oh. not on here
14:18 <@ahuillet> it used to work before cafebabe integration
14:18 <@ahuillet> vegard : it's not easy to spot apparently
14:18 <@penberg> vegard: hmm, I can try git revert
14:18 <@penberg> but if it doesn't work, pls send a patch
14:18 < vegard> I just sent two patches to pekka, maybe those fixed it?
14:19 <@penberg> vegard: ok your patches are applied and pushed now
14:19 <@penberg> will try the revert
14:19 < vegard> I tried the revert here and it was fine (all regression tests passed)
14:20 <@penberg> ok revert worked.
14:20 <@penberg> vegard: you need tomek's patch to see the breakage
14:20 <@penberg> "[PATCH] vm: catch and print unhandled exceptions"
14:20 < vegard> ah
14:20 <@penberg> needs bit of manual merging
14:20 < vegard> one sec, let me try it.
14:21 <@penberg> print test still fails
14:22 <@penberg> vegard: i think it's because System.out is not initialized.
14:22 < vegard> really? how come it works here?
14:22 < vegard> what's your version of classpath?
14:22 <@penberg> appyl the patch <-
14:22 < vegard> oh.. hehe
14:22 <@penberg> vegard: ok so your patches fixed the breakage in ObjectCreationAndManipulationTest
14:22 <@penberg> which is good.
14:22 <@penberg> so I did the revert
14:22 <@penberg> I suggest you look at the static field problem next.
14:23 <@penberg> vegard: I'll probably take my laptop with me for the weekend so I'll be able to merge patches and help you out in debugging efforts.
14:23 <@penberg> I think tgrabiec is looking at the ExceptionsTest breakage.
14:23 < vegard> I want to fix PrintTest with arthur
14:23 <@penberg> I fixed a bunch of those so please double-check my other patches
14:23 <@penberg> vegard: yes.
14:23 < vegard> ExecptionsTest is also broken?
14:23 <@penberg> that's the static field problem!
14:23 <@penberg> vegard: yes.
14:23 < vegard> oh
14:24 <@penberg> i think I'll apply tgrabiec's patch actually
14:24 < vegard> haha, I sure am confused.
14:24 < vegard> yeah, I'm applying it by hand now.. takes a bit of time
14:25 <@penberg> vegard: it will be in master soon
14:25 < vegard> oh, ok
14:25 < vegard> I'll just wait then
14:25 <@penberg> I am disabling the tests
14:25 <@penberg> so you have to uncomment them to see the breakage
14:26 <@penberg> just a sec
14:28 < vegard> oh, I forgot to sign off my second patch
14:30 <@penberg> vegard: ok, pushed.
14:31 <@penberg> vegard: so if you grep for FIXME in printtest
14:31 <@penberg> and enable the test again
14:31 <@penberg> you can see the breakage.
14:32 < vegard> ok
14:32 < vegard> thanks.
14:34 <@penberg> vegard: I disabled most of the ExceptionTests too.
14:35 < vegard> ok, so the first thing I'm doing is trying to figure out where the exception was thrown
14:35 <@penberg> hey
14:35 <@penberg> I already did the debugging for you
14:35 <@penberg> 'System.out'
14:35 <@penberg> a static field.
14:35 <@penberg> is null
14:36 < vegard> right
14:36 <@penberg> you can try assertNull(System.out) there
14:36 <@penberg> to see that's really the case
14:36 <@penberg> please don't trust what I say, try it out!
14:36 < vegard> I need to look at the classpath source code :)
14:36 < vegard> hm. we need a -Xtrace:classloader probably
14:36 <@penberg> :)
14:37 <@penberg> yes.
14:38 < vegard> but don't you think we should try to fix init_stack_trace_printing() first?
14:40 <@penberg> no idea.
14:40 <@penberg> but unblocking ahuillet's progress is IMNSHO top priority here
14:40 <@penberg> how we get there is up to you guys.
14:40 <@penberg> vegard: but I think we're in agreement here, no?
14:40 < vegard> yes.
14:40 <@penberg> yup
14:41 <@penberg> cool, have fun ;)
14:41 <@ahuillet> don't worry about my progress today, I've had a few glasses
14:41 < vegard> oh you're leaving now, are you?
14:41 <@penberg> I'll go back refreshing my inbox every 5 minutes :)
14:41 <@penberg> ahuillet: glasses?
14:41 <@penberg> vegard: nope.
14:41 <@penberg> I'm still here.
14:41 <@ahuillet> Chardonnay, white wine... 4 glasses at noon was a bit much.
14:41 <@penberg> aah
14:41 < vegard> heh
14:41 <@penberg> ahuillet: so how do you find rose wine? I think it's called white zinfandel?
14:42 <@ahuillet> rosé ?
14:42 <@penberg> yes.
14:42 <@ahuillet> cold, during a meal, it's nice
14:43 <@penberg> I like it too.
14:43 <@penberg> I even put some ice cubes in it to keep it really cold.
14:43 <@ahuillet> not exactly good wine though, but it's the easiest kind to appreciate
14:43 <@ahuillet> yeah
14:43 <@penberg> that's why I asked.
14:43 <@ahuillet> red wine is much more difficult to appreciate
14:43 <@penberg> but I do like red wine too.
14:43 <@penberg> especially californian red wines ;)
14:43 < vegard> AFAICS, the only method that gets jit-compiled and executed is main()
14:44 <@penberg> vegard: really?
14:44 < vegard> which means that System/PrintStream <clinit> was never even run
14:44 <@penberg> vegard: that's not true.
14:44 <@penberg> -Xtrace:jit shows plenty of functions
14:44 < vegard> it shows only main() here
14:44 <@penberg> ahuillet: for some reason, I really don't like white wine at all.
14:44 <@penberg> vegard: are you talking about PrintTest?
14:45 < vegard> penberg: yes.
14:45 <@penberg> oh ok
14:45 <@penberg> I thought you meant _in general_
14:45 <@penberg> vegard: yes, that's what I concluded too
14:45 <@penberg> without -Xtrace:jit even!
14:45 <@penberg> (yes, I know, it's magic)
14:45 < vegard> so it sounds like we have a classloader_load() that should gets turned into classloader_load_and_init()
14:45 < vegard> ...wait, didn't I debug and fix this last night with tgrabiec?
14:45 <@penberg> ahuillet: http://www.zimbio.com/Wines/articles/1303/Earnest+Julio+Gallo+Family+Vineyards+White
14:45 <@penberg> ahuillet: that's my favorite of the rose wines.
14:46 <@penberg> vegard: I have no idea.
14:46 <@penberg> vegard: AFAICT, I've applied all your patches.
14:48 < vegard> ah, yes
14:48 < vegard> we did!
14:48 < vegard> the classloader_load() in vm_class_resolve_class() should be classloader_load_and_init
14:49 < vegard> ah, but it deadlocks. like tgrabiec said
14:49 <@penberg> did I forget to apply something?
14:49 <@penberg> ahuillet: you will be back in action in no time ;)
14:49 < vegard> nope. it was like after midnight last night and the patch introduces other problems
14:49 <@penberg> ok, cool.
14:50 < vegard> looks like java/lang/System tries to load itself
14:51 < vegard> I can do a temporary hack to make it work
14:51 < vegard> but I really need to look up those load/link/init rules in the jvm
14:51 < vegard> because this could be a chaos otherwise
14:52 <@penberg> vegard: hmm
14:52 <@penberg> vegard: why would it try to load itself?
14:52 < vegard> it's enough that it has a reference to itself
14:53 <@penberg> vegard: but it doesn't
14:53 <@penberg> check the code.
14:53 < vegard> downloading now :)
14:53 <@penberg> or maybe some class it depends on does that?
14:53 <@penberg> there _can_ be cyclic dependencies, you know.
14:53 <@penberg> which you need to handle
14:53 < vegard> yes, I know!
14:53 < vegard> that's exactly what I'm saying :-P
14:54 <@penberg> yes.
14:54 <@penberg> Throwable.
14:54 <@penberg> no not referenced from System
14:54 <@penberg> what _could_ happen there
14:54 <@penberg> is that you get a compliation failure
14:54 <@penberg> (likely)
14:54 <@penberg> and we try to raise an exception
14:54 <@penberg> load Throwable
14:54 <@penberg> trigger loading of System
14:54 <@penberg> -> another exception
14:54 <@penberg> -> deadlock
14:55 <@penberg> I'm pretty convinced Jato is unable to load and initialize java.lang.System
14:55 <@penberg> because we don't support all the necessary bytecodes.
14:56 < vegard> it's the execution of java/lang/System.<clinit>()V that fails
14:56 <@penberg> yes.
14:56 <@penberg> i wonder why we don't see any messages _why_ it failed.
14:57 < vegard> because it deadlocks :-P
14:57 <@penberg> yes but don't we have die() or something in compile() ?
14:57 < vegard> no
14:57 < vegard> it doesn't fail per se
14:57 <@penberg> no I am not following you.
14:57 <@penberg> some NPE perhaps?
14:57 < vegard> NPE?
14:57 <@penberg> NullPointerException
14:57 < vegard> I don't think so
14:57 <@penberg> oh well, I'll stop bothering you
14:58 < vegard> hm. we would need a decompilation of java/lang/System.<clinit>
14:58 < vegard> slash trace
14:58 < vegard> ok. it tries to load java/lang/VMSystem
14:59 < vegard> while compiling java/lang/System.<clinit>
14:59 <@penberg> javap -bootclasspath /usr/share/classpath/glibj.zip -private -c java/lang/System
14:59 <@penberg> hmm
14:59 <@penberg> doesn't work
15:00 <@penberg> oh it doesn't even decompile <clinit> blah.
15:02 <@penberg> oh there it is
15:02 <@penberg> oh but that's probably jdk version of the class.
15:02 < vegard> yeah, I think that happened here too...
15:02 < vegard> because I don't see any references to VMSystem
15:02 <@penberg> yup.
15:03 <@penberg> I think I've done this once
15:03 <@penberg> i had to unzip the jar or something
15:03 < vegard> that's what I did XD
15:03 < vegard> and it didn't work :(
15:04 <@penberg> ok
15:04 <@penberg> mv java xxx
15:04 <@penberg> javap -classpath . -private -c xxx.lang.System|less
15:05 <@penberg> vegard: http://pastebin.com/m46a05d88
15:05 <@penberg> ahuillet: this also means someone needs to implement the native makeStandardInputStream() method.
15:05 < vegard> yeah... but we don't have VMSystem
15:05 <@penberg> yes.
15:05 <@penberg> We need one.
15:05 < vegard> haha
15:05 <@penberg> and we need an implementation of makeStandardInputStream()
15:05 < vegard> yes, of course, Mr. Obvious.
15:06 <@penberg> sorry
15:06 <@penberg> makeStandardOutputStream
15:06 <@ahuillet> bbl
15:06 <@penberg> ahuillet: and that, my friend, would almost certainly be you :)
15:06 <@penberg> vegard: although I think ahuillet needs a hand with the VM stuff
15:07 < vegard> yup
15:07 <@ahuillet> :)
15:08 <@penberg> vegard: but I'd like a version of your patch that doesn't deadloc
15:08 <@penberg> deadlock
15:08 <@penberg> but produces some die("oops") thing
15:08 < vegard> what do you think about vm/java/lang/VMSystem.java ?
15:08 <@penberg> i was thinking of runtime/
15:08 <@penberg> vegard: btw.
15:09 < vegard> aright, same for me :)
15:09 <@penberg> should we _embed_ the runtime jar to the jato executable?
15:09 <@penberg> that is, all the VM* classes?
15:09 < vegard> hm. that would be neat.
15:09 <@penberg> so jato would be a standalone executable.
15:09 < vegard> cafebabe can load in-memory buffers, so it shouldn't be hard to do.
15:09 <@penberg> vegard: that's my suggestion anyway.
15:09 <@penberg> so during make
15:09 < vegard> just compile the classes with javac and convert it to C code
15:10 <@penberg> ?
15:10 < vegard> (as byte arrays)
15:10 <@penberg> well
15:10 <@penberg> cant we just
15:10 <@penberg> cat executable jar >> jato
15:10 <@penberg> ?
15:10 < vegard> eeek, how ugly :)
15:11 <@penberg> vegard: ok
15:11 <@penberg> whatever you think is the best.
15:11 <@penberg> but the point here is that
15:11 <@penberg> we don't need to play with those stupid bootclasspath things.
15:11 < vegard> why not const uint8_t vmsystem_class[] = { 0xca, 0xfe, 0xba, 0xbe, ... } ? :)
15:11 <@penberg> the VM classes are part of Jato and that's that
15:11 < vegard> yup, it's very smart. didn't think of it myself.
15:11 <@penberg> and _if_ we need to support multiple version of classpath (we don't)
15:12 <@penberg> we can always embed multiple versions of the classes
15:12 <@penberg> and make jato do the right thing (tm)
15:12 < vegard> yup
15:13 <@penberg> vegard: http://www.opsb.co.uk/?p=56
15:14 < vegard> heh, nice :)
15:14 < vegard> so... how do you feel about git now, eh? :P
15:15 <@penberg> vegard: whaddya mean?
15:15 < vegard> I think you used to not like it :P
15:15 < vegard> weren't you a fan of quilt?
15:15 <@penberg> oh.
15:15 <@penberg> I see.
15:15 <@penberg> Yes, I used to be.
15:15 <@penberg> Until I discovered git rebase
15:16 <@penberg> I think you told me about it?
15:16 < vegard> can't remember
15:17 <@penberg> anyway, I absolutely love git
15:17 <@penberg> especially as a maintainer for linux & jato.
15:17 <@penberg> and git pull
15:17 <@penberg> aah
15:17 <@penberg> I am addicted.
15:17 < vegard> lol
15:18 <@penberg> I am hoping I'll have sub-maintainers one day ;)
15:19 < vegard> whoa!
15:19 < vegard> I broke the deadlock ;)
15:19 < vegard> and it crashed in java/util/Hashtable.<init> because of missing floating-point ops
15:21 < vegard> http://pastebin.com/m265cec2c
15:22 <@penberg> nice
15:22 <@penberg> vegard: lets put the vm classes under runtime/classpath/java/lang...
15:22 <@penberg> because we might want to do runtime/openjdk one day
15:22 <@ahuillet> <vegard> and it crashed in java/util/Hashtable.<init> because of missing floating-point ops
15:23 <@ahuillet> that we can work out.
15:23 <@ahuillet> once I have working S.o.println :)
15:23 < vegard> ahuillet: hehe. deadlock :P
15:23 <@ahuillet> seriously though, FPU is not trivial, and I'd like to discuss rewriting monoburg prior to tackling it
15:23 <@ahuillet> vegard : seriously, you need FPU and cannot do without it?
15:23 <@penberg> ahuillet: emulate_fdiv()
15:23 <@ahuillet> can't you emulate it?
15:23 <@ahuillet> penberg : yeah my point
15:23 <@ahuillet> penberg : but you're still gonna need e.g. SSE register allocation
15:24 <@penberg> vegard, ahuillet: one option is to simply _ignore_ those bytecodes.
15:24 <@penberg> generate nothing for those.
15:24 <@ahuillet> which ones?
15:24 <@penberg> fpu
15:24 <@penberg> with a little bit of luck
15:24 <@penberg> jato will be able to initialize the interesting parts
15:24 <@penberg> for S.o.println()
15:25 <@penberg> ahuillet: I don't mind monoburg rewrite
15:25 <@penberg> as long as feature creep doesn't kick in.
15:25 < vegard> if you check out the stack trce for my latest run... it crashes in monoburg :)
15:26 <@penberg> #
15:26 <@penberg> jit/load-store-bc.c:108: warning: __convert_ldc not implemented
15:26 <@penberg> this is also pretty damned bad.
15:26 < vegard> that's trying to load a "float" constant-pool entry
15:26 <@penberg> aah
15:26 <@penberg> ok
15:26 < vegard> I have actually provided some code for it
15:26 < vegard> but I don't know if it's correct :)
15:26 < vegard> expr = fvalue_expr(J_FLOAT, cp->float_.bytes);
15:27 <@ahuillet> <penberg> jit/load-store-bc.c:108: warning: __convert_ldc not implemented
15:27 <@ahuillet> <penberg> this is also pretty damned bad.
15:27 <@ahuillet> not implemented?!
15:27 <@penberg> ahuillet: for _floats_
15:27 <@ahuillet> ah, oh.
15:27 <@penberg> but I wonder why it crashes in monoburg.
15:27 <@penberg> vegard: -Xtrace:jit?
15:27 < vegard> I had that :)
15:27 < vegard> 2a 10 0b 12 11 b7 00 29 b1
15:27 < vegard> that's the bytecode
15:27 <@penberg> no HIR?
15:28 < vegard> nope
15:28 <@penberg> impossible.
15:28 < vegard> oh
15:28 < vegard> I was using -Xtrace:asm
15:28 <@penberg> yup
15:28 < vegard> http://pastebin.com/m7ef8a3d1
15:28 < vegard> I ammended it ;)
15:29 <@penberg> invoke
15:29 <@penberg> with a float argument.
15:29 <@penberg> EXPR_FVALUE
15:29 <@penberg> add an empty rule for that.
15:29 < vegard> ah. fvalue float 1061158912... that value looks wrong :)
15:29 <@penberg> no
15:29 <@penberg> there's no _EXPR_FVALUE_ pattern in monoburg
15:29 < vegard> sure, but that value is still wrong too :P
15:30 < vegard> wouldn't make it crash though.
15:30 <@penberg>  
15:30 <@penberg> +reg:   EXPR_FVALUE     0
15:30 <@penberg> +{
15:30 <@penberg> +}
15:30 <@penberg> +
15:31 < vegard> seems to be no difference
15:31 < vegard> I added it just in front of EXPR_VALUE
15:31  * ahuillet takes note: 1 glass *max* if you plan to work in the afternoon
15:32 < vegard> ahuillet: do you feel dizzy? :)
15:32 <@ahuillet> yeah, kind of :)
15:32 <@ahuillet> I'm used to getting real drunk, in parties with fellow students it's the standard
15:32 <@ahuillet> but a bit dizzy is both unusual and uncomfortable to me
15:33 <@ahuillet> so, why does a hash table need floating point computations?
15:33 < vegard> load factor
15:34 < vegard> or something like that. it has a threshold for when to expand
15:34 <@ahuillet> can be done in integer as well
15:34 < vegard> sure, but Sun chose to use FP for it :)
15:34 <@ahuillet> multiply by 1000 you've got an integer.
15:34 <@ahuillet> stupid. :)
15:34 <@ahuillet> makes Java harder to port with no benefit
15:35 < vegard> I do think it's sensible from a "high-level API" point of view
15:35 <@ahuillet> how so?
15:35 < vegard> it's a bit less arbitrary to ask for a floating-point value below 1 than to ask for an integer below 1000
15:36 <@ahuillet> struct timeval ?
15:36 <@penberg> vegard: so how much further do you get with my suggested hack?
15:36 < vegard> penberg: no furhter. it crashes in same way
15:36 < vegard> penberg: I can send you the patch I have so far
15:38 <@penberg> vegard: yes please.
15:38 <@penberg> wth
15:38 <@penberg> "Not to be applied yet, but for testing purposes:"
15:38 <@penberg> I can't apply that :)
15:38 < vegard> oh
15:38 < vegard> you want to apply it already?
15:38 <@penberg> yes.
15:38 < vegard> um right
15:38 <@penberg> it's an improvement.
15:39 <@penberg> a _big_ improvement in my book
15:39 <@penberg> i'll wait for a proper patch
15:41 < vegard> um, but it could potentionally break all the regression tests
15:41 < vegard> ok, it only broke two
15:41 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has joined #jato
15:41 < vegard> ObjectCreationAndManipulationTest and PrintTest
15:42 < vegard> tgrabiec: hello :)
15:42 < tgrabiec> hello
15:49 < vegard> penberg: valgrind speaks of an "invalid read" in init_reg_operand()
15:49 < vegard> init_register(&operand->reg, insn, reg->interval);
15:50 < vegard> called from insn-selector_32.c, EXPR_ARG(reg) afaics: select_insn(s, tree, reg_insn(INSN_PUSH_REG, src));
15:52 < vegard> are we missing EXPR_ARG(EXPR_FVALUE) perhaps?
15:53 < vegard> ok, I added that and it got further this time
15:55 <@ahuillet> vegard : don't do that
15:56 <@ahuillet> reg: EXPR_FVALUE
15:56 <@ahuillet> do this
15:56 <@ahuillet> and mmh
15:56 <@ahuillet> state->reg1 = get_var(s->b_parent);
15:56 <@ahuillet> just that in the block
15:56 <@ahuillet> so a reg is actually allocated
15:57 < vegard> ah nice
15:58 < vegard> it got to java/util/Hashtable.<init>(IF)V this time :)
15:58 < vegard> I can give you the HIR for it
15:58 <@ahuillet> question, why does this not work now
15:58 <@ahuillet> and used to work with jamvm?
15:58 < vegard> because jamvm ecxecuted static initializers using the bytecode _interpreter_
15:58 < vegard> while we have to jit-compile everything since we don't have an interpreter
15:58 <@ahuillet> ok
15:59 <@ahuillet> ok, so static initializers need to be compiled now
15:59 <@ahuillet> Hashtable is used by what?
15:59 <@ahuillet> what static initializer are you trying to get to work?
15:59 < vegard> Hashtable used by Properties
16:00 < vegard> this is the chain: System -> VMSystem -> FileDescriptor -> FileChannelImpl -> VMChannel -> System.loadLibrary() -> Runtime -> SystemProperties -> Properties -> Hashtable
16:01 <@penberg> does anyone know if you can run a 32-bit os with kvm on 64-bit host?
16:02 <@penberg> vegard: aah
16:02 <@penberg> so your patch breaks tons of stuff
16:02 <@penberg> I'll wait for fixes to come in.
16:03 < vegard> what do you think, I could try to break out of initialisation
16:03 < vegard> if (!strcmp(class_name, "java/lang/Properties")) return;
16:03 < vegard> as a temporary hack
16:03 < vegard> though it would be very ugly probably.
16:04 < vegard> I'd prefer placeholder monoburg rules
16:05 < vegard> ahuillet: can you help me out a bit (more) with the monoburg rules?
16:05 <@ahuillet> sure
16:05 < vegard> http://pastebin.com/m165df1c
16:05 < vegard> that's the trace.
16:06 -!- ahuillet_ [n=user@239.34.83-79.rev.gaoland.net] has joined #jato
16:06 < vegard> as you see it crashed in mono_burg_rule+19
16:06 < ahuillet_> haha
16:06 < vegard> so how do I figure out what rules are needed?
16:06 < ahuillet_> you're not asking for help with monoburg rules
16:06 < ahuillet_> you're asking for help fighting monoburg ;)
16:06 < vegard> well I thought I remembered you having fought it before
16:07 < ahuillet_> line 3685
16:07 < ahuillet_> *2685
16:07 < ahuillet_> cmpl between local float and fvalue float
16:07 < ahuillet_> that will crash for sure
16:07 < vegard> aha
16:07 <@ahuillet> output("\tprintf(\"op = %%d, left = %%#x, right = %%#x, tree = %%#x, cost1 = %%d cost2 = %%d cost3 = %%d cost4 = %%d cost5 = %%d cost6 = %%d, rule_reg = %%d, rule_stmt = %%d, rule_arg = %%d\\n\", p->op, p->left, p->right, p->tree, p->cost[1], p->cost[2], p->cost[3],p->cost[4],p->cost[5],p->cost[6],p->rule_reg, p->rule_stmt, p->rule_arg);\n");
16:07 <@ahuillet> see this?
16:08 <@ahuillet> you can add this line in monoburg.c
16:08 <@ahuillet> so that it ends up right after the big switch in monoburg_label_priv
16:08 <@ahuillet> then, if you see all costs to 32767
16:08 <@ahuillet> for a given rule
16:08 <@ahuillet> it means monoburg did not find a match for this op number
16:09 <@ahuillet> the op number can be e.g. EXPR_VALUE, OP_ADD, ...
16:10 <@ahuillet> mmh, so you really need FPU support
16:10 < vegard> ok, finally found out where it goes :)
16:10 <@ahuillet> do you believe we can stub it like you're trying to? will it work?
16:10 < vegard> don't know yet.
16:12 < ahuillet_> it sounds courageous to me
16:13 < vegard> ok, this gave lots of new output
16:13 < vegard> http://pastebin.com/m74fb6330
16:14 < vegard> oh
16:14 < vegard> did I put it in the wrong place?
16:14 < vegard> I put it after the first switch
16:17 < ahuillet_> looks good
16:17 <@penberg> vegard: so I did _not_ apply your patch.
16:17 < ahuillet_> there's only one in mono_burg_label_priv
16:18 < vegard> ahuillet: no, there's two... here at least
16:18 < vegard> switch (mono_burg_arity [...
16:18 < vegard> switch (MBTREE_OP(tree...
16:18 < ahuillet_> the second one then.
16:19 < vegard> http://pastebin.com/m67a0266
16:20 < vegard> ok so I need to find the ones with all-cost 32767, right?
16:20 < ahuillet_> the first one in a series
16:20 < ahuillet_> it's the one that did not match
16:20 < ahuillet_> once you find which it is, tell me, I'll help
16:21 < vegard> op = 44, left = 0, right = 0, tree = 0xa1ef67c, cost1 = 32767 cost2 = 32767 cost3 = 32767 cost4 = 32767 cost5 = 32767 cost6 = 32767, rule_reg = 0, rule_stmt = 0, rule_arg = 0
16:21 < vegard> line 3177 in the pastebin
16:22 < ahuillet_> 44
16:23 < ahuillet_> OP_CMPL
16:23 < vegard> how did you figure that out?
16:24 < ahuillet_> print (int)OP_CMPL in gdb :))
16:24 < ahuillet_> + intuition + habit
16:24 < vegard> aha
16:25 < vegard> it's defined in jit/expression.h ?
16:25 < ahuillet_> so, CMPL is not implemented at all
16:25 < ahuillet_> let me check what it does
16:25 < ahuillet_> vegard : yup
16:27 < tgrabiec> vegard: can you pls take a look at my latest patch: [PATCH] vm: set ->class field when creating array with vm_object_alloc_array() ?
16:29 < ahuillet_> vegard : so you need to add a reg: OP_CMPL(reg, reg)
16:29 < ahuillet_> that does state->reg1 = state->left->reg1
16:33 < vegard> should it have a number after it?
16:33 < vegard> in the rule?
16:33 < vegard> reg:    OP_CMP(reg, reg) 1
16:33 < ahuillet_> oh yes
16:33 < ahuillet_> 1
16:33 < vegard> what's that?
16:33 < ahuillet_> it's just a real stupid dummy anyway :)
16:33 < ahuillet_> it's the cost of the rule
16:33 < vegard> ah
16:34 < vegard> jato: arch/x86/insn-selector_32.c:1811: mono_burg_emit: Assertion `!"conversion not implemented"' failed.
16:35 < ahuillet_> now that's easy
16:35 < ahuillet_> did penberg drop the printf there or what?
16:35 < ahuillet_>         printf("%d to %d\n", src->vm_type, expr->vm_type);
16:35 < ahuillet_> tell me the values
16:36 < vegard> 4 to 7
16:37 < vegard> it was there :)
16:37 < ahuillet_> int -> float conversion.
16:37 < vegard> sorry, I didn't realize it was there and you needed it.
16:37 < ahuillet_> let's have more fun
16:37 < ahuillet_> seriously man
16:37 < ahuillet_> this is leading us nowhere
16:37 < ahuillet_> I'm just feeding random values everywhere
16:37 < vegard> but we need to do this at some point anyway, right?
16:37 < ahuillet_> } else if (src->vm_type == J_INT && expr->vm_type == J_FLOAT) {
16:37 < ahuillet_>         state->reg1 = get_var(s->b_parent);
16:37 < ahuillet_>  }
16:37 < ahuillet_> try that.
16:37 < ahuillet_> (add that)
16:38 < ahuillet_> vegard : yes, but not by using general purpose registers
16:38 < ahuillet_> and doing actual computations.
16:38 < vegard> yeah.
16:39 < vegard> yay!!!
16:40 < vegard> I added float -> int as well
16:40 < vegard> and it threw a java/lang/UnsatisfiedLinkError!!! :D
16:40 < vegard> throwed ?
16:41 < ahuillet_> threw
16:41 < ahuillet_> so.. mmh, sounds pretty good?
16:41 < ahuillet_> except FPU computations are gonna be reaaal funky
16:41 < ahuillet_> now I'm thinking we could emulate them by doing fixed point computations with integers
16:41 < ahuillet_> as a temporary
16:41 < ahuillet_> *+workaround
16:42 < vegard> I'll dig a bit more, find out why we're getting the UnsatisfiedLinkError (but it's probably the missing VMSystem class)
16:43 < ahuillet_> one of the ones we need for println! :)
16:43 < vegard> ;-)
16:43 < vegard> thanks for the help!!!
16:43 < ahuillet_> if you need more - or working FPU - ask
16:43 < vegard> I couldn't have done this alone. now I'll try to fix the VMSystem and see where that leads us.
16:43 < ahuillet_> as I said, we could do "FPU" with four decimal fixed point
16:44 < vegard> yeah, I will :) though I still think that sounds like more work than it's worth
16:44 < ahuillet_> oh and if you have some simple methods to implement maybe I can help, but keep in mind I really suck at practically anything in java
16:44 < ahuillet_> vegard : the fixed point thing is probably easier than a real FPU implementation
16:45 < ahuillet_> for example, adding floats or integers would be the *exact* same things
16:45 < ahuillet_> so the existing code would work
16:45 < ahuillet_> right out of the box
16:45 < ahuillet_> only the conversion code would need some love
16:45 < vegard> ah right
16:45 < ahuillet_> so that we turn an IEEE754 number into a fixed point four decimal number
16:45 < ahuillet_> now obviously "all" this work would go to the trash once we actually implement floating point numbers
16:45 < ahuillet_> but that's not very easy, so...
16:46 < vegard> hey, given that ldc for floating-point doesn't work yet either
16:46 < ahuillet_> what's the floating point representation format in JVM?
16:46 < ahuillet_> IEEE754 or some custom stuff?
16:46 < vegard> can we just skip the ieee754 conversion entirely
16:46 < ahuillet_> 'cause we'd need to turn that into an integer anyway
16:46 < vegard> oh, nvm it won't work.
16:46 < vegard> yep
16:46 < ahuillet_> but that can be done via FPU code written in C I assume
16:46 < vegard> I don't know about the internal representation.
16:47 < ahuillet_> something like float myfloat = read_float(); int myint = float * 1000;
16:47 < ahuillet_> *myfloat * 1000 sorry
16:47 < vegard> yeah
16:57 < ahuillet_> vegard : so, success ?
17:01 < tgrabiec> vegard: the point is, that when i create an array: Integer [] i = new Integer[2], then in vm_object_alloc_array(), class->name is [Ljava/lang/Integer;, so it is _already_ an array class
17:01 < tgrabiec> isn't it ?
17:02 < tgrabiec> because in convert_anewarray, you call class_to_array_class()
17:03 < tgrabiec> so i think that in vm_object_alloc_array we should check if class->name[0] == '[' ?
17:04 < tgrabiec> or you think that we should change the API so that we pass element class to vm_object_alloc_array ?
17:04 < vegard> tgrabiec: aha
17:04 < vegard> tgrabiec: I understand! I'm sorry
17:04 < vegard> everything is good then
17:05 < tgrabiec> ok :)
17:06 <@penberg> ahuillet_: I'm fine with fixed point for the time being, sure.
17:06 < vegard> in that case, I do think the current API is slightly backwards. but it's probably fine for now
17:06 < ahuillet_> penberg : didn't you apply the lib/ removal patch?
17:07 < vegard> ahuillet_: I had to fix a bit of classloader tracing so that I don't have to do it ad-hoc every time :) and now I'm ready to see where the LinkError is coming from.
17:07 <@penberg> i did
17:07 < ahuillet_> oh, right.
17:07 < ahuillet_> 'cause it conflicts with tgrabiec's "removal of make clean rule for lib/"
17:07 <@penberg> there were rejects with the Makefile changes
17:07 <@penberg> so I skipped those hunks
17:08 <@penberg> yup
17:08 <@penberg> I just dropped them
17:09 < ahuillet_> penberg : yeah, the fixed point.. I believe it can give good results
17:09 <@penberg> well
17:09 <@penberg> mostly to avoid the register allocator issues.
17:10 <@penberg> and allows us to run more programs
17:10 <@penberg> so it's good.
17:10 <@penberg> OTOH, I do wonder if real fpu is that hard.
17:11 < ahuillet_> not that hard, just not as straightforward
17:11 < ahuillet_> the regalloc part is easy
17:11 <@penberg> well
17:11 <@penberg> the thing is
17:11 < ahuillet_> the instruction selection is more annoying because we'd have to inflate the LIR by a factor of two etc.
17:11 < ahuillet_> so it's not difficult but long and big
17:11 <@penberg> oh
17:11 <@penberg> right
17:11 <@penberg> well
17:11 < vegard> tgrabiec: did you do that patch for string2cstr?
17:11 <@penberg> you do need that with fixed point too, right?
17:12 <@penberg> because you basically need all the same rules in place, don't you?
17:12 < tgrabiec> vegard: i actually did, but i put it away for the moment, because i need to tackle some things first
17:12 < ahuillet_> penberg : no, with fixed point, it's gonna work as is
17:12 < tgrabiec> vegard: do you need it now ?
17:12 < ahuillet_> see how OP_ADD does not check for J_INT
17:12 <@penberg> ahuillet_: what do you mean?
17:13 <@penberg> you need float -> int conversions
17:13 < ahuillet_> yes
17:13 < ahuillet_> but only the conversion thing
17:13 < ahuillet_> the rest simply goes through "normal" integer operations
17:13 < vegard> tgrabiec: I want the exception's message to get printed :) but I just copy & pasted now, it's just for debugging yet.
17:13 < ahuillet_> aaaah wait... JVM ISA uses special names for float operations
17:13 <@penberg> ahuillet_: aha, ok, it's been a long time since I did fixed point
17:13 < ahuillet_> ok, it's not that easy then
17:13 < ahuillet_> OP_FADD = bad
17:13 <@penberg> ahuillet_: how come?
17:13 < ahuillet_> 'cause it's not OP_ADD
17:14 <@penberg> you can always OP_FADD = OP_ADD
17:14 <@penberg> for your patch
17:14 < ahuillet_> sure, but it's less future proof somehow
17:14 <@penberg> how?-)
17:14 < tgrabiec> vegard: yes, i had message printing code yesterday but i didn't send it because i want to make it right, that is Throwable.toString()
17:14 <@penberg> if the point is to abuse the integer alu rules for floating point
17:14 <@penberg> I'd kinda expect you do that.
17:14 < ahuillet_> penberg : I mean it's kind of dirty because we'll have to undo some of the changes when we do proper fixed point
17:14 < ahuillet_> *floating point
17:15 < ahuillet_> anyway we'll see if we actually need it or not
17:15 <@penberg> ahuillet_: so implement floating point! :)
17:15 < ahuillet_> once S.o.println I'll be happy to do actual floating point
17:15 < tgrabiec> vegard: if you're tempted, you can write string2cstr :)
17:15 < ahuillet_> before, not so much
17:15 <@penberg> well
17:15 <@penberg> I already said we probably can just _ignore_ the bytecodes.
17:15 <@penberg> just generate empty monoburg rules with NOT_IMPLEMENTED or something
17:15 < vegard> yup, I did that :)
17:15 <@penberg> ok, well, for EXPR_ARG you need to push some dummy value
17:16 <@penberg> otherwise function calls will be messed up
17:16 <@penberg> vegard: oh?
17:16 < vegard> (sorry: ahuillet told me what to put, and I have the patch that has dummies and NOT_IMPLEMENTED :))
17:16 <@penberg> doesn't work?
17:17 < vegard> yesh, it did :)
17:17 < vegard> I'm getting UnsatisfiedLinkError exception now
17:17 <@penberg> -ENOPATCH.
17:17 < vegard> probably because it tries to load java.lang.VMSystem
17:17 <@penberg> vegard: ok, so you're working on a patch series?
17:17 < vegard> yes
17:17 <@penberg> ok, that's fine.
17:17 < vegard> I sent you part of it already :)
17:17 <@penberg> classloader tracing?
17:17 < vegard> yup
17:17 <@penberg> merged already
17:17 < vegard> :D
17:18 < tgrabiec> penberg: vegard finally acknowledged "[PATCH] vm: set ->class field when creating array with vm_object_alloc_array()"
17:18 <@penberg> so I should merge that too?
17:18 < vegard> yes!
17:19 <@penberg> "I don't think this is right."
17:19 <@penberg> is the last email from you
17:19 <@penberg> oh well
17:19 <@penberg> I'll just merge it
17:19 < vegard> yes, um, we sorted it out on irc :)
17:19 < vegard> I was wrong. I had my assumptions wrong.
17:19 <@penberg> yes, the patch looked sane to me.
17:19 <@penberg> but if you start something on the mailing list
17:19 <@penberg> and resove it on the irc (which is fine)
17:19 < vegard> I thought we'd get the array _element_ class instead of the array class itself to that function
17:19 <@penberg> you absolutely must notify me on the list as well
17:20 <@penberg> otherwise I'll drop the patch
17:20 < vegard> ah, sorry
17:20 <@penberg> that's ok
17:20 <@penberg> just saying
17:20 <@penberg> you can always resend
17:20 <@penberg> I read every email
17:20 <@penberg> but not every line on IRC.
17:20 < vegard> oh really?
17:20 <@penberg> yup
17:21 < vegard> :-o
17:21 <@penberg> was that sacrasm?
17:21 < vegard> yes ;)
17:21 <@penberg> sarcasm
17:21 <@penberg> well
17:21 <@penberg> as you know
17:21 <@penberg> I don't have a sense of humor.
17:21 <@penberg> so only serious stuff on this channel, pls.
17:21 <@penberg> ;)
17:22 <@penberg> tgrabiec: ok, applied
17:24 <@penberg> vegard: so ... README doesn't have my addition?
17:24 <@penberg> libzip-dev or something
17:25 <@penberg> oh well I merged it myself
17:26 <@penberg> and btw slash2dots, I really hate that kind of naming conventions :)
17:26 <@penberg> what's wrong with slash_to_dots()?
17:29 < vegard> penberg: aha, sorry. I forgot about that one.
17:29 < vegard> penberg: yes, I was about to ack it :)
17:29 < vegard> penberg: there are more READMe changes needed as well
17:30 <@penberg> ok
17:30 <@penberg> I just don't want to lose patches
17:30 <@penberg> which is why I merged it myself
17:30 < vegard> you can always resend
17:32 <@penberg> hmm
17:32 <@penberg> too much bug fixing for you today.
17:32 <@penberg> judging from the amount of humor pouring out of you
17:33 <@penberg> vegard: here you go: http://rob-bell.net/2009/06/a-beginners-guide-to-big-o-notation/
17:35 < vegard> hey, I know Big-oh
17:35 <@penberg> vegard: Oh!
17:35 <@penberg> that's one crappy article
17:36 < vegard> hhuh?
17:36 < vegard> I'm confused.
17:36 < vegard> why did you show me that article?
17:37 < vegard> about the humour, I need to make up for all the crying I did in church today.
17:37 <@penberg> so that you could learn about big oh
17:38 <@penberg> vegard: oh
17:38 < vegard> did I make a mistake in the classloader or something that makes you think I need to learn big-o?
17:38 <@penberg> it was sarcasm right back at you vegard.
17:39 <@penberg> yes, I am tired.
17:39 < vegard> :-P
17:39  * ahuillet_ watches the conversation, puzzled
17:39 < vegard> gotcha!!!
17:39 <@penberg> but I found it funny. and that's what matters.
17:39 < ahuillet_> I lost track of who was doing humor and who picked on whom.
17:40 < tgrabiec> vegard: we still don't have the obj->class->object == NULL problem fixed, do we?
17:40 <@penberg> ahuillet_: :)
17:40 < vegard> tgrabiec: no, but I am working on it now
17:40 < tgrabiec> vegard: oh, terrific, i'm really looking forward for it :)
17:41 < vegard> tgrabiec: but one thing leads to another and I had to fix a few different things on the way
17:41 < tgrabiec> happens
17:53 < vegard> vm_print_exception: java/lang/UnsatisfiedLinkError: classloader: java/lang/Throwable
17:53 < vegard> hah, writing java code in C is so tiresome :)
17:54 <@penberg> I'm off
17:54 <@penberg> I'll probably be offline later this evening
17:54 <@penberg> I have my laptop with me
17:54 <@penberg> armed and ready to merge patchs
17:54 <@penberg> ;)
17:54 <@penberg> later!
17:54 -!- penberg [n=penberg@xdsl-83-150-86-196.nebulazone.fi] has quit ["leaving"]
17:54 < ahuillet_> I'll likely be off to the restaurant
17:55 < vegard> more wine? :D
17:55 < ahuillet_> no, too expensive in restaurants
17:55 < ahuillet_> and I've had my dose for today :)
17:59 < tgrabiec> vegard: please review  "[PATCH] vm: implement vm_object_get_array_element_class()" :)
18:00 < vegard> hm.
18:00 < vegard> I don't think it works.
18:00 < vegard> don't you need to remove L and ; as well?
18:16 -!- ahuillet_ [n=user@239.34.83-79.rev.gaoland.net] has quit ["Leaving"]
18:17 < tgrabiec> vegard: you're right
18:22 <@ahuillet> vegard : so, println ! working ? :)
18:22 < vegard> ahuillet: not yet :)
18:22 < vegard> I'm implementing the missing VM* classes now
18:31 < vegard> ok
18:31 < vegard> we're back to monoburg breaking :)
18:32 <@ahuillet> good
18:32 <@ahuillet> show me the traces
18:36 < vegard> op = 32, left = 0x86e6818, right = 0x86e68a8, tree = 0x86e6514, cost1 = 32767 cost2 = 32767 cost3 = 32767 cost4 = 32767 cost5 = 32767 cost6 = 32767, rule_reg = 0, rule_stmt = 0, rule_arg = 0
18:36 <@ahuillet> op 32..
18:37 <@ahuillet> OP_REM
18:37 <@ahuillet> do you have the trace output?
18:37 <@ahuillet> (HIR)
18:38 < vegard> http://pastebin.com/m79412ea9
18:38 <@ahuillet> erm
18:38 <@ahuillet> no HIR trace here
18:39 < vegard> oh sorry
18:40 <@ahuillet> bbl calling girlfriend
18:40 <@ahuillet> train tickets to buy...
18:51 < vegard> http://pastebin.com/m7f01b052
18:52 < vegard> blaaah
18:53 < vegard> http://www.nopaste.com/p/alT2TM8LJ
18:55 < vegard> binary_operator: [rem]
18:55 < vegard> binary_left: INVOKEVIRTUAL
18:55 < vegard> binary_right: ARRAYLENGTH
18:56 <@ahuillet> ok, we need OP_REM(reg, reg)
18:57 <@ahuillet> that's gonna be a real patch that I do as soon as I get my gf to understand that I'm not calling here to chitchat
18:57 < vegard> ehe
18:57 < vegard> hey, take your time
18:57 < vegard> girlfriend should have priority over this :)
19:00 <@ahuillet> gf done, now train tickets
19:00 <@ahuillet> then OP_REM
--- Log closed Fri Jun 26 19:07:35 2009
--- Log opened Fri Jun 26 19:07:46 2009
19:07 -!- jato-irc-logger [n=vegard@cm-84.209.125.101.getinternet.no] has joined #jato
19:07 -!- Irssi: #jato: Total of 4 nicks [1 ops, 0 halfops, 0 voices, 3 normal]
19:07 -!- Irssi: Join to #jato was synced in 5 secs
19:27 <@ahuillet> tickets done
19:38 <@ahuillet> vegard : ping
19:38 < vegard> pong
19:38 <@ahuillet> patch incoming
19:38 <@ahuillet> for OP_REM
19:38 < vegard> :D
19:38 < vegard> this is coming from Hashtable.put() btw
19:38 <@ahuillet> untested but it should work. :)
19:38 <@ahuillet> oh, yeah, pretty logical
19:39 < vegard> I have a hope that it will succeed
19:39 <@ahuillet> actually the HIR dumps seriously feels like number_of_elements() % sizeof(table)
19:39 < vegard>     int hash = key.hashCode() % buckets.length;
19:39 < vegard> that's the code
19:40 <@ahuillet> that's java code? where did you take it from?
19:41 < vegard> java/util/Hashtable.java
19:41 <@ahuillet> whose code is it?
19:41 < vegard> I downloaded GNU classpath source code
19:41 <@ahuillet> oh?
19:41 <@ahuillet> *oh.
19:41 <@ahuillet> ok
19:41 < vegard> it's handy sometimes :)
19:41 <@ahuillet> I'm testing OP_REM now
19:43 -!- penberg_home [n=penberg@cs149038.pp.htv.fi] has joined #jato
19:43 <@ahuillet> mail sent
19:43 <@ahuillet> complain loudly if you haven't got it in three minutes vegard
19:44 < penberg_home> heh heh
19:44 < penberg_home> I have it.
19:44 < penberg_home> but my laptop is still in my backpack
19:44 < vegard> aah, gmail is so slooow
19:44 < penberg_home> if it's the rem patch you're talking about.
19:44 < penberg_home> anyway, i'm going to eat now
19:44 < penberg_home> but will be online
19:44 < vegard> got it
19:45 < vegard> I'm very excited to see if this fixes it :)
19:46 < vegard> SIGSEGV at EIP 080505a7 while accessing memory address 00000000.
19:46 < vegard>  [<080505a7>] fixup_vtable+6 (/home/vegard/jato/arch/x86/emit-code.c:1110)
19:46 < vegard> :(
19:46 < penberg_home> that's tgrabiec's area.
19:47 < vegard> ahh
19:47 < vegard> t's my code that crashs :)
19:47 < tgrabiec> vegard: fixup_vtable is called after a virtual method is compiled (method_is_virtual()) to patch the vtable so that it points to compiled code not trampoline
19:48 < vegard> yeah, I was calling Throwable.getMessage() with C code
19:48 < vegard> maybe not a too good idea considering we're in the exception code
19:49 < vegard> so it throws ArithmeticException
19:49 < vegard> but it throws from the java code, not C code
19:50 < tgrabiec> getMessage() throws AritmeticException ?
19:50 < vegard> uh, no
19:50 < vegard> I removed my code to call getMessage()
19:50 < vegard> and it stops the crash
19:51 <@ahuillet> penberg_home : so you're eating while on IRC?
19:51 < vegard> but we fail the program because of the ArithmeticException that gets thrown
19:51 < penberg_home> ahuillet: yes.
19:51 < penberg_home> I am a multitasker.
19:51 <@ahuillet> don't you live with someone though?
19:52 < penberg_home> yes.
19:52 < penberg_home> with my gf
19:52 < penberg_home> I ate something before the actual dinner
19:52 <@ahuillet> and she lets you do this? :)
19:52 < penberg_home> yes
19:52 <@ahuillet> I always eat in front of the computer... whenever she's not here.
19:52 < penberg_home> :)
19:52 <@ahuillet> and in the morning
19:53 < vegard> what -Xtrace do I need to pass in order to see method calls?
19:53 <@ahuillet> :jit will do
19:53 < tgrabiec> -Xtrace:trampoline
19:53 <@ahuillet> but it might be too verbose
19:53 < penberg_home> ahuillet: well, to be fair, she's cooking atm
19:53 < penberg_home> ahuillet: because she had eaten earlier
19:53 < penberg_home> so I am not committing any huge sin here ;)
19:53 <@ahuillet> :)
19:54 < penberg_home> ahuillet: but don't you have this culture of long dinners in France
19:54 < penberg_home> like they have in Italy or Spain?
19:54 < penberg_home> we really don't here in Finland
19:54 <@ahuillet> yeah, but we don't start eating as late as they do in spain
19:54 < penberg_home> ahuillet: right
19:54 < penberg_home> I guess they do that in Spain because of the heat.
19:55 <@ahuillet> I don't know, but it clearly is in their culture to eat late
19:55 < vegard> thanks. so the last jit_magic_trampoline output I see is from java/io/PrintStream.<clinit>
19:56 <@ahuillet> here most people eat between 19h30 and 20h30, and it lasts 30 to 60mn "normally"
19:56 < vegard> ahuillet: that's pretty late
19:56 <@ahuillet> two hours being most common when seeing friends but I guess this is universal. :)
19:56 <@ahuillet> older people eat around 19h though
19:56 < vegard> ahuillet: my impression is that dinners here are usually around 17-18, though we often eat as late as 20.30
19:57 <@ahuillet> seriously, 5PM, dinner ?!
19:57 < vegard> hm. towards 18 is probably more right.
19:57 <@ahuillet> I see...
19:57 < penberg_home> ahuillet, vegard: I had a Spanish colleague once
19:58 < penberg_home> working here in Finland
19:58 < penberg_home> and he couldn't get his head around the fact that a lot of Finns do eat dinner around 17-18
19:58 < penberg_home> as far as he was concerned, that could have been a late lunch ;)
19:58 <@ahuillet> 17-18 would be a late "goûter" in france
19:59 < penberg_home> vegard: 5 PM sounds about right for people with kids, I think.
19:59 <@ahuillet> though this really depends on people, the older you are the less likely you are to eat between lunch and dinner apparently
19:59 < penberg_home> ahuillet: http://www.francethisway.com/frenchfoodsnack.php ?
20:00 <@ahuillet> 4pm is about right for young children
20:00  * penberg_home welcomes everyone to the official gsoc food channel ;)
20:00 <@ahuillet> then it moves to 5 or even later, basically when you come out of work/school/whatever
20:01 < penberg_home> tgrabiec: you're polish, right?
20:02 < tgrabiec> penberg_home, yes
20:02 < penberg_home> tgrabiec: no we need to know at what time you eat :)
20:02 < penberg_home> s/no/now/
20:03 < penberg_home> tgrabiec: closer to the french 19-20 or the nordic 17-18?
20:03 < tgrabiec> well, usually: 1) when i get up 8-10 2) the middle-day meal at about 2pm 3) supper at 7-8pm
20:03 < tgrabiec> i eat 3-times a day at least :)
20:03 < penberg_home> tgrabiec: and is this regular polish custom?
20:04 < penberg_home> tgrabiec: that is, would you expect other people to eat around that time too?
20:04 < tgrabiec> well, yes, i'd expect, but i'm not an expert
20:04 < penberg_home> :)
20:05 < penberg_home> so that concludes our lecture in eating habits around europe.
20:05 < penberg_home> ;)
20:05 <@ahuillet> :)
20:06 < penberg_home> I'm not sure if I mentioned this before but I am going to Tokyo this year to the kernel summit
20:06 < penberg_home> I wonder how shocked I'm going to be of their food culture :)
20:06 <@ahuillet> plane entirely paid for by... ?
20:06 < penberg_home> ahuillet: Linux Foundation.
20:06 <@ahuillet> hehe.
20:07 < penberg_home> they invited me so they better pay up! ;)
20:07 < vegard> penberg_home: they say itadakimas before meals
20:08 < vegard> *itadakimasu
20:08 < penberg_home> vegard: pronounced as English, Norwegian, or Finnish?-)
20:08 < vegard> (the final u is not pronounced)
20:08 < penberg_home> vegard: what does it mean?
20:08 < vegard> Japanese...
20:09 <@ahuillet> ok, time to head to the restaurant
20:09 < vegard> "I receive" I think. google it, wikipedia knows ;)
20:09 <@ahuillet> I'm not gonna be online
20:09 < vegard> ahuillet: good luck, thanks for the patch
20:15 < tgrabiec> vegard: is it safe to call classloader_load() from vm_class_init() ?
20:17 < tgrabiec> what i'm concerned about is an infinite recursion, is it possible ?
20:22 < vegard> hehe
20:22 < vegard> yes
20:22 < vegard> that's what happened, and it's solved in my tree
20:22 < vegard> unless pekka merged it already
20:22 < vegard> [PATCH] vm: fix classloader deadlock on recursive dependencies
20:22 < vegard> yep, I think he merged it
20:23 < tgrabiec> so, i shouldn't be using classloader_load() from vm_class_init() ?
20:23 < vegard> oh wait
20:23 < vegard> you are talking about  vm_class_init()
20:23 < tgrabiec> yes
20:23 < vegard> you mean for the superclass?
20:23 < tgrabiec> i can show you the patch, wait a moment
20:24 < tgrabiec> vegard: http://pastebin.com/d623cad5d
20:24 < vegard> we already use it for loading the superclass
20:24 < tgrabiec> it's about initializing array_element_class in array classes
20:24 < tgrabiec> what do you tjink about it ?
20:25 < vegard> hm. it definitely could be bad
20:26 < tgrabiec> why is that ?
20:26 < vegard> wait
20:26 < vegard> um, are we ever calling vm_class_init() for array classes..?
20:27 < tgrabiec> hmm, maybe not. when do we call vm_class_init() and why don't we for array classes ?
20:28 < vegard> because that takes a struct cafebabe_class *
20:29 < vegard> it uses the classfile information to create a class
20:29 < vegard> the array classes are synthetic; they're not constructed from a class-file
20:30 < tgrabiec> so where do we set vm_class.object for arrays ?
20:32 < tgrabiec> ah , is see
20:33 < tgrabiec> so what do you say if i make vm_class.array_element_class initialized on demand (initially null) by a call to vm_class_get_array_element_class()
20:33 < tgrabiec> or is it better to put it in classloader_load_and_init() ?
20:39 < vegard> it's possible to load on demand
20:39 < vegard> but then we need to check it always before using
20:39 < vegard> (unless you can fix that with a signal handler, of course ;-))
20:40 < tgrabiec> yes, the latter is better, provided it's safe
20:41 < tgrabiec> hey, signal handler was not my idea ;)
21:01 < tgrabiec> vegard: i think i have the same problem as the one with vm_class.object
21:02 < tgrabiec> vm_class.array_element_class should be initialized probably in the same place that vm_class.object is initialized ?
21:11 < tgrabiec> vegard: i think we should initialize classes arrays (classloader_load_and_init) what do you think ?
21:11 < tgrabiec> *classes which are arrays
21:14 < vegard> initialize?
21:14 < vegard> but they don't have a static initializer
21:14 < vegard> so what's the point?
21:15 < tgrabiec> yes, so we skip clinit, but we have to setup ->object
21:15 < vegard> oh
21:15 < tgrabiec> Integer [] c = new Integer[2]; c.getClass()
21:15 < vegard> true
21:15 < tgrabiec> i did it, and regression seem to pass
21:16 < vegard> oh right
21:16 < vegard> that's including this patch? vm: fix classloader deadlock on recursive dependencies
21:18 < tgrabiec> is it in master ?
21:19 < vegard> I think so
21:19 < vegard> oh
21:19 < vegard> no, it's not
21:19 < vegard> it's on the mailing list, but it broke something else so pekka wanted to wait (iirc)
21:21 < tgrabiec> why would that patch break anything ?
21:22 < vegard> I don't know :)
21:32 < tgrabiec> yes, it breaks things. so are you working on it now ?
21:33 < vegard> yes
21:33 < vegard> not on this patch
21:33 < vegard> but I intend(ed) for that patch to go in
21:34 < tgrabiec> ok, so i guess i should wait for you :)
21:35 < tgrabiec> do you need any help ?
21:36 < vegard> ah, your gsoc project is implementing exceptions
21:36 < vegard> I think you have come pretty far already?
21:37 < vegard> we need to come up with a scheme for class loading that is correct
21:38 < vegard> right now I am trying to debug the ArithmeticException thing
21:38 < vegard> why jvm.PrintTest throws an ArithmeticException I don't know, but it might be related to our (lack of) floating-point handling
21:40 < tgrabiec> i'll take a look at it too
21:40 < vegard> want me to push a branch with my crrent patch queue?
21:41 < vegard> I think we might want to do class loading non-recursively. and do some kind of back-patching to update pointers when a class is loaded. it's just a vague idea for now, but I don't like to see an 80-deep stack trace in gdb.
21:42 < tgrabiec> vegard: yes, you can push
21:45 < vegard> oh, we received SIGFPE
21:45 < vegard> you should be able to do:
21:45 < vegard> $ git remote add vegard git@github.com:vegard/jato.git
21:45 < vegard> $ git fetch vegard
21:45 < vegard> $ git checkout vegard/for-tomek
21:47 < tgrabiec> vegard: Permission denied (publickey).
21:47 < vegard> ah sorry
21:47 < vegard> you need to git rm vegard
21:48 < vegard> and use   git://github.com/vegard/jato.git as the url instead
21:53 < tgrabiec> should `git branch` show * (no branch) ?
21:53 < vegard> yes, that's okay
21:54 < vegard> you can use "git checkout -b <new-branch-name>" if you want an explicit branch in your own repository
22:01 < vegard> I think I know what's wrong.
22:02 < tgrabiec> yes?
22:02 < vegard> the OP_REM patch from ahuillet
22:02 < vegard> I'm not sure it's correct.
22:02 < penberg_home> hmm
22:02 < vegard> it doesn't seem correct to me
22:02 < penberg_home> so
22:02 < penberg_home> I merge ahuillet's patch
22:02 < penberg_home> and then tomek's series?
22:02 < vegard> because it does "idiv %eax"
22:03 < vegard> which is nonsensical (eax / eax)
22:03 < tgrabiec> vegard: but i son't get ArithmeticException thrown from signal handler
22:03 < tgrabiec> *I don't
22:03 < vegard> you don't? for jvm.PrintTest ?
22:03 < tgrabiec> yes
22:03 < tgrabiec> i put printf() in signal handler and no output
22:03 < vegard> hm. what happens then?
22:04 < tgrabiec> i don't know yet
22:04 < penberg_home> hmm
22:05 < vegard> http://faydoc.tripod.com/cpu/idiv.htm
22:05 < vegard> the instruction we're using divides EDX:EAX by the operand
22:06 < vegard> but emit_div_reg_reg() takes two register operands?
22:06 < tgrabiec> vegard: yes, but the second one must always be eax
22:06 < vegard> I think __emi_div_mul_reg_eax has a bug
22:07 < tgrabiec> to indicate that it divides edx:eax (i don't know why)
22:07 < vegard> it should say encode_reg(&dest->base_reg) instead of encode_reg(&src->base_reg)
22:07 < tgrabiec> dest is always eax isn;t it ?
22:07 < vegard> oh
22:07 < vegard> true
22:08 < vegard> ahh
22:08 < vegard> but something is funky there
22:08 < vegard> because it outputs idiv %eax and it shouldn't..!?
22:09 < vegard> ah ok
22:09 < vegard> it's the OP_REM after all
22:09 < vegard> it shouldn't pass eax to DIV_REG_REG
22:09 < vegard> or..?
22:09 < vegard> bleh, I can't read this code :-P
22:14 < tgrabiec> vegard: oh, sorry - it is from sigfpe, i wasn't looking at the first occurance of exception
22:17 < tgrabiec> vegard: i believe it's because java/lang/Object.hashCode() returns 0
22:17 < vegard> that should be fine
22:17 < vegard> 0 / (non-zero) = 0
22:17 < tgrabiec> the assembly looks like it divides eax by the result of java/lang/Object.hashCode()
22:17 < vegard> no?
22:17 < vegard> it looks like it divides %eax by %eax!
22:17 < vegard> which is 0 / 0
22:18 < tgrabiec> oh, yes, apparently i'm blind :)
22:18 < vegard> "idiv %eax" is essentially: eax <- eax / eax, correct?
22:20 < penberg_home> hmm
22:21 < penberg_home> i wonder how two temporaries can get the same value
22:21 < penberg_home> probably an instruction selector bug
22:21 < penberg_home> ahuillet: what do you think?
22:22 < vegard> one of them is fixed
22:22 < vegard> oh, sorry
22:22 < vegard> I thought you meant registers. I should just shut up until you figure it out :)
22:24 < tgrabiec> i know what's wrong :)
22:24 < tgrabiec> rule: reg:    EXPR_ARRAYLENGTH(reg) is broken
22:24 < tgrabiec> it should not put the result in EAX !
22:25 < vegard> so get_var() instead of get_fixed_var() ?
22:25 < tgrabiec> yup
22:26 < vegard> ok, now it gets further
22:26 < vegard> great!
22:26 < vegard> you're good!
22:27 < tgrabiec> :-)
22:28 < vegard> shouldn't we have an assert() somewhere if the same register is used twice?
22:29 < vegard> ok, with that changed to get_var() do you also get a SIGSEGV aka. NullPointerException?
22:29 < tgrabiec> yes
22:29 < vegard> seems to be one of the arguments to the invokevirtual?
22:32 < tgrabiec> i belive that object->class is null, when invoking java/util/Hashtable.get
22:34 < vegard> ah, yes
22:35 < vegard> aha
22:35 < vegard> it's a String
22:37 < vegard> but vm_object_alloc_string() calls vm_object_alloc(vm_java_lang_String) and that should set ->class correctly
22:38 < vegard> I think it's the object reference itself that is NULL
22:38 < vegard> because we fault on trying to _get_ the obj->class
22:41 <@ahuillet> back
22:43 <@ahuillet> I'll look into your bug guys, give me a few minutes
22:44 < vegard> ahuillet: the div/rem thing was solved, sorry for suspecting your code :)
22:44 <@ahuillet> ah, oh
22:44 <@ahuillet> so nothing for me?
22:44 < vegard> don't think so
22:47 < vegard> we have do {} while loops working right? :)
22:51 < penberg_home> ahuillet: nope, no bugs for us, these two are taking care of all of them :(
22:52 < tgrabiec> well I'm done for tonight, I need to dring some wine :)
22:53 < vegard> if you really want...
22:53 < vegard> http://pastebin.com/m2ed11210
22:53 < vegard> that's the current problem
22:54 < vegard> I _think_ that "prop" gets turned into a NULL and prop.get(key) fails
22:54 <@ahuillet> not for me :]
22:55 <@ahuillet> might it be tied to our special implementation of floating point arithmetic? :)
22:55 < vegard> I doubt it
22:55 < penberg_home> why
22:55 < vegard> this looks more like a syntax/code-flow problem to me
22:56 < vegard> of course it could be something vm internal like tgrabiec suspects too
22:56 <@ahuillet> control flow... mmh
22:56 < penberg_home> control flow...
22:56 < vegard> sorry
22:56 <@ahuillet> can you please javac -p your piece of code?
22:56 <@ahuillet> so I see the JVM and can check for bugs in my operand stack code
22:56 < penberg_home> vegard: so does prop.get(key) work as a standalone test?
22:57 < penberg_home> ahuillet: do you mean bytecode?-)
22:57 < vegard> javac: invalid flag: -p
22:57 <@ahuillet> err, JVM code sorry
22:57 <@ahuillet> I've mostly drunk water though.
22:58 < vegard> huh? I posted the .java code?
22:58 < vegard> ah, this
22:58 < vegard> Code: 2a 4d 2c 2b b6 00 b4 c0 00 2d 4e 2d c6 00 05 2d b0 2c b4 00 13 4d 2c c7 ff eb 01 b0
22:58 < penberg_home> hmm
22:59 < penberg_home> well looks like edi is treated as a pointer
22:59 < penberg_home> and the value of it is 0x01
22:59 < penberg_home> and the value comes from 0x14(%ebp)
23:00 < vegard> is it possible that this is because we use a fixed EDI in the OP_REM?
23:00 < penberg_home> which is the object reference, isn't it?
23:00 < vegard> remember that it's in a loop
23:00 < penberg_home> looks like the _parameter_ passed to get() is bogus
23:00 < vegard> so I don't know if it's the first or second or which iteration
23:00 < vegard> oh
23:00 < penberg_home> vegard: eip is 0x929e01e
23:00 <@ahuillet> fixed EDI in OP_REM?
23:00 <@ahuillet> ?!
23:00 < penberg_home> 0x0929e01e:   8b 7f 00                   mov    0x0(%edi),%edi
23:01 < penberg_home> and the value of edi is utterly bogus
23:01 < vegard> ahuillet: the result of divl is in %eax/%edx... isn't it? :-/
23:01 <@ahuillet> eax is the result
23:01 <@ahuillet> edx the remainder
23:01 < penberg_home> vegard: and as far as I can tell, it's coming from 0x14(%ebp)
23:01 <@ahuillet> edi has nothing to do here
23:01 < penberg_home> hmm
23:01 < penberg_home> so where is this rem you guys are talking about?
23:02 < vegard> ahuillet: aha. sorry for suspecting your code again :-(
23:02 < vegard> ahuillet: I must be tired to confuse edi and edx.
23:02 < vegard> penberg_home: afaics, edi is loaded from 0x0(%esp)...
23:02 < penberg_home> well anyway
23:02 < penberg_home> vegard: yes
23:02 < penberg_home> then go further back
23:02 < penberg_home> that's a virtual call, probably.
23:02 < penberg_home> yes.
23:03 < penberg_home> 0x0929e019:   56                         push   %esi
23:03 < penberg_home> 0x0929e016:   8b 75 fc                   mov    -0x4(%ebp),%esi
23:03 < penberg_home> 0x0929e00f:   89 45 fc                   mov    %eax,-0x4(%ebp)
23:03 < penberg_home> 0x0929e00c:   8b 45 14                   mov    0x14(%ebp),%eax
23:03 < penberg_home> vegard: there you go.
23:03 < vegard> :D
23:03 < penberg_home> so the bug is in the _caller_
23:03 < vegard> wow, thanks. I didn't see that push.
23:04 < penberg_home> so can we see the caller?
23:04 < vegard> hm. how do I find out?
23:04 < penberg_home> -Xtrace:jit?
23:04 < penberg_home> the previously dumped method usually
23:05 < penberg_home> just check who is _calling_ that
23:05 < penberg_home> getProperty()
23:05 < penberg_home> somewhere is a invokevirtual getProperty()
23:07 < vegard> problem is, there are a few of them :)
23:07 < vegard> oh wait
23:07 < penberg_home> aah
23:07 < vegard> I have its return address
23:08 < penberg_home> 0x929e05f?
23:08 < penberg_home> jit_magic_trampoline: ret0=0x919700d, ret1=0x929e05f: java/util/Hashtable.get #11
23:08 < penberg_home> right?
23:08 < vegard> yeah...
23:09 < vegard> though I restarted it and got a different address :)
23:09 < penberg_home> sure
23:09 < vegard> whoa, the caller is huuuge
23:09 < penberg_home> maybe I should just go to sleep
23:09 < penberg_home> ;)
23:09 < vegard> it has 407 LIR instructions
23:10 < vegard> TRACE: gnu/classpath/SystemProperties.<clinit>()V
23:10 < vegard> I think I should go to bed too
23:11 < vegard> will try to sort this out tomorrow :-/
23:11 <@ahuillet> ah well, if you are going, I have no more pretext not to watch a move
23:11 <@ahuillet> *movie
23:11 < vegard> though I fear we'll run into more trouble with all these static initializers
23:11 < penberg_home> are you initializing them in correct order btw?
23:12 < vegard> order?
23:12 < vegard> there's an order?
23:12 < vegard> I thought constructors had a bytecode call to their super-constructor always?
23:12 < vegard> maybe <clinit> doesn't?
23:13 < penberg_home> hmm
23:13 < penberg_home> hmmm
23:14 < penberg_home> nobody calls clinit
23:14 < penberg_home> the vm does it.
23:14 < penberg_home> at classloading time
23:14 < penberg_home> but yeah, I suppose the ordering is correct there
23:14 < penberg_home> so you don't need to worry about it
23:14 < penberg_home> but anyway, static fields are always initialized from top to bottom
23:14 < penberg_home> but I guess thats _java language_ thing
23:14 < penberg_home> the jvm just invokes clinit
23:17 < penberg_home> ok it's zzz time for me
23:17 < penberg_home> good night
23:23 < vegard> http://pastebin.com/m10f80d28
23:24 < vegard> if for some reason you can't sleep
23:24 < vegard> it's there
23:24 < vegard> but it's huge
23:24 < vegard> zzz me too
23:28 < penberg_home> vegard: arg_expression: [value reference 0x9aa0fa8]
23:28 < penberg_home> so who initializes that.
23:28 < penberg_home> i don't see anyone do it
23:29 < penberg_home> hmm
23:29 < penberg_home> sorry, that's a _value_
23:30 < penberg_home> it seems like the arguments are in wrong order.....
23:32 -!- ahuillet_ [n=user@79.83.34.239] has joined #jato
23:32 < penberg_home> no actually it's fine
23:35 < penberg_home> no
23:35 < penberg_home> hmm
23:35 < ahuillet_> mmh?
23:35 < penberg_home> http://pastebin.com/m10f80d28
23:36 < penberg_home> aren't the _args_ in wrong order there?
23:36 < penberg_home> no
23:36 < penberg_home> they are correct.
23:36 < penberg_home> because we push them in reverse order on stack
23:39 < ahuillet_> we end up on a sigsegv because we jump at 0x00000000?
23:39 < penberg_home> nope
23:40 < penberg_home> http://pastebin.com/m2ed11210
23:40 < penberg_home> but that's from a different run
23:40 < penberg_home> vegard: would be better to see the whole trace
23:40 < penberg_home> pretty much impossible to debug small snippets like this
23:40 < penberg_home> well now I am off to bed FOR REAL!
23:40  * ahuillet_ is already in bed
--- Log closed Sat Jun 27 00:00:50 2009