logs | stats
   February 28, 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

[05:22:03] *** mrmcq2u has joined #JNode.org
[05:22:33] <mrmcq2u> does the rubicks cube app bundled with jnode use java3d?
[05:23:14] <mrmcq2u> *rubiks
[08:48:06] *** FabienD has joined #JNode.org
[09:18:24] <FabienD> hi mrmcq2u and welcome to jnode :)
[09:20:16] <FabienD> mrmcq2u: jnode doesn't yet support java3d. so the rubick's cube game is only using java2d (without acceleration). you are welcome to help us.
[10:20:14] *** rommanio has joined #JNode.org
[10:41:03] *** FabienD has quit IRC
[10:41:51] *** FabienD has joined #JNode.org
[11:41:23] <rommanio> For what pirposes is the NativeStream class?
[12:07:07] <peda_> it aggregates the native opcodes and creates the native code
[12:07:38] <rommanio> ok, thanks
[12:07:38] <peda_> i.e. you can put single opcodes into the stream..
[12:08:29] <rommanio> I'm create diagram for myself.
[12:11:02] <rommanio> And what does the Vmx86Architecture class? :)
[12:31:18] <peda_> it mainly contains constants needed for the compiler
[12:31:41] <peda_> they abstract the differences between 32bit and 64bit arch.. if you have a look, there are two implementations of it
[12:32:51] <rommanio> but why it is in bootimage?
[12:34:00] <rommanio> Sorry if I fistract you!
[12:38:57] <rommanio> *distract
[13:24:18] <peda_> no no, I'm just busy with other stuff, so I'm always answering with a bit delay :)
[13:24:53] <peda_> and it is in the bootimage as you either boot on a 32bit or on a 64bit architecture.. or what do you mean?
[13:35:55] <rommanio> but for what purpose? if it using in compiler.
[14:23:57] <peda_> I do not understand. You need l1a (and therefore Vmx86Architecture, NativeStream,...) to compile classes during runtime
[14:24:24] <peda_> once the basic hardware setup is done you want to execute java code.. so you need a jit
[14:24:54] <peda_> and to actually work, the jit (and all classes it needs) have to be compiled as native code into the boot image
[14:26:26] <rommanio> ok therefore in runtime using the same classes that in build time?
[14:27:57] <peda_> yup
[14:28:20] <peda_> there's just a boolean somewhere that tells the compiler if it's in build- or runtimemode
[14:28:34] <peda_> (which makes a little difference in how "linking" happens)
[14:40:07] <rommanio> but really l1a is jit compiler?
[14:40:24] <peda_> yes
[14:40:43] <peda_> l1a is the name for a basic "fast" non-optimizing jit compiler in jnode :)
[14:41:16] <rommanio> I don't understand...
[14:41:34] <peda_> l1a stands for "level 1a"
[14:41:38] <peda_> and is just a name
[14:41:44] <peda_> for the JIT compiler in JNode
[14:42:29] <rommanio> how jit xompiler may compile satically native code?
[14:42:58] <rommanio> statically
[14:43:01] <peda_> ah ok, I think I understand your problem :)
[14:43:08] <peda_> that's kind of easy
[14:43:37] <peda_> what a JIT normaly does is: It takes an array of bytecodes and transforms them into a byte array of native codes
[14:43:46] <peda_> it contains all the "add, mov,..." values
[14:44:12] <peda_> and basically those bytearrays are just stored into a file: the bootimage :)
[14:44:26] <rommanio> but how to be with dynamically code?
[14:44:52] <peda_> the most basic bootup just _is_ statically linked
[14:45:17] <peda_> it's executed once to bootup.. so no need for dynamic calls (everything is static or final at that point)
[14:46:02] <peda_> and once that's done (mainly VmSystem, Classloader and stuff like that) is initialized the normal dynamic invokations apply
[14:46:27] <rommanio> OK I think I understand it :)
[14:46:31] <peda_> :)
[14:55:57] <rommanio> it is time for me..
[14:56:42] <rommanio> Sorry for my questions, if so!
[14:58:15] *** rommanio has quit IRC
[17:40:33] *** influt has quit IRC
[18:55:09] *** peda has joined #JNode.org
[19:02:32] *** peda_ has quit IRC
[19:04:00] <mrmcq2u> How does jnodes device driver framework differ from squakevm and the opensolaris java driver framework?
[19:29:43] *** influt has joined #JNode.org
[20:05:58] <peda> hi mrmcq2u
[20:06:18] <peda> I have no idea as I neither know squakevm's nor opensolaris java driver framework
[20:45:56] *** mrmcq2u has quit IRC
[20:59:37] *** mrmcq2u has joined #JNode.org
[20:59:53] <mrmcq2u> ok cool
[21:00:52] <mrmcq2u> Yeah, the solaris java driver framework seems to have next to no actual documentation that I can find
[21:02:02] <mrmcq2u> The most info I could find was that they implement a modified version of squawk as a kernel extension for solaris
[21:03:49] <mrmcq2u> Would be interesting to have jnode use a common driver framework which could be used on linux and solaris via kernel extensions for building desktop agnostic drivers
[21:04:27] <mrmcq2u> Would help speed up the development if people on linux and solaris were developing say gfx drivers which worked on all platforms
[21:05:57] <peda> well, sharing with traditional OSes is highly unlikely since we depend on 100% managed bytecode for our drivers
[21:06:35] <peda> and I guess it would be kind of hard to find such common interface so one could actually share code
[21:30:07] <mrmcq2u> Well wouldnt the vm be the common interface
[21:30:41] <mrmcq2u> each vm would need to interface with the host system differently alright
[21:31:08] <mrmcq2u> but in terms of a common way of writing device drivers I think its possible
[21:39:24] <peda> well, but the architectural differences remain
[21:39:46] <peda> e.g. JNode has "flat memory", no virtual address space
[21:46:04] <mrmcq2u> Well keep in mind that squawk also uses isolates and flat memory iirc and that is the vm which has been implemented as a kernel extension for solaris to develop drivers in java
[21:53:57] <peda> oh ok, didn't know that
[22:00:15] <mrmcq2u> Yeah.. squawk vm is not metacircular though from what I have read from the intel guys who worked on moxy jvm
[22:00:45] <mrmcq2u> but it still seems to be the only sun jvm which implements isolates from what I know
[22:00:55] <mrmcq2u> I dont think maxine implements them
[22:35:09] <mrmcq2u> http://www.google.ie/url?sa=t&source=web&ct=res&cd=4&ved=0CBcQFjAD&url=http%3A%2F%2Fresearch.sun.com%2Ftechrep%2F2006%2Fsmli_tr-2006-156.pdf&ei=-eGKS5DwDMOQjAfmoPG6DA&usg=AFQjCNFWeZlpG93ZMfoJMLnECnF6093rKg&sig2=G1o_IyyOfba9MQ7eApVdUQ
[22:35:30] <mrmcq2u> Thats a link to info on creating drivers in java for solaris if your interested
[23:11:45] <peda> yeah, I know that.. we should have it somewhere in our refs
[23:45:25] <mrmcq2u> peda - have you seen decaf?
[23:46:13] <mrmcq2u> http://pages.cs.wisc.edu/~swift/projects/drivers.html
[23:46:27] <mrmcq2u> at the bottom of the page there is a presentation explaining it
[23:47:54] <mrmcq2u> Its basically tackling the issue of driver development in java
[23:48:11] <mrmcq2u> Its a recent stab at it too, the presentation was from 2009
[23:50:06] <peda> no, didn't know it
[23:50:12] <peda> thanks's for the link
[23:53:26] <mrmcq2u> no prob
[23:57:51] *** FabienD has quit IRC

top