[bitc-dev] Fwd: Retrospective Thoughts on BitC

[Bennie Kloosteman]

---------- Forwarded message ----------
From: Jonathan S. Shapiro
Date: Saturday, March 24, 2012
Subject: Retrospective Thoughts on BitC
To: Florian Weimer <fw at deneb.enyo.de>
Cc: "Jonathan S. Shapiro" <shap at eros-os.org>


On Friday, March 23, 2012, Florian Weimer <fw at deneb.enyo.de> wrote:
> * Jonathan S. Shapiro:
>
>>    - Run-time optimization has very negative consequences for startup
times

>
> >>    - especially in the context of transaction processing. Lots of hard
> data on
> >>    this from IBM (in DB/2) and others. It is one of the reasons that
> "Java in
> >>    the database" never took hold.
> >
> > Are you sure about this?  It seems to be more of a technical issue
> > because both the Oracle JVM and databases each bring their own
> > operating system substrate with them and are thus at odds.  Nowadays,
> > startup times are comparable to VMs which can execute inside a
> > database server process.
>
> Here's the key fact, as measured circa 1990:
>
> Typical DB/2 transaction duration: 150,000 instructions
> Native instructions required to reach first bytecode of main in IBM's JVM:
> 1,500,000 instructions
>
> Note the JVM hasn't done anything actually useful by that point. This
> datum is what prompted all of the work to pickle the initialized state.
>
> It's definitely possible to embed a safe language in a database
> effectively. Because of the profligate nature of the libraries, Java isn't
> going to be that language and neither is C#.
>
>
> shap
>

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.


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.

I do agree though you wont see C# for running the SQL queries for a long
time but that is the same reason  it doesnt work well for system code and
that is the  GC and more specifically the memory barrier .   C# can run
mutable compiled ( ngen assemblies) so the difference to C++ for code
execution can be fast but the memory costs are a killer .  ( Yes you can
use unsafe byref and stackalloc but it is a black art)

A pauseless GC can be built to do this , but this alone with a minimal
barrier is an impressive project .  Many of the people who use C++ now  (
and im not talking the systems people) eg  merchant banks  and 3D Games
would jump to C# or Java and pay big bucks  for an enterprise version.

Regards,

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20120324/546a1009/attachment-0001.html