On Sat, Mar 24, 2012 at 7:51 PM, Bennie Kloosteman <[email protected]>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. 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 here: http://www.steensgaard.org/bjarne/ The long and short of it is that it isn't being shipped.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
