477253 - js shell: exposing compile-time options like JS_THREADSAFE or JS_TRACER

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, enhancement)

Description

[Igor Bukanov]

Currently it is not possible to detect from a script if the js shell was compiled with JS_TRACER since options("jit") works even when !JS_TRACER. To address this and other issues of reliable detection of compile-time options I suggest to provide a function like hasFeature(feature_name) which returns true when the shell is compiler with JS_FEATURE_NAME macro.

Comment 1

[Bob Clary [:bc] (inactive)]

It would be good to enable something for the browser as well.

Comment 2

[Igor Bukanov]

(In reply to comment #1)
> It would be good to enable something for the browser as well.

One possibility is to include "jit" in navigator.userAgent. Or do you mean some privileged function?

Comment 3

[Bob Clary [:bc] (inactive)]

I doubt a change to the userAgent would fly. 

Do you mean by privileged, something requiring chrome privileges? If that is necessary, I could live with it. I already use extra privileges to turn jit on and off in the browser. But I'm not sure why we would need to restrict it.

Another alternative might be throwing an exception when trying to set an option which is not supported. This would require more interaction with the rest of the browser though.

How about a readonly object with an enumerable property for each JS_FEATURE_NAME?

Comment 4

[Brendan Eich [:brendan]]

No userAgent changes would be appropriate, for several reasons (attractive nuisance leading web devs to work around bugs rather than report them; UA is too long already; UA is not for such fine-grained feature encoding).

The window.options object could reflect in a readonly sense certain options. Would this break symmetry with the pref names?

/be

Comment 5

[Benjamin Smedberg]

I don't think we should do this for the browser unless there's a really compelling reason why we should.

Comment 6

[Bob Clary [:bc] (inactive)]

The only reason to support this in the browser would be to enable the tests to not report failures if the feature is not supported. Whether that is compelling enough or not, I'll leave to others.

Comment 7

[Mike Shaver (:shaver emeritus)]

Agreed, we do not want content authors conditioning on specific things like that.  Especially since we want to change some of the settings like JS_THREADSAFE in the near future!

Comment 8

[Bob Clary [:bc] (inactive)]

I suppose Igor's original intention of making this only accessible to privileged code makes more sense in that context. Would it be acceptable to require chrome privileges to access the information?

Comment 9

[Benjamin Smedberg]

This bug was originally about the JS shell. I'm not sure why we need this in the JS shell (maybe for testing?), but I still don't see why chrome or content would need it in the browser.

Comment 10

[Bob Clary [:bc] (inactive)]

The original motivation is for tests which perform comparisons between jit and non jit code looking for performance issues. So, yes for testing. I would want it in the browser for the same reason.

Comment 11

[Mike Shaver (:shaver emeritus)]

Can we just put them in a "JIT tests" group, and people can select them according to their environment?

Comment 12

[Bob Clary [:bc] (inactive)]

Currently, I place jit related assertion and correctness tests where they would have lived prior to the jit so that 1.9.0 gets additional coverage even though it doesn't support jit. 

For the jit performance sensitive tests, I place them in js1_8_1/trace/ so that 1.9.0 and earlier can easily ignore them. The problem Igor is trying to solve is for 64 bit which does not support the jit and which can fail when comparing the jit and non jit performance timings. 64bit could exclude js1_8_1/trace and not see these problems, yes.

Comment 13

[Igor Bukanov]

(In reply to comment #11)
> Can we just put them in a "JIT tests" group, and people can select them
> according to their environment?

I like to run those tests even when jit is not enabled (64 bit Linux). Surely they no longer assert that jited code is faster but they do test against segfaults providing a coverage for paths in the interpreter that may not explored in other tests.

Comment 14

[Brendan Eich [:brendan]]

We should run the tests with and without jit. If we must know whether the jit is on for a given run, can we require the suite to tell us? I.e., don't put the tests under a "JIT tests" group, but do run them both ways and have something that the test harness sets tell the difference? A global variable, say?

/be

Comment 15

[Bob Clary [:bc] (inactive)]

I do run the tests with and without jit although for some specific tests for assertions or correctness I wrap the actual test in a jit(true)... jit(false), which effectively always runs the test with jit on. I can remove those jit calls if that is what is desired but that will not resolve the issue Igor cares about.

For the particular tests in js1_8_1/trace that are causing Igor problems, they depend on running a section of code with jit off and then with jit on and then comparing the timings.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Is this still wanted?

Comment 17

[André Bargull [:anba]]

JS_THREADSAFE was removed in bug 1031529, so this bug is probably no longer actionable, therefore closing as INCOMPLETE.