Off-list discussion taken back on-list. On 7/9/07, skaller <[EMAIL PROTECTED]> wrote: > On Mon, 2007-07-09 at 12:03 -0400, Sandro Magi wrote: > > Ok, I think we're on the same page now. I think you'll agree that if > > (2) allocates resources that survive its own execution, those need to > > be booked to the agent. Potentially, (2) runs in response to a VM > > service (7) (ie. load bytecode), so resources whose scope escapes the > > request must be accounted for. > > Actually worse: if (7) invokes (2) to *run* bytecode, then during > the middle of the service request, new code can begin to run, > i.e. there's now a new 'sub-agent' owned by the calling agent, > and now this code is running, even in the middle of a service > request, so it has to be booked against something.
Oh I would *never* suggest doing that. The VM should conform closely to the ideal of a microkernel IMO, where system calls are small in number, atomic and "prompt". Running bytecode on behalf of another agent is certainly neither prompt nor atomic. :-) If an agent wanted to execute code, he would have to spawn another language process to execute it (or he could simply load and instantiate the object himself). > > Yes, this is the type of "implicit" allocation I'm referring to. I > > hope I can keep my code simple enough that I won't need to use higher > > order features. > > I hope to convince you this isn't necessary. > > Many people in the games world think dynamic allocation > and garbage collection are evil.. in fact this is rot. Well, I don't think it's "evil"; I quite like it actually. I'm just hoping to keep the VM kernel so simple that the greater abstraction provided by HOF isn't actually useful. Consider microkernels like EROS where IPC and some low-level system objects are the only kernel code. Really EROS is a machine-level VM, and there is very little reuse and abstraction in such a small, low-level code base. A language VM should in theory be even simpler, and it should push as much implementation as possible into the language itself. > [...] > This is similar to how modern processors overclock .. they > jack up the clock rate until the processor stops working > then back off .. yet there is no fault detection. > > What actually happens is the designers know that the > limit is actually heat. Heat makes quantum devices like > transistors fail. So they just measure the heat and when > the processor gets too hot, turn up the fans, and reduce > the clock rate. > > So what you really need to do is monitor memory use, > and when things get out of hand, kill of the agent > which has booked up too much memory .. but it doesn't > need to be an exact figure! In a sense, this is how the GC accounting algorithm works: once memory pressure passes a threshold, the GC runs and reclaims storage, and kills off processes that have exceeded their quota once collection is complete. I was probably going to tweak this so that each process keeps an allocation count, and once that count is exceeded, a GC is run under that process's schedule and readjusts the count; thus, even GC is scheduled. The problem is that without precise information, you can't make the "kill process" judgment with any accuracy; you're left with heuristics as in Linux/Unix of killing processes off randomly (although you might have more information in this case). > > Thanks for the suggestions; it might be indeed be possible to replace > > allocators, but I'd like to avoid that complication entirely if > > possible: KISS. This is why I'm hoping the algorithms won't need much > > if any allocation. > > Of course. Just don't worry if you do some, even magically. I certainly won't be averse to it if it presents significant advantages, no worries. :-) > Yep. Actually, one idea I've been toying with is to merge Felix > and Erlang .. Felix is much better at shared memory multi-processing > but Erlang is better at distributed parallelism with message passing. Hm, interesting; merge in what sense? > > * Does Felix abstract these? I suspect I'll need to bind to a C/C++ > > library like libaio. Ah, the accounting hell will entail... :-) > > Felix comes with a high performance platform independent > asynchronous I/O subsystem: works with sockets mainly, > but RF (the author) is playing with Unix pipes and some > other stuff. Excellent! :-) > There's some support for async disk file I/O, but really > Linux can't do this so it's fairly pointless. Well, some web servers seem to do fairly well with epoll (see lighttpd, et al). > libaio is crap: it does it in user space with pthreads. Not too familiar with it, just that it exists. As long as Felix has something, I can build on that. > I guess we've covered enough ground to both believe Felix > MIGHT be useful for your application. To go any further, > you probably need to try it :) I agree. The resource use properties seem no worse than C++, and Felix is considerably better in all other areas. Sandro ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
