Re: [Jikesrvm-core] Problem at runtime with a inserted instruction

[Ian R. <ian...@ma...>]

Hi,

there's a lot of special casing of zero in OPT_AssemblerBase. The 
optimizing compiler should never generate accesses to address 0 as the 
simplifier replaces them with explicit traps. It could be that there's a 
problem in OPT_AssemblerBase, we had a thread started on the 18/11/05 
entitled "null_check from Hell" that mentions some things relating to 
this. I also found a problem relating to this in the now closed bug 
#1274081. In the context of that what was happening is that 
OPT_BasicBlock assumes traps end basic blocks, so when the simplifier 
makes a trap it should end the basic block. This, however, breaks the 
outer enumeration that the simplifier is being called from. I wrote a 
patch that stopped this, in particular for the case of simplifying a 
null check. I believe the patch probably didn't make it through as there 
were issues with the assembler with 0 constant operands; it was also 
slightly less optimal than the previous code as it only simplified to 
traps when the instruction was at the end of a basic block (this could 
have been fixed later by recoding the outer enumeration). You may want 
to explore further, you can enable some more of the IR verification in 
OPT_IR.java (try the PARANOID flag). We're not fully verifying 
everything in development builds yet, which is a shame, as some of the 
fixes raised bugs in the system. Verification may be of limited to you 
anyway as the problem is surfacing in the final MIR expansion.

Regards,

Ian

Isabella Thomm wrote:
> Hi,
>
> I think it's something else :-) But thank you anyway. What I posted 
> before, is not the problem, I think... :-/
> I can only guess, because I saw (by coincidence), that I only get this 
> error when I write into address "0", and not,
> when it is another value. Could "0" be misinterpreted by the compiler?
>
> Thx,
> Isabella
>
> Eliot Moss wrote:
>
>> This may be off base, Isabella, since I have not gone back to the 
>> beginning
>> of this thread of conversation, etc.
>>
>> But I am wondering if something like this might be happening. Are you
>> computing an address into an object, which is then getting compiled into
>> the code? And is this a heap object that can move? In such a case, a
>> garbage collection would break things. I am guessing this is not what is
>> happening, but just wanted to observe that such compiled-in addresses 
>> need
>> to be to data that are (a) not in the heap, or (b) in the heap but
>> non-moving and won't be reclaimed by a collector.
>>
>> Best wishes -- Eliot
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through 
>> log files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>> _______________________________________________
>> Jikesrvm-core mailing list
>> Jik...@li...
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>
>>  
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Jikesrvm-core mailing list
> Jik...@li...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core