expose the bytecode in cli

[gengjiawen]

This will make debug and performance more easily

v8

MonkeyLang

[bnoordhuis]

You already can, kind of - it's the -D1 flag to qjs (JS_SetDumpFlags in quickjs.h)

[gengjiawen]

You already can, kind of - it's the -D1 flag to qjs (JS_SetDumpFlags in quickjs.h)

qjs -D1 t2.js no output on my side (version: ng 0.8.0). I am directly use the release binary, should I build my own or something I miss ?

[bnoordhuis]

You'll need a debug build (no -DNDEBUG)

[gengjiawen]

Any chance this is moves into production build by default. Consider it's under a flag, won't drag down perf in normal mode.

[saghul]

Some of the debug flags may have an impact if enabled in release builds.

[bnoordhuis]

Any chance this is moves into production build by default. Consider it's under a flag, won't drag down perf in normal mode.

Probably not because it embiggens the library by quite a bit. One of quickjs's design goals is being able to run in constrained environments so we're mindful of size.

[chqrlie]

Enabling all the trace/dump facilities does cause a slow down even if the flags are not enabled via a command line option or a call to JS_SetDumpFlags(). PR #770 is underway to control these features and expose the flags, but we should probably investigate an intermediary approach where selected features are compiled that do not affect performance but give the developper access to the byte code: the ability to output the byte code or more generally give enough access for debugging should be available separately.

[gengjiawen]

Probably not because it embiggens the library by quite a bit. One of quickjs's design goals is being able to run in constrained environments so we're mindful of size.

In real cases in embedder we can always turn it off. But we need perf insight during development, which is my real case.

[saghul]

Can't you use a Debug build for that?

[gengjiawen]

Can't you use a Debug build for that?

That's what I do for now. But I want this make it to the default build. Sometimes I want to do the diff with latest qjs binary in release page.

[saghul]

We would need to separate the bytecode dumping logic from the other dump flags I guess...

[gengjiawen]

We would need to separate the bytecode dumping logic from the other dump flags I guess...

How should we push this forward. Is currently turn on ENABLE_DUMPS in release mode can be considered ?

[saghul]

No because that turns on some other stuff that is too impactful.

Perhaps the bytecode dumping ifdefs can simply go away.

Feel free to give it a try in a PR and we can take it from there.

[gengjiawen]

I deployed a qjs debug build on http://k2.gengjiawen.com:8001/quickjs

One thing I notice is that

• it lacks bytecode length like v8 have
• have a extra eval in final bytecode

[chqrlie]

The bytecode dumping routines and the corresponding tables should be controlled by a specific define in addition to NDEBUG. eg:

     js_free(ctx, fd);
 }

-#ifdef ENABLE_DUMPS // JS_DUMP_BYTECODE_*
+#if defined ENABLE_DUMPS || defined JS_DUMP_BYTECODE
 static const char *skip_lines(const char *p, int n) {
     while (p && n-- > 0 && *p) {

[saghul]

I deployed a qjs debug build on http://k2.gengjiawen.com:8001/quickjs

Nice!

• it lacks bytecode length like v8 have

I guess that is engine specific?

• have a extra eval in final bytecode

IIRC in QuickJS it all begins with eval, hence you see it there.

[gengjiawen]

it lacks bytecode length like v8 have

I am thinking adding this will make this optimisation more obvious #752

[bnoordhuis]

it lacks bytecode length like v8 have

Just so we're on the same page, what exactly are you referring here? Length of individual bytecodes, total length, something else?

[gengjiawen]

Just so we're on the same page, what exactly are you referring here? Length of individual bytecodes, total length, something else?

total Bytecode length. I believe means this the same too when v8 used with flags --print-bytecode

[bnoordhuis]

#929

[gengjiawen]

@bnoordhuis can you reopen this, core of this still not implemented.

[bnoordhuis]

What else is left? As I mentioned, I don't plan on enabling it by default.

[gengjiawen]

What else is left? As I mentioned, I don't plan on enabling it by default.

All major engines like jsc and v8 provide it in release model. The increase in size is really small I think.

[bnoordhuis]

I'm open to being convinced by numbers but consider how V8 and JSC are centimegabyte monsters so an extra 50-100k is nothing to them, whereas qjs is a few hundred kilobytes in total.

[matthewmueller]

Thanks for the earlier context, I was able to print out the opcodes with:

make debug
./build/qjs -D1 add.js

I also think it would be nice to be able to do this with the production build though. What about adding it to qjsc instead of qjs?

[bnoordhuis]

I'd be okay with enabling bytecode dumping in the release binaries, where I drew the line is at enabling it by default in library builds; those should stay small. Go ahead if you want to open a pull request for the former.