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

 
 

bug #18790: mis-compilation of invoke-special

Submitter:  tk <huh>
Submitted:  Mon 15 Jan 2007 10:07:12 PM UTC
   
 
Category:  Code generation Severity:  3 - Normal
Item Group:  Unexpected result Status:  Need Info
Privacy:  Public Assigned to:  bothner
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group administrator
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>
Group administrator
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>
Group administrator
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>
Group administrator
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 Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-02-28 bothner StatusNone Need Info
        Assigned toNone bothner

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code