On Fri, 10 Dec 2004 09:48:51 +1100, Matthew Geier <[EMAIL PROTECTED]> wrote: > Dave Carabetta wrote: > > > No, as I've said before, because of the way fork() is implement in > > UNIX, it will make a copy of the parent process's memory footprint and > > use that value when it creates the child process (which is what > > cfexecute does). 1K or 100000000K, it makes no difference. This is > > just a UNIX "feature." > > This isn't strictly true. I would expect most modern Unix's are 'copy > on write' when a process 'forks'. Linux certainly is. > Pretty well the only different between a fork and a 'vfork' > (threading) is that the thread doesn't 'copy on write'... > > So the fork does not use an entire copy of all the RAM occupied by the > process. The application code space it self is marked read only and > shared and the other memory is copied in pages as the new process writes. > > The JVM might be doing something oddball with its RAM cauing an entire > new working set created each time it forks, and possibly this is the > performance hit - every time jrun forks, it 'scrubs' it's entire working > memory set. >
Yes, it's how the JVM uses fork() as opposed to vfork(). Here's the bug URL. Note that it's old, but the problem still exists even today: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4227230 You are correct about vfork(), but they note that it is unsafe in multi-thread applications and won't work on native threads, so it won't get fixed.. Regards, Dave. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Special thanks to the CF Community Suite Gold Sponsor - CFHosting.net http://www.cfhosting.net Message: http://www.houseoffusion.com/lists.cfm/link=i:14:3774 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/14 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:14 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.14 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
