--- Log opened Tue May 19 00:00:33 2009
00:47 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has quit [Remote closed the connection]
08:30 -!- penberg_home [n=penberg@cs149038.pp.htv.fi] has joined #jato
08:30 -!- mode/#jato [+o penberg_home] by ChanServ
08:31 -!- penberg_home changed the topic of #jato to: Jato - Google Summer of Code 2009 is on! - http://jatovm.sf.net/ - IRC logs: http://folk.uio.no/vegardno/jato-irc-logs/
08:31 -!- penberg_home [n=penberg@cs149038.pp.htv.fi] has quit [Client Quit]
09:20 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has joined #jato
10:02 <@penberg> tgrabiec: I'm about to merge your patches
10:02 <@penberg> tgrabiec: are you still happy with the latest ones?
10:07 < tgrabiec> penberg: yes, the last one seems ok
10:07 < tgrabiec> at least i don't see a better way
10:10 <@penberg> tgrabiec: ok, I'll go through them in a minute.
10:12 <@penberg> ahuillet: so, are you happy with tgrabiec's changelogs now :)
10:14 <@penberg> tgrabiec:
10:14 <@penberg> +static void emit_pop_memlocal(struct buffer *buf, struct operand *operand)
10:14 <@penberg> +{
10:14 <@penberg> +       unsigned long disp = slot_offset(operand->slot);
10:14 <@penberg> +
10:14 <@penberg> +       __emit_membase_reg(buf, 0x8f, REG_EBP, disp, REG_EAX);
10:14 <@penberg> +}
10:14 <@penberg> tgrabiec: REG_EAX?
10:15 < tgrabiec> penberg: well, the point is that in lpace of a register there should be 0 - a part of instruction opcode
10:16 <@penberg> is this a x86 instruction set limitation?
10:16 <@penberg> if not, you must not hardcode the register there.
10:17 <@penberg> tgrabiec: so exception "spill slot" is just the slot for exception reference, no?
10:17 <@penberg> not a "spill" slot?
10:17 <@penberg> tgrabiec: and will that work with a nested try block within a catch block?
10:18 <@penberg> so something like catch (Exception e) { try { /* ... */ } catch (Exception x) { /*...*/ } }
10:18 < tgrabiec> penberg: yes, it's a place for exception, and it will work, since only one exception handler is active at a time.
10:19 < tgrabiec> if another exception is thrown in a catch block than the second catcher will store the pointer in "exception stack slot" but it's ok because the first handler is done now
10:19 <@penberg> yes, but won't the nested exception handler overwrite the previous exception?
10:19 <@penberg> tgrabiec: aha, but that's not necessarily true!
10:20 < tgrabiec> yes, it will override, but the old value is not needed anymore
10:20 <@penberg> but but
10:20 <@penberg> let me illustrate.
10:21 <@penberg> tgrabiec: http://rafb.net/p/bRYbCd40.html
10:22 <@penberg> I am not completely convinced that will work properly.
10:24 <@penberg> wait a minute
10:24 <@penberg> pop memlocal
10:24 < tgrabiec> penberg: when it is about athrow, the jvm spec. says it discards java stack, so that the java stack at eh entry is cleared. so i believe that every java compiller will not assume that a will be still on stack
10:24 <@penberg> so pop the top of the stack to a memory location
10:24 <@penberg> so... eax?
10:24 <@penberg> how is that used?
10:25 <@penberg> tgrabiec: sure it is.
10:25 <@penberg> let me double-check
10:25 < tgrabiec> penberg: the opcode for pop r/m32 is 8F /0 (0 in place of register)
10:28 <@penberg> tgrabiec: http://rafb.net/p/OK7kHp37.html
10:28 <@penberg> tgrabiec: ok ok, but don't pass REG_EAX there!
10:28 <@penberg> just pass zero.
10:28 <@penberg> it's not _eax_
10:29 <@penberg> but lets talk about this nested thing first.
10:29 <@penberg> I can merge your patch as-is
10:29 <@penberg> but then I _really_ want a fix for the nested case :-)
10:29 <@penberg> tgrabiec: you decide.
10:32 < tgrabiec> penberg: so you think that java stack can be not empty after a try/catch block ?
10:34 <@penberg> tgrabiec: no, but did you look at the example?
10:34 <@penberg> tgrabiec: am I just confused here?
10:34 <@penberg> tgrabiec: because I think you will reuse the _same_ exception slot for both blocks
10:34 <@penberg> and that the second printout will print "B" as opposed to "A"
10:34 < tgrabiec> penberg: oh right, i can see now
10:35 < tgrabiec> penberg: ok, so i think it's better to hold on merging
10:36 < tgrabiec> penberg: no, wait
10:38 < tgrabiec> penberg: confusion came in. so - if java stack is assumed to be destroyed by try/catch, then every compiler will generate astore before that and will save the vale from exception stack slot to a local slot
10:38 < tgrabiec> so the nested example is handled properly
10:39 < tgrabiec> as i can see, every compiler generates astore at exception handler entry
10:40 < tgrabiec> penberg: so i still think that the patch is ok
11:16 <@penberg> tgrabiec: aha
11:20 <@penberg> tgrabiec: ok, I'll merge your patch as-is. we probably want some more exception handling regression tests, thougj
11:20 < tgrabiec> penberg: sure
11:21 <@penberg> tgrabiec: yay!
11:21 <@penberg> my example works now
11:21 <@penberg> thanks
11:21 <@penberg> pushing
11:33 < vegard> Error initialising VM (initialiseMainThread)
11:33 < vegard> any idea what this is?
11:36 <@penberg> vegard: classpath problem.
11:36 <@penberg> you are missing something from the boot classpath
11:36 < vegard> aha.
11:36 <@penberg> vegard: either lib/classes.zip or one of the gnu classpath ones
11:36 < vegard> what exactly is in the boot classpath?
11:37 <@penberg> what do you mean?
11:37 <@penberg> all the necessary stuff to bootstrap the jvm
11:37 <@penberg> like VMThread and so on.
11:37 <@penberg> and I assume parts of GNU Classpath also.
11:37 <@penberg> I am not that familiar with details here.
11:37 <@penberg> did I ever post you a link on how to integrate gnu classpath to a vm?
11:37 < vegard> aha.
11:38 < vegard> it's possible.
11:38 < vegard> so those bootstrap classes we have are a part of Jam VM?
11:38 <@penberg> vegard: yes and no
11:39 <@penberg> vegard: gnu classpath provides example classes.
11:39 <@penberg> and I think JamVM just uses them
11:39 <@penberg> but you are right that lib/ is JamVM stuff
11:39 <@penberg> and we need to replace them.
11:39 <@penberg> it's mostly just wrappers for native code
11:39 <@penberg> that the VM needs to implement.
11:39 < vegard> yep, I see.
11:39 < vegard> they're actually not needed yet.
11:40 <@penberg> vegard: btw, you might want to consider submitting some of the helper functions you have in jato+cafebabe tree
11:40 <@penberg> to reduce conflicts
11:40 <@penberg> like "method_is_ctor" and so on
11:40 <@penberg> vegard: not needed yet, sure.
11:40 <@penberg> but VMThread, for example, is probably something you need quite early on
11:40 <@penberg> vegard: http://www.gnu.org/software/classpath/docs/cp-vmintegration.html
11:42 < vegard> nice, thanks.
11:45 <@penberg> you are welcome
12:07 < vegard> is there missing an abort() in compile_error()?
12:08 <@penberg> vegard: yes
12:08 <@penberg> we should probably use die() there
12:32 < vegard> I realized that I need to write a jar-/zip-file decompressor as well
12:32 < vegard> since that's currently a part of jam vm.
12:42 <@penberg> vegard: true.
12:42 <@penberg> nice :)
13:13 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has quit ["Leaving"]
13:22 < vegard> hm. gdb and valgrind stack traces are not so nice, because they can't follow the jit-compiled code.
13:23 < vegard> is there a way to help that? if only for debugging purposes.
13:54 <@penberg> vegard: dunno
13:55 <@penberg> vegard: afaik, hotspot has some gdb glue to make jit code visible
13:55 <@penberg> i'd imagine it's the same for valgrind
13:55 <@penberg> probably some hooks where you tell gdb and valgrind that we have anon exec pages
13:55 <@penberg> and where they're at
13:57 <@penberg> vegard: I'd love to merge patches to do that (hint, hint) :-)
13:57 < vegard> yes. I looked at dlopen/dlsym api, but found nothing. looked at valgrind hooks, found nothing. :-(
13:59 <@penberg> vegard: http://tirania.org/blog/archive/2007/Jun-29.html
14:01 < vegard> we have to patch _valgrind_? isn't that kind of ugly?
14:01 <@penberg> vegard: yes
14:01 <@penberg> but if valgrind doesn't have the hooks, we can't do it.
14:02 <@penberg> that's from 2007
14:02 <@penberg> one would assume it's been merged
14:03 < vegard> how does dlopen() enter symbols into the symbol table, then?
14:04 < vegard> or is that all done by the kernel? (binfmt_elf?)
14:04 <@penberg> dunno.
14:05 < vegard> well, a hacky solution seems to be: write out an elf imagine with the symbols we want. use dlopen() to open the shared library. delete the file. voila.
14:05 <@penberg> vegard: did you peek into glibc?
14:05 <@penberg> vegard: perhaps we should patch the kernel instead?-)
14:05 < vegard> ...don't want my eyes to fall out ;-)
14:06 <@penberg> hmmhhmmhm
14:08 <@penberg> vegard: http://www.mono-project.com/Debugging#Debugging_with_GDB_in_XDEBUG_mode
14:09 <@penberg> vegard: apparently people write out DWARF debug information
14:09 <@penberg> and load that into gdb
14:09 <@penberg> hmm
14:11 < vegard> hm.
14:11 < vegard> still looks a bit ugly if you ask me.
14:12 <@penberg> yeah
14:12 <@penberg> i want to know what dlopen does.
14:14 <@penberg> vegard: hmmm
14:14 <@penberg> vegard: interesting
14:15 <@penberg> vegard: dlopen() is just open() + mmap() apparently
14:18 < vegard> um. even if you use RTLD_NOW? (whichi s supposed to resolve all the symbols immediately)
14:19 <@penberg> no idea
14:20 <@penberg> vegard: maybe gbd uses ptrace to intercept the dlopen() call?
14:20 < vegard> maybe. it does use ptrace for a lot of things, after all.
14:21 < vegard> wait
14:21 <@penberg> vegard: http://sourceware.org/ml/gdb/2001-08/msg00221.html
14:21 < vegard> dlopen is a library call
14:21 < vegard> how can it use ptrace to intercept that?
14:21 <@penberg> ptrace supports single-stepping, doesn't it?
14:21 <@penberg> but
14:22 <@penberg> I think you can use some preloading tricks to intercept library calls, no?
14:22 < vegard> ah, true
14:22 < vegard> I feel like crying. this is so ugly :-)
14:24 <@penberg> :)
14:28 <@penberg> vegard: I can't believe this either
14:28 <@penberg> vegard: apparently people are dumping symbol information in external files
14:28 <@penberg> vegard: and then just reloading that into gdb.... :(
14:30 <@penberg> vlah
14:30 <@penberg> blah
14:31 <@penberg> we really need some common hooks to tell rest of the world that we have just generated some new code
14:32  * vegard nods
14:33 < vegard> patch glibc to include dlinsert() and dlremove()? patch gdb to intercept dlinsert() and dlremove()? patch valgrind to do the same? :)
14:37 <@penberg> vegard: I wonder how valgrind does it
14:37 <@penberg> grep -r dlopen doesn't really reveal anything useful
14:38 < vegard> probably it just calls dlsym?
14:40 <@penberg> vegard: but doesn't it need to intercept dlopen too?
14:40 < vegard> uhm
14:41 < vegard> remember that valgrind is an emulator
14:41 <@penberg> yes
14:41 <@penberg> but it does not _have_ all the necessary symbol information prior to dlopen()
14:41 <@penberg> so it must detect the situation anyway!
14:43 < vegard> my guess is that it wouldn't need to call dlopen() itself -- because it's already called in the emulated program. and then it could just call dlsym() in the context of the emulated program, to get addresses. erm, I have no idea, really :-p
14:44 <@penberg> vegard: have you ever looked at valgrind code, btw
14:44 <@penberg> it's shit
14:44 <@penberg> :)
14:45 <@penberg> vegard: so it intercepts mmap() apparently
14:46 <@penberg> vegard: check out di_notify_mmap() in coregrind/m_debuginfo/debuginfo.c
14:47 < vegard> I have, yeah. when I was trying to figure out its opcode decoder. I still have nightmares about it.
14:47 <@penberg> vegard: so if you mmap() an elf object file, valgrind will pick it up automatically.
14:47 <@penberg> AFAICT
14:48 <@penberg> can you get a file descriptor to an anonymous memory region?
14:48 < vegard> heh
14:48 <@penberg> wot!
14:48 <@penberg> allocate anonymous memory
14:48 <@penberg> get a fd on it
14:48 <@penberg> mmap
14:48 <@penberg> -> profit
14:48 < vegard> you don't need an fd to call mmap
14:48 < vegard> there's MAP_ANONYMOUS
14:49 <@penberg> rite.
14:49 <@penberg> :-)
14:49 <@penberg> remember, _I_ am the mentor here.
14:49 <@penberg> don't you ever forget it!
14:49 <@penberg> ;)
14:49 <@penberg> so
14:49 < vegard> but looking at the valgrind code, it looks like it NEEDS a file
14:49 <@penberg> vegard: oh but
14:49 <@penberg> yes
14:49 <@penberg> I was getting there.
14:49 < vegard> /* If the file doesn't have a name, we're hosed.  Give up. */
14:49 < vegard> we could just write one in /tmp, of course
14:50 <@penberg> vegard: yup, makes sense.
14:54 <@penberg> vegard: shm_open()
14:54 < vegard> why does insn-selector_32.c recompile every time I run make?
14:54 <@penberg> vegard: because it's regenerated every time.
14:54 <@penberg> vegard: because of FORCE in Makefile.
14:55 <@penberg> vegard: shm_open() + mmap() = yes?
14:55 < vegard> why is it regenerated every time?
14:55 <@penberg> vegard: I don't remember.
14:55 <@penberg> vegard: probably because of some dependency bug?
14:55 <@penberg> vegard: back in 2005?
14:55 < vegard> oh.
14:56 <@penberg> vegard: so what do you say about shm_open() + mmap() ?
14:57 < vegard> I don't know if that works.
14:57 <@penberg> vegard: why?
14:57 < vegard> besides, can libbfd() (I assume we need that to write out the debug info) use that?
14:58 <@penberg> what do you mean
14:58 <@penberg> shm_open() returns a file descriptor.
14:58 <@penberg> I expect that we can write() to it
14:58 <@penberg> it's backed up by tmpfs in linux
14:58 < vegard> well, because valgrind says "I want a filename".
14:58 <@penberg> you give it a filename!
14:58 < vegard> oh.
14:58 <@penberg> it's a real file
14:58 <@penberg> in ram
14:58 < vegard> ok, cool.
14:58 <@penberg> backed by swap
14:59 < vegard> but it's not a real file, right?
14:59 <@penberg> what do you mean?
14:59 < vegard> valgrind is going to do open() on that filename
14:59 <@penberg> it's a tmpfs file
14:59 <@penberg> and it should work, no?
14:59 <@penberg> ok
14:59 <@penberg> I'm going to try it out
14:59 <@penberg> the shm_open() + open() thing
14:59 < vegard> I thought shm namespace and fs namespace were disjunct?
15:00 <@penberg> hmm
15:00 <@penberg> lets see
15:00 < vegard> ok :D
15:01 <@penberg> you are probably right
15:01 <@penberg> :(
15:04 <@penberg> vegard: so how did valgrind look up the file name?
15:08 <@penberg> vegard: it's a file in /dev/shm/<name>
15:21 < vegard> VG_(am_get_filename)
15:22 < vegard> er, no idea, actually. probably remembered by looking at the open() argument and return value?
15:26 <@penberg> vegard: readlink() from /proc/fd
15:26 <@penberg> vegard: so
15:27 <@penberg> shm_open() + mmap() works nicely
15:27 <@penberg> now I am trying to figure out how to trick valgrind into reading symbols
15:27 <@penberg> vegard: http://rafb.net/p/tS9y1A32.html
15:29 < vegard> yes? :D
15:30 <@penberg> that's what I am working on
15:30 < vegard> but does it run without error?
15:32 <@penberg> yes but valgrind doesn't seem to be trying to read anything
15:33 < vegard> did you insert debug printfs into valgrind source?
15:34 <@penberg> no no
15:35 < vegard> then how do you know? :D
15:35 <@penberg> hmm hmm hmm
15:35 <@penberg> looking at strace output
15:35 <@penberg> I don't see valgrind trying to read the file.
15:36 < vegard> aha.
15:47 <@penberg> vegard: so
15:47 <@penberg> using gdb
15:48 <@penberg> I can see that valgrind does di_notify_mmap() + am_get_filename()
15:51 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has joined #jato
15:53 < vegard> but is that for your file (descriptor), or is it for the libraries that your program uses?
15:53 < vegard> any program does a dozen or so mmap() calls
15:55 <@penberg> it doesn't do it because there's no ELF header :-)
15:55 <@penberg> (I am reading valgrind sources.)
15:55 <@penberg> (just found the correct version)
15:55 <@penberg> ok
15:55 <@penberg> elf header
15:55 <@penberg> hmm
15:55 <@penberg> where can I find it
15:57 < vegard> make your program read() from ./a.out, write() that to the shm fd, _then_ mmap the file?
15:57 <@penberg> sure
15:57 <@penberg> but I want to generate mine
15:57 <@penberg> we need to do it anyway
15:59 <@penberg> here we go
16:00 < vegard> libbfd can do it, I think.
16:03 < vegard> it should, technically speaking, be possible to convert the line-number information we have from the class files, and translate it into dwarf format
16:03 < vegard> convert and translate. hah. pick one ;)
17:22 <@penberg> vegard: ok i didnt have time to try it
17:22 <@penberg> but anyway
17:22 <@penberg> might work
17:22 <@penberg> ahuillet: "[PATCH] x86: code cleanups in emit-code_32.c"
17:22 <@penberg> ahuillet: pls have a look
17:27 <@penberg> vegard: http://rafb.net/p/7yW4UK78.html
17:27 <@penberg> vegard: does not work because there's no ELF data.
17:31 < vegard> hm?
18:37 < vegard> ahuillet: hi. I have a question about method_real_argument_count()!
18:37 <@ahuillet> hi
18:37 <@ahuillet> yes?
18:38 < vegard> ok. so for a method with signature (JJ) the method's ->args_count = 2
18:38 <@ahuillet> yes
18:38 <@ahuillet> that's the number of arguments of the method. :)
18:38 < vegard> real_argument_count() returns 0
18:38 <@ahuillet> that's not true
18:38 <@ahuillet> and/or a bug
18:38 <@ahuillet> mmh wait, ->args_count is supposed to be 4
18:38 < vegard> well, it sees two Js, so it subtracts 2
18:38 < vegard> ok!
18:38 < vegard> please explain why :-D
18:39 <@ahuillet> because that's how it is
18:39 <@ahuillet> you're on x86-64 right?
18:39 < vegard> no, 32-bit.
18:39 <@ahuillet> how do you reproduce?
18:39 < vegard> I'm trying to get rid of Jam VM :)
18:39 < vegard> so right now, my code is initialising ->args_count
18:40 < vegard> but I must be doing it wrong, so I wonder why it should be 4 :)
18:40 <@ahuillet> oh, ok.
18:40 <@ahuillet> well, ->args_count is the number of 32bit arguments
18:40 <@ahuillet> don't ask why
18:41 < vegard> right. yes, I see now, the jamvm code also does += 2
18:41 <@ahuillet> I believe JVM works with 32 bit arguments
18:41 <@ahuillet> as in, a 64bit argument occupies two "slots" or whatever they are called
18:41  * vegard nods
18:42 < vegard> alright, thanks!
18:42 <@ahuillet> I wasn't sure what you were asking at first :)
18:44 < vegard> I just saw that you'd written the real_argument_count() function
18:45 < vegard> so I thought you must know something about this
18:51 <@penberg> :-)
18:51 <@penberg> when in doubt, ask ahuillet.
18:52 <@penberg> that's what I do!
18:53 <@ahuillet> <penberg> ahuillet: "[PATCH] x86: code cleanups in emit-code_32.c"
18:53 <@ahuillet> what's the point of it?
18:53 <@ahuillet> -	__emit_membase_reg(buf, 0xff, src_reg, disp, REG_ESI);
18:53 <@ahuillet> +	__emit_membase(buf, 0xff, src_reg, disp, 6);
18:53 <@ahuillet> the only actual change it does is replace a symbolic name by a cryptic constant
18:53 <@ahuillet> I can't say I agree
19:01 < tgrabiec> ahuillet: the point is, that in PUSH r/m32 in the 'reg' field of mmregmod byte there is extended opcode 6, it's not really accessing ESI
19:02 <@ahuillet> spare me opening the docs, what's it for then?
19:02 <@ahuillet> you sure can push %esi, so.. ?
19:03 <@ahuillet> ah right ok it's kind of a bug in the existing code
19:03 <@ahuillet> sorry
19:03 < tgrabiec> ahuillet: but mmmodreg codes both soirce and destination, but in push there is no source part
19:03 <@ahuillet> we're using a register while it's an opcode we need
19:03 < tgrabiec> ahuillet: yeah, that;s the point
19:04 <@ahuillet> ok, if it makes you feel better it's fine by me
19:04 < tgrabiec> ahuillet: penberg pointed that out yesterday, so..
19:04 <@ahuillet> alright, alright :) I just had not properly read the patch
19:04 <@ahuillet> it's fine, it's just not tremendously useful
19:05 < tgrabiec> ahuillet: right :)
20:00 -!- Netsplit calvino.freenode.net <-> irc.freenode.net quits: @penberg
20:00 -!- penberg_ [n=penberg@xdsl-83-150-86-196.nebulazone.fi] has joined #jato
20:35 < penberg_> ahuillet: cleanups are always useful!
20:36 <@ahuillet> talking of which, I'm cleaning up the apartment a bit
20:36 <@ahuillet> (instead of working for tomorrow's exam)
21:21 < vegard> um.
21:22 < vegard> I am scratching my head over a null dereference
21:22 < vegard> it seems to be emitted by INVOKEVIRTUAL
21:26 < tgrabiec> vegard: maybe uninitialized entry in classblock->vtable.native_ptr[cu->method->method_table_index] ?
21:28 < vegard> hm, ah
21:28 < vegard> I am not calling vtable_init() anywhere :)
21:35 < vegard> but I don't see any reference to "vtable" in INVOKEVIRTUAL?
21:38 < tgrabiec> arch/x86/insn-selector_32.brg line 529
21:38 < tgrabiec> vegard: it assumes that it's at zero offset relative to classblock
21:38 < vegard> ah. and no comments to document it!
21:41 < tgrabiec> vegard: precisely, it assumes that classblock->vtable.native_ptr pointer is sizeof(struct object *) bytes after class pointer
21:45 < vegard> thanks, I understand more now.
22:01 < vegard> http://pastebin.com/m3e37410d
22:02 < vegard> the INVOKEVIRTUAL on line 47
22:02 < vegard> compiles into lines 78-82 if I understand correctly
22:03 < vegard> those correspond to the assembly on lines 121-126
22:04 < vegard> now, it's the line 123 that segfaults, and %ebx at that point is 0
22:17 < tgrabiec> vegard: any progress on that one ?
22:17 < vegard> not so much yet :)
22:17 < vegard> I was going to ask what's supposed to be at 0(%esp)
22:18 < tgrabiec> i guess it should be  the object reference
22:18 < tgrabiec> line 123 is getting the class pointer
22:19 < vegard> that push %esi on lnie 120.. .is that the same thing we're reading back?
22:19 < tgrabiec> yes
22:20 < tgrabiec> it's also passed to the method invoked ('this' pointer)
22:30 < vegard> %esi is loaded from the line before, line 119
22:31 < vegard> this one: mov 0x14(%ebx), %esi
22:31 < vegard> and %ebx is loaded on line 117: mov $0x9411380,%ebx
22:34 <@ahuillet> regallocator bug again ? grrr
22:34 <@ahuillet> vegard : you're up to date right?
22:34 < vegard> no!
22:34 < vegard> this is with jamvm chucked :)
22:35 <@ahuillet> NOT MY FAULT ? life is great !
22:35 < vegard> not your fault, no. this is the putstatic regression test. I'm trying to make it work with the new class loader :)
22:35 < vegard> (and those tests work perfectly with the repository that I forked)
22:36 <@ahuillet> I fixed it recently, we had a bug in the register allocator
22:36 <@ahuillet> hence my asking
22:36 < vegard> oh. how recent?
22:36 <@ahuillet> 'bout one month
22:36 < vegard> no wait -- nothing should change. it shouldn't make a difference.
22:39 < vegard> I am simply ripping out the class loader. so everything else (including register allocation) should continue working in exactly the way it did before :)
22:56 < vegard> class_field int 0x9411380
22:58 < vegard> ok, so it's a static method and a static field
22:59 < vegard> so I guess there is no "this" pointer here
23:03 -!- tgrabiec [n=tomekg@rev-189-107.ramtel.pl] has quit ["Leaving"]
--- Log closed Wed May 20 00:00:33 2009