[bitc-dev] Fwd: Retrospective Thoughts on BitC
Jonathan S. Shapiro
shap at eros-os.org
Sun Mar 25 08:15:49 PDT 2012
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
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
Java: Write Once, Bloat Everywhare.
> Also in C# you can already run C# programs in SQL server...and they are
> compiled once so there stored procs will rarely hit bytecode or the VM
> startup costs.
Also true in Java. The bytecode compilation isn't the problem.
> A pauseless GC can be built to do this , but this alone with a minimal
> barrier is an impressive project...
A pauseless GC *has* been built for .NET. Take a look at Bjarne
Steensgaard's work. I'm sure there is an official source, but his page is
The long and short of it is that it isn't being shipped.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev