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

Mono 3.2.5+ Support : Got it running now...

Nov 30, 2013 at 8:44 PM
I started down a rabbit hole that I was not planning, but now have Jurassic running on Mono 3.2.5 (.Net 4.5, C#5). I have converted the MS Tests to NUnit, added the updated test262 and SunSpider tests and soon will have Octane benchmarks added.

There is still more to do as in a few areas invalid IL is being created, this is a know 'problem' in Mono vs. MS .Net as the JIT in .Net can optimize out certain things that never get validated and you never see a 'problem' where Mono will not and will validate the IL first and throw an exception before the JIT sees it. Other OSS projects like IronRuby, JSON.Net, etc… have run into the same problem. IronRuby fixed a DSL bug, while JSON.Net does a Mono patch… I'll have to research and get dbg going (been a long time since I had to debug w/dbg, so if anyone else it up to speed with dbg/Mono debugging stack traces, let me know if you wish to help)

Found a strange native code stack overflow/rewind problem (bug?) in Mono (OS-X) that causes Mono to go crazy and slow to a snails pace (got dead-locks in native threading queuing at that point), but it only happens in a couple of test282 compliance tests, edge tests for sure and I have not seen it in real-world scripting (yet), but it needs researching and patching.

Getting a handle on what to do with x-plat floating point math differences in the NUnit and test282 tests, these are typical FP x-plat issues, but I am not clear on why x-plat javascript engines produce the same results, where the OS/std library on those platforms produce different results… is there a (float point) math library standard described in the EMCAScript standard that I am overlooking? Is it even worth dealing with, for my usage pattern no, but others?

I'm a git/GitHub guy, but if anyone wishes to help clean on the remaining Mono bugs/issues, I can push these changes to a hg/CodePlex fork.

Here are the current benchmarks and test results:

http://sushihangover.azurewebsites.net/post/Jurassic-(Net-based-JavaScript)-running-under-Mono-1
http://sushihangover.azurewebsites.net/post/Jurassic-(Net-based-JavaScript)-Initial-Mono-Benchmarks2
http://sushihangover.azurewebsites.net/post/Jurassic-(Net-based-JavaScript)-Initial-Mono-Benchmarks-(Part2)1
http://sushihangover.azurewebsites.net/post/Jurassic-(Net-based-JavaScript)-Test262-under-Mono1
Dec 5, 2013 at 5:10 AM
I pushed a branch of my Mono changes to my GitHub account so I not lose them, if interested in checking it out and doing some debugging on the remaining Mono issues, start here:

http://sushihangover.azurewebsites.net/post/jurassic-(Net-based-JavaScript)-Running-under-Mono-pushed-to-my-GitHub-account

-Robert
Coordinator
Dec 7, 2013 at 8:37 AM
Awesome work - I'm a Windows guy myself, but wider cross-platform support is always welcome. By the way, basic IEEE 754 floating point math (add, multiply, square root, etc) should be deterministic across all platforms and languages, since the IEEE spec requires it to be. Where it gets tricky is order of evaluation of operators, converting between single and double precision and intrinsics like sin() and cos(). I did a quick Google search and it seems that generally it is required that you use the same exact compiler version in order to get determinism. Do the cross-platform javascript engines use the same compiler across platforms? If so, that would potentially explain why they don't have this problem.
Dec 7, 2013 at 2:55 PM
Thanks for the info.

Yes, it is the precision of the floating point that causes the 'problem'. While Mono is correct in its CLI implementation, the CLI specification itself allows precision to 80 bit (x87 FPU std). It appears at first pass, that on Windows, .Net sets 53bit precision (64 bit mode) and on OS-X, Mono is 'allowing' the full 80 bit, thus there are rounding issues, i.e.:
  Expected: 1.2345678901234568E+20d
  But was:  1.2345678901234567E+20d

  Expected: "7.7e+101"
  But was:  "7.700000000000002e+101"
At 53 bit precision, Windows/.Net results match the Javascript engines and thus are deterministic.

There are some .Net Math libraries that actually allow the FPU precision used to be controlled, but in a very quick search, all of these are based on native std lib calls that of course do not work on OS-X or *nix:
            Single24Bits    = 0x00020000,
            Double53Bits    = 0x00010000,
            Extended64Bits  = 0x00000000
So, the options here are to either go with a 'soft' Math library within the Mono version of Jurassic, write FPU native calls, link Mono to a math lib that forces 64 bit FPU mode, etc…

Again, this is not a show stopper for the work that I needed Jurassic for, but if others need it, they would need to do some more work in this area.
Oct 16, 2014 at 12:21 PM
Hi,
I see it's been almost a year since the last post on this thread. Just wondering what the status of running Jurassic on OS X is these days? I would like to use Jurassic in a new project, but we can only use it if we can guarantee that it'll work cross platform.
Coordinator
Oct 16, 2014 at 11:02 PM
Jurassic is an open source project I created while I was in-between jobs a few years back. For this kind of project, there are no guarantees.

(I don't have a mac myself, so I can't give you any assurances, sorry)