January 10, 2010 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
January 10, 2010 NOTICE: This channel is no longer actively logged.
[00:58:37] *** FabienD has quit IRC[05:45:19] *** peda has joined #JNode.org[05:52:38] *** peda_ has quit IRC[15:01:00] *** echelog-1 has joined #JNode.org[15:01:49] *** Mazon has joined #JNode.org[16:32:13] <FabienD> hi benoit and happy new year ![16:32:46] <benoit> happy new year too![16:39:07] <benoit> ismael told me he spoke with you about the gc[16:56:28] <FabienD> right and peda told me some things about that after ismael has left the channel[16:56:37] <FabienD> it should be somewhere in the irc logs[16:58:07] <FabienD> discussion with ismael (but there was also some private discussion) : http://echelog.matzon.dk/logs/browse/jnode.org/1262386800[16:58:41] <FabienD> discussion with peda : http://echelog.matzon.dk/logs/browse/jnode.org/1262473200[17:00:44] <benoit> ok, i'll give it to him[17:00:46] <FabienD> what I remember is that you should take care of gc at boot time[17:01:11] <benoit> ok[17:01:27] <benoit> we will see that together at our next meeting[17:03:04] <_Pete_> benoit: is there room for a newebie jnoder to somehow help/try in your project?[17:06:43] <benoit> _Pete_: yes, why not[17:07:24] <_Pete_> things you do intrests me[17:07:40] <benoit> ok[17:07:41] <_Pete_> so far only got done for JNode are some simple shellcmds[17:08:03] <benoit> we've started to implement a generational GC[17:08:14] <FabienD> _Pete_: you 're welcome to help them with gc[17:08:43] <_Pete_> I have about none knowledge of that[17:08:58] <_Pete_> but still intresting[17:10:34] <FabienD> benoit: I wonder if your school would see a problem with a person external like _Pete_ being implied in your student project[17:10:48] <FabienD> personnally, I am welcoming any help[17:11:25] <benoit> _Pete_ if you want we have some documentation about garbage collection[17:12:33] <benoit> FabienD: it don't think it's a problem for the school, what they want is we work on a project[17:13:04] <_Pete_> benoit: nice, is that jnode specific or general?[17:13:35] <_Pete_> my knowledge is just "it happens"[17:13:37] <_Pete_> not much more[17:14:01] <benoit> not it's not JNode specific[17:14:19] <benoit> in fact JNode embeds a JVM which is rather standard[17:14:28] <_Pete_> right ok[17:15:12] <benoit> the garbage collector we are implementing looks like the JVM 1.4 or 1.5 (i'm not sure)[17:15:57] <_Pete_> ok[17:16:04] <_Pete_> so any good docs for that?[17:16:44] <FabienD> but the implementation will be jnode specific ;)[17:17:02] <benoit> yes, sure[17:17:38] <benoit> the Wikipedia's article is quite good : http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29[17:20:18] <benoit> this one is rather good but it's in french (i don't know what your nationality is): http://gfx.developpez.com/tutoriel/java/gc/[17:20:43] <_Pete_> it is Finnish[17:21:27] <_Pete_> so this gc is there deep in OS[17:21:41] <_Pete_> what is the actual tasks you are trying to do with it[17:21:43] <_Pete_> ?[17:22:43] <benoit> we are creating different memory areas for the different generations[17:23:02] <_Pete_> do you mind if I ask as you explain[17:23:05] <_Pete_> what I do not know?[17:23:44] <benoit> ok, but i'm not sure i'll be able to answer all your questions[17:23:59] <_Pete_> or maybe they are on that wiki[17:24:10] <_Pete_> but dont have mind to get it just now[17:24:39] <_Pete_> what are those different generations?[17:24:55] <benoit> there is a white paper written by Sun about the Hospot JVM's memory management[17:24:58] <benoit> http://java.sun.com/javase/technologies/hotspot/gc/memorymanagement_whitepaper.pdf[17:25:24] <benoit> generations depend from the memory's age[17:25:46] <_Pete_> like when they are last touched?[17:25:57] <FabienD> I would say object's age :)[17:26:06] <benoit> yes, memory's age[17:26:35] <benoit> when you create an object in a code block ({ .... }), it's life span is very short if no other reference points to it[17:27:14] <_Pete_> one more question for this age[17:27:26] <_Pete_> ... no[17:27:33] <_Pete_> forget... please continue :)[17:27:34] <benoit> when you create an object it goes in the area we call Eden[17:27:58] <benoit> when the Eden is full, we launch GC[17:28:44] <benoit> and the memory which is still used goes in the survivor area[17:29:05] <_Pete_> ok[17:29:27] <benoit> then it stays a certain time in the survivor area and after it goes in the last generation[17:29:48] <_Pete_> :)[17:30:07] <benoit> when an object is old, the probability it disappears is low[17:30:24] <benoit> whereas when it's just come to be created, it could disappear soon[17:31:09] <benoit> it's a little more complicated to optimize implementation, but the theory is that[17:31:53] <benoit> in the old generation, the garbage collector is triggered more rarely[17:32:02] <_Pete_> "whereas when it's just come to be created, it could disappear soon" ?[17:32:29] *** ismael has joined #JNode.org[17:32:55] <ismael> hi[17:32:57] <benoit> when you do a new, you don't know when the object will die[17:33:05] <FabienD> hi ismael[17:33:10] <benoit> the probability it dies soon is quite high[17:33:23] <_Pete_> why so?[17:33:26] <benoit> i've called ismael to help me to explain you ;)[17:33:40] <ismael> benoit: i'm coming to the rescue[17:33:51] <benoit> it's what i told at the beginning[17:33:52] <_Pete_> \o/[17:34:03] <benoit> when you reach a } (end of block)[17:34:37] <benoit> you know that all local variables whose references haven't been copied elsewhere will die[17:34:52] <_Pete_> right[17:35:21] <_Pete_> does it help that I tell you I currently work/think C[17:35:37] <_Pete_> and with that point of view try to understand this[17:36:35] <benoit> ok, in Java it's exactly the same thing for that[17:37:00] <benoit> in C when you reach a block end, the compiler unstacks the block, ok ?[17:37:09] <_Pete_> right[17:37:37] <benoit> in Java, the memory isn't in the stack, it's in what we call a heap[17:38:06] <benoit> the stack only contains references heap'adresses[17:38:33] <_Pete_> hmm[17:38:44] <_Pete_> so in Java only have *something[17:38:56] <_Pete_> while C might have * + something whole copied ?[17:39:01] <benoit> approximately yes[17:39:11] <_Pete_> ok[17:39:28] <benoit> in C when a variable is not a pointer, it's stored in the stack, ok N[17:39:30] <benoit> ?[17:39:40] <_Pete_> ok[17:40:20] <benoit> when you allocate some memory (malloc) it's not in the stack, right ?[17:40:28] <_Pete_> right[17:40:43] <benoit> in Java every variable is a reference (pointer) to an allocated memory[17:41:07] <benoit> right?[17:41:10] <_Pete_> allocated memory being jvm memory space?[17:41:33] <benoit> yes, in fact, it's the JVM that allocates the memory[17:41:53] <benoit> the JVM has a heap[17:41:55] <_Pete_> does it have own virtual address for who ever uses it ?[17:42:37] <benoit> yes, the JVM translates it when it accesses to the real memory[17:43:11] <_Pete_> and real memory is some underlaying process memory?[17:44:08] <benoit> on the windows or linux, the JVM runs in a process, so it's in the process memory's space[17:44:21] <_Pete_> ok[17:44:25] <benoit> in JNode, it's more complicated[17:44:37] <benoit> because there is no real operating system[17:44:51] <benoit> JNode can be seen as a stand alone JVM[17:45:05] <benoit> but the principle is the same,[17:45:08] <benoit> right?[17:45:30] <_Pete_> standalone?? where does that JVM run then?[17:46:36] <benoit> directly on the processor[17:47:16] <_Pete_> ok right[17:47:16] <_Pete_> cookl[17:47:54] <benoit> ok, now you know where the objects are stored[17:47:57] <benoit> in the heap[17:48:26] <benoit> and it's this heap that we are gonna split in different areas which are associated to each object generation[17:48:52] <_Pete_> I prefer still memory as memory[17:48:52] <_Pete_> directly[17:49:26] <_Pete_> but do you refer to physical memory ?[17:49:52] <benoit> not exactly[17:50:11] <benoit> the JVM is able to run different applications simultaneously[17:50:25] <_Pete_> yes of coz[17:50:38] <_Pete_> but all mem access should go thru mmu unit[17:50:39] <benoit> it's rather like an operating system, each process has a heap if you prefer[17:50:47] <FabienD> _Pete_: do you know the flat memory model in C ? I think it's the same in jnode since jnode can use all the available physical memory[17:51:01] <_Pete_> FabienD: sure I do[17:53:05] <benoit> i don't know what interacts with the MMU but i think it's in a lower layer[17:53:17] <_Pete_> yes[17:53:24] <_Pete_> but are jnode using it?[17:53:42] <benoit> i'm not sure, but i think so[17:54:07] <benoit> FabienD: can you confirm (or not) that ?[17:55:34] <benoit> but the JVM is at a higher level[17:55:50] <benoit> you don't have to take care about MMU[17:55:51] <FabienD> I know that MMU means Memory Management Unit but I am not sure what it do exactly[17:56:12] <_Pete_> FabienD: it manages virtual memoryspaces[17:56:17] <_Pete_> for invidual processes[17:56:36] <_Pete_> "like every process runs on their own"[17:56:40] <benoit> MMU ensures translation, it enables you yo use virtual adresses[17:56:54] <FabienD> ok[17:57:41] <benoit> it's what raise a processor exception when you want to access an adress that is forbidden for you[17:57:42] <FabienD> no, we don't have virtual memory : I think it's called flat memory model, right ?[17:58:01] <_Pete_> FabienD: no[17:58:10] <_Pete_> that's different thing[17:58:50] <benoit> each Java application runs in a virtual memory space[17:59:05] <_Pete_> inside JVM ?[17:59:12] <benoit> but i don't know how it's managed in the lower layers[17:59:32] <benoit> each application runs in an instance of the JVM[17:59:41] <_Pete_> hmm[18:00:03] <_Pete_> and that instance of JVM is the one which is booted with jnode?[18:00:11] <benoit> if you prefer, a Java application corresponds to a Linux process[18:00:13] <FabienD> have you seen the docs in svn under docs/vm-specs ?[18:00:33] <FabienD> there is a scheme showing memory model in jnode[18:00:53] <FabienD> (addres-space.pdf)[18:01:01] <benoit> no, the JNode kernel doesn't run in a JVM[18:01:19] <_Pete_> benoit: ok[18:01:22] <_Pete_> hold for that[18:01:58] <_Pete_> so some is kicked in boot which then again kikcs JNode kernel ?[18:02:03] <benoit> but the JNode kernel doesn't do many things[18:03:04] <benoit> when you boot JNode, you run assembly which launchs JNode kernel[18:03:22] <_Pete_> ok[18:03:24] <benoit> JNode kernel is written in Java but doesn't run in a JVM[18:03:32] <_Pete_> ok[18:03:37] <_Pete_> what that does[18:03:39] <_Pete_> in general[18:08:38] <_Pete_> anyway sticking to orginal[18:08:48] <_Pete_> I do have lots of catch up[18:09:09] <_Pete_> so I really understand what's this gc problem[18:11:20] <benoit> this pages explains how the current gc works: http://www.jnode.org/node/33[18:11:40] <benoit> the white paper i gave you explains the gcv we want to implement[18:11:54] <_Pete_> ok :)[18:12:04] <_Pete_> I will try to learn those[18:14:00] <_Pete_> anyway[18:14:21] <_Pete_> what prevents JNode to be something but i386 ?[18:16:35] <benoit> it's not a topic i know well[18:17:07] <benoit> but i think the low level layers (nano kernel) which is written in assembly hasn't been ported on the other architectures[18:17:49] <benoit> the rest of the JNode kernel shoudl'n be a problem because it's written in Java and should be compilable for any architecture[18:18:02] <benoit> it's what i think but i'm not sure[18:22:32] <FabienD> benoit: _Pete_: actually it i586 minimum :)[18:23:29] <FabienD> jnode only work on x86 compatible CPU right now[18:24:32] <FabienD> to port it to other CPU architecture, you need to rewrite the nanokernel in the target CPU architecture + manage the boot (we use the grub boot loader) +[18:25:01] <FabienD> write another java bytecode -> assembly for the target CPU[18:25:18] <benoit> ok, it's what i thought[18:26:19] <FabienD> some third party libraries are already doing that (=bytecode to assembly) in pure java but it need to be ported to jnode[18:26:39] <FabienD> one of these is the maxwell project (initiated by sun iirc)[18:28:12] <FabienD> https://maxwellassembler.dev.java.net/[18:29:04] <FabienD> since it's "GPL v. 2.0. with the Classpath Exception", the licence shouldn't be a problem[18:31:01] <FabienD> it's the same licence used by gnu classpath/iced tea/openjdk, from which we are taking code to implement the java APIs : in theory, we "only" need to port the native bindings to jnode[18:34:23] <_Pete_> I think that is big "only"[18:35:02] <FabienD> sure ![18:35:52] <_Pete_> that's the shame of the industry imo[18:36:07] <_Pete_> someone usually inventes some nice[18:36:14] <FabienD> one step in multi CPU plateform support would be to use grub 2 instead of grub 1 since it doesn't only work on x86 CPU but also on PPC (and others ?)[18:36:25] <_Pete_> then $is place in to table[18:36:41] <_Pete_> in that point it's easy think about free[18:36:47] <_Pete_> and ferrari[18:55:42] *** ismael has joined #JNode.org[22:16:23] *** galatnm has joined #JNode.org