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.
http://labs.jboss.com/portal/index.html?ctrl:id=page.default.blog&project=jb
ossrules&from=1&link=http://labs.jboss.com:8080/projects/jbossrules/blog/sta
tus_of_IKVM_and_Drools.html#http%3A%2F%2Flabs.jboss.com%3A8080%2Fprojects%2F
jbossrules%2Fblog%2Fstatus_of_IKVM_and_Drools.html
Mark
