New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable -g and OCAMLRUNPARAM=b by default #6728
Comments
Comment author: @damiendoligez While I agree that no one should care much about the size increase, we have many users who do care a lot about performance. In any case, if we enable backtraces by default, we'll have to change the parsing of OCAMLRUNPARAM to provide a syntax for disabling backtraces. |
Comment author: @whitequark I do agree, hence the note on raise_notrace. And if the backtraces are not dynamically necessary, the debug information is not read at all, so just always enabling -g would be a zero-cost change. OCAMLRUNPARAM=b=0? |
Comment author: @lpw25 There would definitely need to be a -no-g option (with a better name than that), manually setting OCAMLRUNPARAM is not a viable alternative. |
Comment author: @damiendoligez Note: the |
I know changing defaults is contentious but I often see people having a lack of stacktraces when they use the toplevel which is a bit sad. I have an If people still worry too much making |
Sorry to insist with that. But since I released down I get crash reports from people who as far as I know have been programming in OCaml from quite some time. It's quite consistent: no stack trace which I find really silly. I'll gladly make a PR that does the above if I get an indication it will be merged. |
If you force a call to FWIW, I personally agree that users should get backtraces "by default":
|
It can of course be made conditional on consulting the variable. But if people are willing to change the global default I'm all for it. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Still an issue. |
Willing to work on that one. Am I correct that we are actually discussing two slightly independent If |
Note: I think that we could have |
Note that I think most build system out there do add a The actual problem is rather the runtime system default – i.e. that you need to specify |
Yes, so we would accept |
Daniel Bünzli (2020/08/31 03:14 -0700):
Note that I think most build system out there do add a `-g` by default (or make it easy to do so) *now*.
The actual problem is rather the runtime system default (i.e. that you
need to specify `OCAMLRUNPARAM=b`) to have them.
By "them" you mean the backtraces, right?
|
Yes. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Giving all this a second thought. If I understand things correctly, what
we are discussing is what we should use as default options for the
compiler and runtime.
Rather than discussing this, wouldn't it be better to provide a
generic mechanism that would let users specify the options they want as
defaults, e.g. at compiler configure time or, if that's not flexible
enough, at compiler / program run time?
For example, we could have options like
`--with-compiler-default-flags=` for options that apply to both
compilers, ocamlc/ocamlopt-default-flags, toplevel-default-flags,
whatever.
What do you think?
|
No. Good defaults is what we need, not more configurability. |
@dbuenzli I think that somewhere above you mentioned the toplevel specifically. Would you be in favour of a move to systematically record backtraces in the toplevel (and keep discussing the default for compiled programs) ? |
Why not, but if people obsessed by speed like JaneStreet set it by default (according to this comment on discuss). Can't we safely bet the performance hit is too minimal to consider ? |
My sense from the discussion is that there seems to be a consensus in favour of changing the default everywhere. As far as I can see the only thing that needs to be added beyond that is the Furthermore, the 5.0 release seems like a good point at which to make this change. |
That's not even really necessary, the only default that really needs to be changed is |
See #11282 |
Daniel Bünzli (2022/05/27 08:32 -0700):
> Rather than discussing this, wouldn't it be better to provide a generic mechanism that would let users specify the options they want as defaults, e.g. at compiler configure time or, if that's not flexible enough, at compiler / program run time?
No. Good defaults is what we need, not more configurability.
I'd say, debugging options enabled by default and a way in configure to
disable them. Would that be a satisfactory compromise?
|
Nicolás Ojeda Bär (2022/05/27 10:17 -0700):
My sense from the discussion is that there seems to be a consensus in
favour of changing the default everywhere. As far as I can see the
only thing that needs to be added beyond that is the `-no-g` flag.
Other improvements can be left for later.
Would it make sense to couple OCaml's `-g` with the C compiler's one and
have both enabled by default and a configure opiton to turn both of them
off simultaneously? That's how I planned to do things, one day.
Furthermore, the 5.0 release seems like a good point at which to make
this change.
Yes
|
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Still relevant. And please disable the bot already. |
Original bug ID: 6728
Reporter: @whitequark
Status: acknowledged (set by @damiendoligez on 2015-01-09T17:05:06Z)
Resolution: open
Priority: normal
Severity: feature
Category: compiler driver
Related to: #5855 #6238
Monitored by: @ygrek @hcarty @dbuenzli @yakobowski
Bug description
The size hit of -g is insignificant; a raw opam init checkout (not even any compilers or packages installed) is 60M, and a dozen packages blows it up to 500M. I haven't seen anyone complain.
The fact that -g enables several things unrelated to backtraces (see #6238) should be still addressed.
The rationale for enabling OCAMLRUNPARAM=b is well described in #5855. Additionally:
Not only most OCaml programs are unaffected by the slight performance hit due to collection of backtraces, but also since after 4.02, raise_notrace is available. I think it's time to stop caring about the performance hit at all. The code which require fast exceptions can (and should) well have them with raise_notrace.
The text was updated successfully, but these errors were encountered: