**** BEGIN LOGGING AT Sun Feb 4 10:53:21 2001
10:53:21 --> RobertFit (~bob@194.125.56.12) has joined #jos
10:53:48 --- RobertFit sets mode +t
10:53:50 --- RobertFit sets mode +n
10:53:52 --- RobertFit has changed the topic to: The JOS Project
12:31:10 --> jewel_ (~jewel@pta-dial-196-31-186-136.mweb.co.za) has joined #jos
12:31:20 Hi John.
12:40:48 Hey Robert
12:42:34 How's it going?
12:43:44 It's been quite busy
12:43:53 But things are coming under control now
12:43:57 How have you been?
12:45:09 I'm good, I've been a little busy in work.
12:45:35 I'm afraid I can't actually chat right now, will you be here in about 15-30 minutes?
12:45:45 Yes.
12:45:56 see you a bit later
12:46:01 Ok.
13:08:49 --> risi (~risi@netapp2.skynet.be) has joined #jos
13:08:51 I'm back
13:09:01 WB.
13:09:07 Hi risi.
13:09:08 <-- risi (~risi@netapp2.skynet.be) has left #jos
13:09:13 * jewel_
13:09:30 Yes, In December I went to Mozambique to go diving with some friends
13:09:48 January involved a lot of extended new years celebrations and some work on teaseme
13:10:06 In the last few weeks I've been earning some money doing extra maths tuition
13:10:59 Now I'm trying to organise my life so that I can get back to coding
13:11:45 I haven't really done anything except work, I live a very boring lift. :(
13:11:56 :-)
13:12:08 Where are you working now?
13:12:23 I'm still in Ireland, wasn't able to go back into the US.
13:12:49 You weren't able to go back to your old job, or you couldn't get any work in the US?
13:13:28 Visa problems, I'm working on the project from Dublin now.
13:14:03 the US is pretty tight
13:14:15 Yeah, it's a pain.
13:14:35 When Africans want to apply for holiday visas to the US they have to undergo an *interview* before getting it
13:16:18 It a bit better coming from Europe.
13:17:08 So why did they refuse you?
13:18:21 I was there on buisness using a vistor visa for too long.
13:19:07 Ah ok
13:19:17 How long were you there?
13:20:27 About 9 months in total, the vistor visa is for 3 months but you can leave and get a new one.
13:23:39 --> risi (~risi@netapp2.skynet.be) has joined #jos
13:23:43 Did they know that you had been working?
13:23:56 <-- risi (~risi@netapp2.skynet.be) has left #jos
13:26:24 Sort of, I was there on buisness. I work for an Irish company and was just located there as part of a contract between my company and there client in the US.
13:27:42 So what does your company say, are they upset?
13:28:43 It was that big an issue for my company but the clients were a little upset.
13:28:48 wasn't
13:29:47 So you're working from home?
13:30:46 No, our office in Dublin. I've better internet access and our clients systems at work.
13:31:29 How long will you stay on the project?
13:32:02 There's probably another month or two left.
13:32:12 --> risi (~risi@netapp2.skynet.be) has joined #jos
13:32:23 <-- risi (~risi@netapp2.skynet.be) has left #jos
13:32:43 After that, what are your plans?
13:33:11 I don't know yet, depends what the company want to do with me.
13:33:47 you mentioned NZ the last time we spoke
13:34:40 Yeah that could be an option, but I don't know if that's where they'll send me at this point in time.
13:35:33 Have you been doing any coding besides work?
13:36:13 Yes, I've mostly been working on RJK (Robert's JOS Kernel).
13:36:25 --> risi (~risi@netapp2.skynet.be) has joined #jos
13:36:32 <-- risi (~risi@netapp2.skynet.be) has left #jos
13:36:47 It's going quite well I should be ready to make a new release soon.
13:37:25 Cool, what's changed?
13:38:27 IRQ's, timers and threads now work.
13:39:03 Wow, how do the threads work?
13:39:10 Do you have a scheduler?
13:40:24 It's a very simple scheduler at the moment, just round robin over the list of threads.
13:40:55 Cool, I assume you haven't got any synchronisation primitives yet?
13:42:56 I've got most of the atomic operations, stubs for spinlocks, I will probably add lock's and rwlock's. I'm not sure if I need to put monitors in the kernel it might be better to put them in the JVM?
13:43:40 It probably would be
13:43:48 The last week or two I've been redoing the locks for kissme
13:44:07 I've implemented thin locks that use an atomic cmpxchg instruction
13:44:20 And this falls back to a fat lock (pthread mutex) when there is contention
13:44:51 We will need a way for a thread to efficiently wait to be signalled by another thread
13:46:44 Yeah, I think I'll do that in the scheduler.
13:47:26 Is it possible for me to compile it and check it out?
13:48:14 Yeah, I'll package it up in a few minutes, and email it to you?
13:48:43 please
13:48:54 Ok.
14:03:36 John that's on it's way.
14:05:04 got it
14:06:29 Ok, can I boot it with grub?
14:06:35 There is a floppy img you will need to write to a disk, then build the kernel.elf file and copy it to the disk.
14:06:36 What does it do at the moment?
14:07:03 Yes, it uses grub, grub is on the floppy image.
14:07:35 It just starts 3 threads and prints some messages.
14:08:43 so do I need the floppy image if I already have grub?
14:09:27 It might be better for the moment.
14:16:22 ok, I'm busy writing it
14:16:23 --- Disconnected (Remote host closed socket).
**** ENDING LOGGING AT Sun Feb 4 14:16:23 2001
**** BEGIN LOGGING AT Sun Feb 4 14:18:43 2001
14:18:43 --> RobertFit (~bob@194.125.56.12) has joined #jos
14:18:43 --- Topic for #jos is The JOS Project
14:18:43 --- Topic for #jos set by RobertFit at Sun Feb 4 10:52:51 2001
14:19:40 Once I've written the image, what do I do?
14:20:19 You then need to build the kernel.elf file and copy it to the floppy disk.
14:20:44 You will then need to reboot a computer with the disk in the floppy drive.
14:21:08 To build, "make all" should work on any linux system.
14:21:39 I can't mount the disk
14:23:04 It's a fat formated disk, you will need to do something like "mount -t vfat /dev/fd0 /floppy".
14:23:21 let me try another disk
14:29:47 that's better
14:29:50 so it's just a grub disk?
14:30:20 Yes, grub is needed to load my kernel.
14:30:38 ok I have to disconnect this monitor to boot the other machine, brb
14:37:31 ok, got it to work
14:37:41 had to use the grub on my HD however
14:38:05 What was the problem?
14:38:47 I don't know, I think I selected the first item on the menu, but it didn't boot (can't remember why)
14:38:48 --> tofventje (~jos_02@netapp4.skynet.be) has joined #jos
14:39:00 <-- tofventje (~jos_02@netapp4.skynet.be) has left #jos
14:43:18 So what do you think of it?
14:43:56 Looks good, I'm busy browsing through the code
14:44:28 what is interrupt eight?
14:44:38 RTC.
14:45:05 Real Time Clock.
14:45:20 Is there any VMM code?
14:45:55 kmemory has a very simple one, it's on my Todo list.
14:47:13 how do you install an interrupt handler?
14:49:45 Function kirq_assign_irq in kirq.c does the work.
14:50:59 The asm interrupt service routines are in entry.S which call the C code handle_irq.
14:52:29 Excellent. Is it possible to load another module with grub at boot time (instead of compiling code into the kernel)?
14:53:56 Not at the moment but that's the plan, I'm going to work on that soon.
14:55:41 That would be very useful
14:56:12 I think I'ld like to try make this new "lock" module that I made for kissme work on kissme/teaseme/rjk
14:56:23 Have you implemented any of the lock interfaces?
14:57:14 Yeah, the goal is to have the all JOS jvm use the kinterface and have multiple implementations of the interface.
14:57:39 Do you really think we'll have other interfaces?
14:57:40 No implementations yet.
14:57:56 How much work would it be to make the linux kernel implement the kinterface?
14:58:06 (I meant other implementations in the first line)
14:58:35 but RJK will
14:59:14 It wouldn't be very hard, RJK and some of the interface functions are based on the Linux kernel.
15:00:34 Where is the pthread implementation in the linux source?
15:00:42 Having a interface like this should allow JOS to be ported to platforms quicker because you can just use the existing kernel as a base.
15:00:47 or is it glibc?
15:00:52 glibc.
15:01:06 hmm, where do I get the glibc source?
15:02:07 cvs -z 9 -d :pserver:anoncvs@anoncvs.cygnus:/cvs/glibc checkout libc
15:03:17 bash-2.03$ cvs -z 9 -d :pserver:anoncvs@cvs.cygnus:/cvs/glibc checkout libc
15:03:18 Unknown host cvs.cygnus.
15:03:36 bash-2.03$ cvs -z 9 -d :pserver:anoncvs@anoncvs.cygnus:/cvs/glibc checkout libc
15:03:37 Unknown host anoncvs.cygnus.
15:03:43 sorry should have anoncvs.cygnus.com
15:04:57 It's a big download ~100Mb.
15:05:41 If you go to sources.redhat.com you should be able to find a tar ball.
15:06:07 ok, well I'm pulling it down now
15:06:12 howcome so big?
15:07:33 It implements the C interface for over 20 platforms.
15:08:25 and everyone has a different kernel interface :-)
15:08:40 Yeap. ;)
15:09:47 --> jos01 (~jos_02@netapp4.skynet.be) has joined #jos
15:09:49 --> Diremnce (~Diremnce@nchobo01.telenet-ops.be) has joined #jos
15:09:54 iepz
15:09:59 <-- jos01 (~jos_02@netapp4.skynet.be) has left #jos
15:10:32 <-- Diremnce (~Diremnce@nchobo01.telenet-ops.be) has left #jos
15:10:44 There are 11 Changelogs
15:11:16 Going back to 1992.
15:11:33 Sorry 1991.
15:11:59 In a way, implementing a Java platform is similar to what glibc has done
15:12:04 except we need a kernel too
15:12:15 Brb, I've to get some lunch.
15:12:29 ok
15:21:03 I'm back.
15:26:02 What type of functions do you need in a lock interface?
15:26:35 the first is a just a normal mutual exclusion lock
15:26:52 ie, if one thread has the lock, any other threads must block efficiently until it is free'ed
15:27:39 then I need a similar lock, but it must recursive, ie the owning thread can lock it multiple times
15:28:13 and then a "condition" variable which allows a thread to send a signal to one or waiting threads
15:28:16 Would a read/write lock work for this?
15:28:24 those threads must sleep efficiently while waiting for the signal
15:28:45 What do you mean by a read/write lock?
15:28:54 A lock that prohibits both reading and writing?
15:29:27 A lock that allows multiple reads or one writer at a time.
15:30:11 Yes, but we would just use the write functionality
15:50:18 Does this look right?
15:50:46 while(true) {
15:51:17 if(katomic_compare_and_set_if_equal(m->mutex, 0, current_thread ||
15:51:49 katomic_compare_and_set_if_equal(m->mutex, current_thread, current_thread))
15:52:03 (m->mutex_count)++;
15:52:06 else
15:52:15 kthread_yield();
15:52:16 }
15:52:44 the exit function would be:
15:52:55 if(--(m->mutex_count))
15:53:18 katomic_set(m->mutex, 0);
15:56:00 how do you know the expression after the || will be executed after the first one?
15:56:28 are m->mutex and current_thread 32 bit ints
15:57:03 A kuint in the kinterface is the same size as a pointer.
15:57:05 the exit function must check if the current thread owns the mutex
15:57:45 Are you sure?
15:57:57 With valid bytecode?
15:58:06 Oh I see, the order of the compare_and_set's doesn't matter
15:58:37 Well we don't want to depend on the bytecode
15:58:49 The JVM itself will be using these methods, and there might be a bug there
15:58:58 You would pick the best order to use maybe the check for the current_thread equal m->mutex should be done first.
15:59:21 the order of compares.
15:59:37 the second compare doesn't need to be atomic
15:59:52 if we own the lock, noone else is going to change it while we look at it
16:01:16 The second one will to called when someone owns the lock it may not be the current thread. Though it doesn't have to be a compare and set.
16:01:28 I assume kyield() just schedules another thread
16:01:41 Yes.
16:02:21 So it should be: if( m->mutex == current_thread)
16:02:30 inc count
16:02:55 else if( compare_and_set(m->mutex, 0, current_thread))
16:02:56 But the == isn't atomic.
16:03:00 inc count
16:03:07 else
16:03:10 yield()
16:03:18 it doesn't need to be
16:03:33 because we're only checking for the case when we own the lock
16:04:48 Ok, I see. But you do need to use an atomic compare I'm working on adding one now.
16:05:37 We need the atomic_compare_and_set_if_equal(), do we need a plain atomic_compare?
16:06:09 you mean for the unlock method?
16:06:18 For both.
16:06:32 Where do we need it in the lock method?
16:07:13 The first if, (m->mutex == current_thread) wont work.
16:07:24 why not?
16:08:10 The above is not atomic.
16:08:37 it doesn't need to be
16:09:15 assume the mutex is 0, and we try lock it, if someone changes it while we're doing the test, we'll see some number but it won't be current_thread
16:09:49 if the mutex was current_thread, no-one else will be able to change it
16:11:38 Let me think about this.
16:11:49 :-)
16:15:59 BTW, I'ld like to suggest we move these IRC meeting to irc.openprojects.net
16:16:23 I thinking the same.
16:16:54 We won't be bothered by the Belgians, and the servers are much less lightly loaded
16:18:04 Ok, the next meeting will be on the openprojects IRC network.
16:19:22 --> MX_00 (~MX_00@dh170-186.yucom.be) has joined #jos
16:19:32 speak of the devil
16:19:38 ;)
16:19:48 <-- MX_00 (~MX_00@dh170-186.yucom.be) has left #jos
16:20:29 I'm wondering about the interaction of the first compare and katomic_set in the exit function on SMP system.
16:21:16 so one processor sets the mutex to 0
16:21:26 while another processor is comparing mutex to current_thread
16:21:32 Yes.
16:22:03 I think the compare will see the old value, so it will just come round again for another compare, mmm, maybe come round for _many_ compares
16:22:57 I don't know how the cache works on such systems, will the new value eventually be seen by the other processor?
16:23:39 Does GCC know that it mustn't cache that variable ?
16:23:45 (in a register)
16:23:56 The value will be volatile but I'm still not sure
16:24:22 ok, go for the atomic_compare, better to be safe
16:24:36 We can always change it later.
16:24:48 yes
16:27:34 Is there a way to set the current thread to not only yield, but maybe to miss one or two scheduling opportunities
16:28:05 I'm thinking that if one thread holds a lock for a long time, the other will spend a fair amount of time on the processor just checking for the lock, especially when there are only two threads
16:28:17 At the moment only kthread_sleep.
16:28:55 I think there will be more than two threads, unless the whole JVM is single threaded.
16:29:39 Sure, but even with thousands of threads, if they are all contesting for the same lock it could be inefficient
16:29:57 (but of course they should use then a different kind of lock)
16:30:17 / use then / then use
16:30:33 Yes.
16:42:05 Question, in teaseme where do you store the mutex?
16:43:43 And do you know how much nesting is used?
16:45:20 There is a per-object word which is a thin lock
16:45:31 when it is inflated to a fat lock it points to a new structure
16:45:38 there is a mutex in there
16:45:55 nesting can be infinite
16:46:10 my thin lock nests 255 times
16:46:59 But what's a normal amount, is the mutex normaly free, compare_and_set go first?
16:47:13 shoule compare_and_set go first?
16:47:16 but an integer should be enough for the nesting count
16:47:57 I don't think the mutex will normally be free, because they will be used in the contention case
16:48:11 but the JVM will use these locks to lock it's own structures, and there they will normally be free
16:48:20 I'm wondering should this code/stucture be part of the JVM or the kernel.
16:48:53 Well the question is, will anything else in the kernel use it, does it rely on anything in the kernel?
16:48:56 Or should the one provided by the kernel only be used for the JVM structures.
16:50:19 I currently have two types of locks in mind a spinlock and lock.
16:50:43 we could do that, and then have a special one which the JVM uses for Java locks
16:51:19 The JVM could then inline the enter/exit code etc.
16:51:25 I vaguely remember reading in some of the IBM papers that they implemented some kind of back-off system for locks that were heavily contended
16:51:54 yes, that would give us a speed advantage
16:53:12 Also the kernel interface may not be linked into the jvm, so it would be a system call for each lock.
16:54:22 So does JVM need to be able to nest on the same lock?
16:56:58 At the moment the JVM does use recursive locks
16:57:17 when locking data in classfil.c
17:03:19 I'm trying to minimize the amount of structures in the kernel interface, and it looks like to have you might need a structure.
17:03:41 .. to have a mutex you ...
17:09:50