[bitc-dev] Fwd: Retrospective Thoughts on BitC

Bennie Kloosteman bklooste at gmail.com
Sun Mar 25 10:27:03 PDT 2012

C# has app domains for this basically light weight processes .

I mean all the code can be shared since it read only so you only need a new
heap/ memory region for the GC the cost of that cant be that high. Isnt the
C++ equivalent to a guaranteed state a process restart which is going to
cost a few cycles as well ( at least a fork or mmap) . Do Sql services
today use new processes for each transaction ? Last time i checked they
seem to just use a few processes and kept them alive a long time  but that
could have been under a weaker transactional model...


On Sun, Mar 25, 2012 at 8:15 AM, Jonathan S. Shapiro <shap at eros-os.org>wrote:

>  On Sat, Mar 24, 2012 at 7:51 PM, Bennie Kloosteman <bklooste at gmail.com>wrote:
>>  Not sure why you would start a new process (VM) for a transaction
>> /query ....if you dont its merely a hash  look up to some pre compiled code.
> Finding the code isn't the problem. Getting the initial state set is the
> problem.
> Remember that we are talking about code that runs *inside* the
> transaction on the database server. In order to preserve transactional
> isolation, each such piece of code needs to run in a fresh, "virgin"
> environment. Which means that you need a new JVM for each execution. Which
> means that you need to run all of the global initialization logic for that
> JVM. Which means all of the global initialization logic for the core
> libraries. Which is a *huge* amount of work. The research at IBM and
> elsewhere was to determine how much of that initialization could be
> pre-computed for a known JVM/library configuration.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20120325/ea5db3d2/attachment.html 

More information about the bitc-dev mailing list