CompilerException java.lang.RuntimeException: Method code too large! when debugging

[fgiasson]

Since version 0.11.0 and still with 0.12.0 I am often getting this error message when debugging:

CompilerException java.lang.RuntimeException: Method code too large!

Well, the error message is obvious, but I am wondering why it started to happen (never encountered it with version 0.10.0).

I am wondering if this is something new, and what is a function that is too large (how is this defined?).

Also, it will be returned whatever I use #dbg, #break or that instrumentalize the whole function.

Any ideas how I could increase the size supported (if possible), or..?

[Malabarba]

Is this happening consistently? What are the functions like?
I've run into this problem once or twice, but usually on very large functions.

[fgiasson]

@Malabarba yes, consistently with specific (longer) functions. However I am really wondering how is "a long function" defined :)

My functions doesn't appears to be particularly large, except if it includes other things that I am not aware in the calculation of the size.

Also, do you know if this is something that has to do with the latest version or is this something I didn't encounter before?

[Malabarba]

@Malabarba yes, consistently with specific (longer) functions. However I am really wondering how is "a long function" defined :)

I think only The Source could tell us that. :-)

My functions doesn't appears to be particularly large, except if it includes other things that I am not aware in the calculation of the size.

Macros could make functions much larger than they appear. But it's also unclear to me exactly when that happens.

Also, do you know if this is something that has to do with the latest version or is this something I didn't encounter before?

No, it's always been around. But it's possible that the current version has made the problem worse.

[fgiasson]

@Malabarba ok good to know.

Do you know what what returns this exception?

[fgiasson]

@Malabarba tell me if I am wrong, but probably that the debugger is getting the function's code, and then maybe add stuff to it and then compile it for debugging purposes (this is probably the instrumentalization process).

I can buy that this may happen when instrumentalizing relatively large functions. However, I am wondering why this would happen when using a #break or a #dbg in a small portion of the code. Probably because it has to add all the stuff to that function and to compile it the same way anyway?

Just a few thoughts, but I didn't look at the Cider code yet.

[Malabarba]

Yeah, it's really strange that it happens with #break. Break only adds a single macro to the function.
However, the instrumentation process also adds a ton of metadata to everything, so maybe that's the cause.

Perhaps we can solve this by clearing some of the metadata before evaluation.

[fgiasson]

@Malabarba Yeah this is what I thought about #break but obviously there seems to be an issue with it. If we can get this to work with #break and maybe with #dbg for small subsets, then I don't think this issue would be a real one. But not having any of these options comes an issue in my view.

Perhaps we can solve this by clearing some of the metadata before evaluation.

You mean, when doing the instrumentation? I don't think it would even be necessary if we can get #break to work (or maybe it is how to fix it :) )

[Malabarba]

Yes, that's what I meant. Clearing the metadata might be a way to fix #break. I'll cook up a snippet and ask you to run it, is that ok?

[fgiasson]

@Malabarba sure any time! Thanks.

[fgiasson]

@Malabarba any news on this?

[Malabarba]

Right, sorry.
Try evaluating this on a repl:

(in-ns cider.nrepl.middleware.debug)
(defmacro breakpoint-implementation [form {:keys [coor]} original-form]
  (let [val-form (cider.nrepl.middleware.util.meta/strip-meta
                  (if (looks-step-innable? form)
                    (let [[fn-sym & args] form]
                      ;; Evaluate args first, delaying the decision of whether or
                      ;; not to step in until the last possible moment.
                      `(let [args# [~@args]
                             step-in?# (step-in? (var ~fn-sym) ~coor)]
                         (apply (if step-in?#
                                  (::instrumented (meta (var ~fn-sym)))
                                  ~fn-sym)
                                args#)))
                    form))]
    `(let [val# ~val-form]
       (cond
         (skip-breaks? ~coor) val#
         ;; The length of `coor` is a good indicator of current code
         ;; depth.
         (= (:mode @*skip-breaks*) :trace)
         (do (print-step-indented ~(count coor) '~(cider.nrepl.middleware.util.meta/strip-meta original-form) val#)
             val#)
         ;; Nothing special. Here's the actual breakpoint logic.
         :else                (->> (pr-short val#)
                                   (assoc *extras* :debug-value)
                                   (read-debug-command val#))))))

See if it solves the issue.

[expez]

Method code too large...

[fgiasson]

@Malabarba it seems that it helped fixing the issue for one of my function, but I can still experience it in others when using #break

[expez]

I experience this problem on functions containing resource definitions for use with liberator. They are way too long in several places, but no one has had the time to break them up yet.

[fgiasson]

@Malabarba did you have some more time to look into this issue?

There is another thing I was wondering with the latest version: is it normal that the function's name is not highlighted anymore with #break or #dbg but only when everything is instrumented? (it used to work, and was pretty handle to have the name of the function highlighted in any situation).

[Malabarba]

@fgiasson Sorry, haven't looked further into it yet.

Yes, it's normal that this happens. It's a bit of an unfortunate consequence of a recent refactor. I'm not sure how to fix it though. =/

[fgiasson]

Hi @Malabarba

Ok thanks for looking, will cross my fingers that you can think of something to improve the situation :)

Thanks

Fred

[ftravers]

Having same issue with om.next/denormalize* :)

[fgiasson]

@ftravers I am not sure if @Malabarba did improve the situation with the latest version, but it happens less often now. The only work around you have when this happens is to refactor your code to create multiple functions (it is these functions that you debug) which may not be a bad thing. But if it doesn't make sense, then you do it anyway just for debugging purposes and revert the changes after.

[vspinu]

Another workaround is to insert #break explicitly, which makes me think that #bstart and #bend would be useful to instrument specific portions of the code. Also C-u C-M-x could instrument only a portion of the code if the region is active. Shall I open a feature request for these?

[vspinu]

I have looked at it a bit closer and the problem stems from the instrumentation macros. I start with 70 lines of code which instrumented and macroexpanded (but before the expansion of breakpoint-if-interesting) produces 1700 lines. Once breakpoint-if-interesting is expanded I get 18k lines of code on which eval blows. If I replace instrument-if-interesting with a simpler macro it compiles just fine.