Yes we can turn certain parts of core into
factories, to make it work
better with .Net. One of those will need to be
PackageCompilationData -
which is responsible for the compiled code and
classloaders. Someone is
going to need to do some research on how we can do
runtime compilation
of code, wiring it up via reflection, and then
making sure we can drop
it - without getting memory leaks. I still think we
should leverage JCI
to try and promote a common parser API, this later
work will benefit
other java/c# integration projects.
3.0 works much like 2.5. In that we compile a Class
for the rule. Each
predicate, returnvalue, eval and conseqeunce is a
method in that Rule.
Each method then has a generated and compiled
Invoker class. The invoker
class is wired up to the Rule with reflection. So if
I want to call a
consequence I call the Invoker which is generated to
prepare the data
and call the consequence. If I want to drop the rule
I simply delete
those classes and reload the classloadser - all
classes, the byte[], are
in memory, so no disk work. if I update a rule it
drops the classes,
reloads the classloader and then re-wires the Rule.
Mark
Chinmay Nagarkar wrote:
I'm sold! :)
If you really get right down to it, we making a
design choice with
incomplete data and no comparitive examples of
success/failure.
We have to stay flexible and minimize risk of
failure (to deliver and
maintain Drools.NET). Keep one foot in IKVM, one
foot in .NET. We can always
shift the weight to stay balanced.
I feel that continuing interest and coordination
across the .NET and Java
teams will be critical.
-----Original Message-----
From: Mark Proctor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 19, 2006 8:18 PM
To: Chinmay Nagarkar
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED];
Michael Neale; [email protected]
Subject: Re: .net support
I've been chatting to the IKVM guys. dynamic
classes is a one time hit,
so no problem there. The overhead is in the
exception hangling, most
other areas are fine; .Net has slower exception
handling than Java
anyway, IKVM adds further overhead to this.
However we have minimal
exception handling in the core runtime which I
feel is management;
jereon has shown some ways to avoid the really
large hits. The one
caveat, and this is true even with a native port,
.Net 1.0 has an
infexible ClassLoader system compared to Java you
cannot reload classes
- you have to dump the entire appdomain - which
isn't doable. .Net 2.0
apparently allows you to add/remove methods, so
maybe we could work
around that.
Jereom has more work planned on speed, so IKVM
will only get better; if
performance is only 5% on averag worse - I don't
think that justifies a
native port - which will be a huge undertaking,
especially as our
platform grows.
Mark
Chinmay Nagarkar wrote:
We should investigate moving additional
code/components to .NET that are
deemed to be performance killers. Unless that's
impossible within the
constraints of the technology and available
resources, my vote is to
leverage IKVM.
-----Original Message-----
From: Mark Proctor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 19, 2006 1:50 PM
To: [email protected]
Cc: [EMAIL PROTECTED];
[EMAIL PROTECTED];
[EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: .net support
I havea updated the blog with some thoughts on
.Net support and IKVM.
