This project has moved. For the latest updates, please go here.

Memory consumption

Mar 2, 2012 at 8:48 AM

Hello,
i have an online service, where users can customize their "account" via own, server-side-running, scripts. At the moment, i'm using an own written engine, it has nothing todo with javascript. But maybe, i want to change the engine to an javascript-engine. In the one hand, i have Chromium V8(yes, it is possible to use it in .NET, already tried) and in the other hand, jurassic.

I read, jurassic uses system.emit to create assemblies in memory. So it uses an appdomain as well, i think. So here are my two questions:

- Are there any memory leaks, because of using "assemblies"? What is, when 1000 users changes a script 100 times, do i have than 1000000 assemblies or unused ilcode-framents in memory? Are they freed afters exiting the script?

- What about .NET to Javascript communication performance(and back). I have a complex object hirarchy, and some objects are not serializable. My current script-engine runs in same appdomain and has direct access via reflections to the object tree, so a objects needs never to be serialized. How works this in Jurassic?

Greetings,
Sebastian

Mar 2, 2012 at 9:08 AM
Hi Arakis,

I have no problems running Jurassic on the server side with Cloudlab (http://cloudlab.io). Everything is disposed of correctly as far as my profiling goes.

-Tristan.

On 02/03/2012, at 19:48, "Arakis" <notifications@codeplex.com> wrote:

From: Arakis

Hello,
i have an online service, where users can customize their "account" via own, server-side-running, scripts. At the moment, i'm using an own written engine, it has nothing todo with javascript. But maybe, i want to change the engine to an javascript-engine. In the one hand, i have Chromium V8(yes, it is possible to use it in .NET, already tried) and in the other hand, jurassic.

I read, jurassic uses system.emit to create assemblies in memory. So it uses an appdomain as well, i think. So here are my two questions:

- Are there any memory leaks, because of using "assemblies"? What is, when 1000 users changes a script 100 times, do i have than 1000000 assemblies or unused ilcode-framents in memory? Are they freed afters exiting the script?

- What about .NET to Javascript communication performance(and back). I have a complex object hirarchy, and some objects are not serializable. My current script-engine runs in same appdomain and has direct access via reflections to the object tree, so a objects needs never to be serialized. How works this in Jurassic?

Greetings,
Sebastian

Coordinator
Mar 3, 2012 at 12:54 AM

1. By default, Jurassic uses DynamicMethod to generate code.  This does *not* use a separate AppDomain.  Code generated using DynamicMethod is eligible for garbage collection - my test suite runs over 10,000 scripts without any memory issues.  There is a property to enable debugging support which does leak, however.

2. Because Jurassic code runs in the same AppDomain as the calling code, there is no marshalling cost to accessing JavaScript objects.  Of course, if you set up an AppDomain to run the user code in, then there is a cost, but Jurassic does not do this.  All Jurassic built-in objects are serializable, using standard .NET serialization.

There is one serious problem to running arbitrary user code using Jurassic: a StackOverflowException will terminate the entire .NET process with extreme prejudice (unless it is being hosted, in which case the host can decide what to do).  This is not really a Jurassic problem (it applies to all .NET code) but Jurassic makes no attempt to mitigate this problem.