[bitc-dev] Fwd: Retrospective Thoughts on BitC
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
> 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...
More information about the bitc-dev