bugKawa - Bugs: bug #18790, mis-compilation of invoke-special


bug #18790: mis-compilation of invoke-special

Submitted by:  tk <huh>
Submitted on:  Mon 15 Jan 2007 10:07:12 PM UTC  
Category: Code generationSeverity: 3 - Normal
Item Group: Unexpected resultStatus: Need Info
Privacy: PublicAssigned to: Per Bothner <bothner>
Open/Closed: Open

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Sun 18 Mar 2007 11:34:57 AM UTC, comment #8:

for the record...

sorry for not responding to this through bugzilla, savannah seems to be having database problems.

I agree with your approach to compilation, preferring that the compiler have sufficient inter-module information to allow it to produce the best possible code. after all, the high quality of code generation is one of Kawa's strongest points, and it's clear why one needs static name resolution to do this.

On the other hand, late dynamic binding is a characteristic of scheme that I thoroughly rely on. I agree with your statements about preferring the use of require vs load, but I wouldn't want to see the functionality of compile-file/load go away.

I generally structure my applications so that performance-critical calling patterns are within the same module, which is somewhat inconvenient modularity-wise, but it makes it fairly clear where the boundaries for making dynamic updates are. if you're inclined to replace compile-file/load with some other mechanism, that's fine, as long as Kawa retains its dynamic qualities (without resorting to the define-variable approach).

I've also used the interface/abstract class approach you mentioned, which is effective but rather awkward. bottom line for me is that I'd be bummed to see load deprecated.

tk <huh>
Wed 07 Mar 2007 08:04:22 AM UTC, comment #7:

The question I have is how a library is "imported" into your application. You you load a library, you import a bunch of definitions into the "top-level scope". The module that does the load has to have some expectations about what it imports. Can the importing modules the names (at least) of imported definitions - at compile time?

One mechanism is to use an interface or abstract class: The
importing module assumes the new class implements some interface or extends some class.

We can also just use variable names. For example 'define-variable'
will allow references names from the dynamic scope while otherwise using static bindings (with error messages when names of undefined). However, that isn't the ideal solution.

Of course you may not care compilability and static name resolution, but I think it is good to aim for it.

Per Bothner <bothner>
Project AdministratorIn charge of this item.
Tue 06 Mar 2007 07:18:52 PM UTC, comment #6:

the functionality of compile-file/load that my applications and development environment rely on is the ability to compile/load/reload code, both within a single VM and across multiple VMs.

there's undoubtedly tension between java-oriented and scheme-oriented compilation approaches. if you prefer some alternative to compile-file/load, I'm fine with that as long as there's a way to preserve late-binding behavior.

tk <huh>
Fri 02 Mar 2007 08:15:19 PM UTC, comment #5:

The problem isn't so much compile-file but load. So the answer depends on what you're using compile-file for.

If you want to compile an file so you can then load it in the same VM, and if the path is known at compile-time, then use:
(require PATH).

If you want to compile a file for use in a later VM, something like compile-file is ok, but we want to add the zip-file to the classpath and require it. I could implement some syntax that does that automatically.

Otherwise, it seems like you're essentially doing eval - which you know is Evil ... But a contrained eval is Ok.

Bottom line: I think I need to understand what you're useing compile-file for.

Per Bothner <bothner>
Project AdministratorIn charge of this item.
Fri 02 Mar 2007 07:31:48 PM UTC, comment #4:

ok -- so what is the alternative to compile-file? (apart from invoking the compiler separately, which doesn't really address the need to compile files within a kawa runtime environment).

tk <huh>
Fri 02 Mar 2007 05:00:09 PM UTC, comment #3:

I'll take a look at compile-file. But I should point out that I don't recommend compile-file, not so much for itself, but because it is designed to use with load. And load is quite problematical, since it is a function and thus injects top-level definitions at run-time rather than compile-time. I.e. it is incompatible with static name resolution.

I recommend require rather than load. You can now do:
(require "file-name")

I'm in the process of re-thinking how to handle top-level definitions in general and load in particular.

Note that R6RS does not have load, and only has a limited (non-definition) eval.

Per Bothner <bothner>
Project AdministratorIn charge of this item.
Fri 02 Mar 2007 04:24:57 PM UTC, comment #2:

thanks, making this a compile-time error sounds like the right response.

one question about the compiler diagnostics -- I have these warnings turned on, and they are indeed useful. however, I generally compile code with compile-file, in which case the warnings aren't issued (I can see the compile warnings by loading the source files). is there a reason that compile-file doesn't display these diagnostics?

tk <huh>
Wed 28 Feb 2007 11:04:19 PM UTC, comment #1:

I changed Invoke.inline so that in the invoke-special case, if it doesn't find a unique method it emits an error. This is similar to compiling with --warn-invoke-unknown-method --warn-as-error just for invoke-special.

Does that help?

By the way, you might consider always compiling with --warn-undefined-variable --warn-invoke-unknown-method --warn-as-error. These options catch a lot of errors, both ones that causes erroneous results and those that hurt performance. There are mechanisms for locally fine-tuning the errors/warnings if you need to.

Per Bothner <bothner>
Project AdministratorIn charge of this item.
Mon 15 Jan 2007 10:07:12 PM UTC, original submission:

Under what circumstances might the Kawa compiler fail to be able to
generate inline code for invoke-special?
In some cases the compiler is apparently failing to resolve
the call to invoke-special (to call a superclass method),
so the code fails at runtime in Invoke.applyN trying
to do a non-static invoke (i.e., kind is '*', it doesn't
even look like an incorrect runtime invocation of invoke-special).
The actual runtime error is a null-pointer exception in
Invoke.applyN as arg0 is null.

would appreciate advice on where to look in the compiler to track
this down -- so far I can't isolate a test case. In most analogous
circumstances the code generation works fine.

svn revision 5848

tk <huh>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by bothner (Posted a comment)
  • -unavailable- added by huh (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 28 Feb 2007 11:04:19 PM UTCbothnerStatusNone=>Need Info
      Assigned toNone=>bothner

    Back to the top

    Powered by Savane 3.1-cleanup