harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikhail Loenko <mloe...@gmail.com>
Subject Re: [drlvm] Loading 50:0 format class files
Date Fri, 04 Sep 2009 11:32:39 GMT
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

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.

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
>
>

Mime
View raw message