harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [drlvm] Loading 50:0 format class files
Date Fri, 04 Sep 2009 12:02:06 GMT
Mikhail Loenko wrote:
> Hi!
>
> If you are talking about this peace of code:
>
> #ifndef _NDEBUG
>         vf_recompute_stackmaptable(method, &context6.substitution,
> error, classwide.class_constraints);
>
>         result = context6.verify_method(method);
>         if (result != VF_OK) {
>             vf_create_error_message(method, context6, error);
>         }
>         tc_free(context6.substitution);
>         context6.substitution = NULL;
> #endif
>   

Yes, that's the piece of code.

> then it should not be executed. it was written for debugging purposes
> when I developed recompute stack map functionality.
>
> (recompute stack map functionality populates modified on the fly class
> file with correct stack map attributes)
>
> This peace of code fails when original class file has 6.0 version
> while it can't be verified with Java6 rules.
>
> Just comment it out or even remove it.
>   

Brilliant, thanks Mikhail! Ill remove that block altogether.

Regards,
Oliver

> Thanks,
> Mikhail
>
>
>
> 2009/9/4 Oliver Deakin <oliver.deakin@googlemail.com>:
>   
>> Alexey Varlamov wrote:
>>     
>>>> The changes that went into JSR202 include:
>>>>  - split verifier support
>>>>  - increase various size limits
>>>>  - adding support for class literals
>>>>  - minor changes to support Java language changes
>>>>
>>>> I'm assuming that the problem in DRLVM is the loading on class literals.
>>>>
>>>>         
>>> Actually the class literals were incorporated in Java 5 (v49.0), as
>>> well as other minor features for language support. AFAIK there are no
>>> Java language changes between Java 5 and 6.
>>> DRLVM does support these features, so the evil should be somewhere else.
>>>
>>>       
>> Hi Alexey,
>>
>> I have replied about this issue in another part of this thread [1]. It seems
>> there is a problem with some code intended for debug in the verifier. After
>> the initial java 6 method verify, the debug code then tries to recompute the
>> stack map table (which only seems to include Java 5 references oddly) and
>> then verify the method again, and this is where we fail. Without the debug
>> code in place the verification completes successfully.
>>
>> Any ideas why the failure is occurring or why we would want to do the second
>> verify in debug mode after recomputing the stack map table?
>>
>> Regards,
>> Oliver
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/harmony-dev/200909.mbox/%3c4A9FD5E6.6060701@googlemail.com%3e
>>
>>     
>>> [snip]
>>>
>>>       
>>>> I'm happy to keep testing, and if we can make progress quickly then
>>>> let's press ahead, but otherwise let's open all the code and give the
>>>> 6.0 stream a bit more attention before attempting the 6.0M1 again.
>>>>
>>>>         
>>> Right decision is already taken ;)
>>>
>>> --
>>> Regards,
>>> Alexey
>>>
>>>
>>>       
>>>> Regards,
>>>> Tim
>>>>
>>>>
>>>>
>>>>         
>>>       
>> --
>> Oliver Deakin
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>> PO6 3AU
>>
>>
>>     
>
>   

-- 
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Mime
View raw message