[qt] Add function to check if QtWebKit was compiled with the JSC JIT
Created attachment 92249 [details] Patch
JIT is a property of the ScriptEngine. Perhaps it make more sense to expose this functionality in the QtScript API. Can you share key use-cases you had in mind ?
(In reply to comment #2) > JIT is a property of the ScriptEngine. Perhaps it make more sense to expose this functionality in the QtScript API. > > Can you share key use-cases you had in mind ? Good point. The use case is mostly to verify the Qt buildsystem, mostly the 'auto detection'. There is one regression in t 4.6 to 4.7 in regard to enabling the JIT by default.
Why should any callers care what the underlying interpreter uses?
(In reply to comment #4) > Why should any callers care what the underlying interpreter uses? Constructed and bad example: If one would like to disable executable memory allocations.. one could check if the WebKit will need it and not disable it. The real and boring motivation: WebKit gets copied into src/3rdparty/webkit in Qt. When configuring Qt (and webkit as part of it) one has two javascript options: -no-javascript-jit . Do not build the JavaScriptCore JIT compiler. + -javascript-jit .... Build the JavaScriptCore JIT compiler. The default option will leave enabling the JIT to WebKit (wtf/Platform.h) and there was a 'regression' (Qt 4.6 had it enabled for MIPS, Qt 4.7 'accidently' disabled). So having an option to see the configuration of the compiled QtWebKit can be helpful to write a unit test (so maybe I should return a String with all ENABLEs and FEATUREs or such). So the goal right now is to have a test that the default compilation of Qt has the JIT enabled for x86, x86-64, ARM and MIPS. The underlying assumption is that on a release (a stable branch) that a JIT will stay faster than the interpreter. For the development of trunk I am going to host a MIPS buildbot and run performance tests (they should spot a change in the default configuration as well). So it would be interesting if you think it is worth of having 'introspection' on the build configuration and if yes have an opinion on how to achieve it
(In reply to comment #2) > JIT is a property of the ScriptEngine. Perhaps it make more sense to expose this functionality in the QtScript API. > > Can you share key use-cases you had in mind ? I have to agree with that.
(In reply to comment #5) > The default option will leave enabling the JIT to WebKit (wtf/Platform.h) and there was a 'regression' (Qt 4.6 had it enabled for MIPS, Qt 4.7 'accidently' disabled). So having an option to see the configuration of the compiled QtWebKit can be helpful to write a unit test (so maybe I should return a String with all ENABLEs and FEATUREs or such). So the goal right now is to have a test that the default compilation of Qt has the JIT enabled for x86, x86-64, ARM and MIPS. Holger, this looks like could be solved at build system level. The build system could generate a file with a function (not public API) that returns all the build parameters used in compilation so you can check them in your tests. What do you think? I don't think is good to solve the issue separatedly just for the JIT case.
Sure, being able to do /lib/ld-linux.so.2 /usr/lib/libQtCore.so.4.7.2 for QtWebKit would be nice. But then it would be tied to ELF. The other basic thing here is, I want to ask the artefact and not what the buildsystem thinks about it (e.g. I might only have the artefact).
(In reply to comment #8) > Sure, being able to do /lib/ld-linux.so.2 /usr/lib/libQtCore.so.4.7.2 for QtWebKit would be nice. But then it would be tied to ELF. The other basic thing here is, I want to ask the artefact and not what the buildsystem thinks about it (e.g. I might only have the artefact). Got it. Note that by "not public API", I meant marking it as \internal -- since it's not something a typical user of QtWebKit is expected to use. Seems to be more about verification of the artifact, at least for now. I was suggesting (inspired by your comment #5) that the build system could produce the function for you that return all the build parameters relevant. Of course just the configure line will not cut in your case. What do you think about something like "bool qtWebKitHasFeature(const char*)" instead? I just think is strange to have a function only for this specific feature. What if later we need to test the artifact for other features too?
I have to say, like the other, I don't think it is a good idea to expose that. I can hardly see what kind of decision would be taken at runtime based on the function (apart from bugs workaround).
Comment on attachment 92249 [details] Patch The consensus of the bug seems to be negative.
=== Bulk closing of Qt bugs === If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary. If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.