Hi Casey, Following my previous mail, please try this small performance test. It illustrates what I want to do and the performance "loss" that is expected. Simply unpack and run make. Cheers, Guilhem. Casey Marshall wrote: > On Feb 2, 2006, at 10:27 AM, Guilhem Lavaux wrote: > >> Casey Marshall wrote: >> >>> On Jan 31, 2006, at 6:10 PM, David P Grove wrote: >>> >>>> Jikes RVM also does m-to-n threading, so it's there's more than 1 VM >>>> that's whacky in this regard. The things we need to do are most >>>> likely >>>> different than what Kaffe needs to do, but having a chance to >>>> inject a VM >>>> callback before the thread dives off into a blocking system call is >>>> something we would like to be able to do. We have some linux specific >>>> hacks (evil with dlopen to intercept poll, select, etc), but it's >>>> fragile >>>> and doesn't work on other platforms like AIX and OS X that Jikes >>>> RVM runs >>>> on. >>>> >>> Would my suggestion for Enter/Exit callbacks help this? >> >> >> Though enter/exit callbacks may help for a few syscalls but it won't >> for some (like blocking read/write). For these new calls you need >> handle blocking queues in the VM thread scheduler. That needs to put >> the fd into non-blocking mode and when you do a read you first check >> if there is any data (in non-blocking mode) and if there is not data >> then the thread system queues the current thread and tells the >> scheduler to jump somewhere else until some datas are available on >> the specified fd. So we must really stick to rerouting a few IOs. I >> am sure that handling m-to-n threading system is as difficult as >> what we are doing (maybe more). >> > > Aha, I grok the issue now. Would it make sense to do conditional > compilation based on a "green threads" model, so that you can compile > all blocking I/O calls to support such a model, if configured thusly? > Or would file descriptor callbacks help -- where the FD is put into > non-blocking mode before the call, then reset after, with support to > catch the `EAGAIN' if it arrives? > > Also, I'm sure you could write a kernel-threads compatible library that > also supported user-mode thread models at the same time (the > restrictions on the former seem to be a subset of the latter), but > don't know about what performance drain that would incur on kernel > threaded systems. Because, "one POSIX library to rule them all," that > supported both thread models, would still be an awesome thing. > -------------- next part -------------- A non-text attachment was scrubbed... Name: perf.tar.gz Type: application/x-tar Size: 850 bytes Desc: not available Url : http://developer.classpath.org/pipermail/classpath/attachments/20060204/ee83e747/perf.tar.tar
