[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-discuss
Subject:    Re: Java class file verification
From:       John Bergin <john.bergin () gmail ! com>
Date:       2015-01-15 13:12:19
Message-ID: 54B7BCB3.3000100 () gmail ! com
[Download RAW message or body]

Hi Andrew. I'm glad to hear you also have a similar
interpretation of the spec. And it does make sense
like you said that the JVM should not punish Java
class files that have invalid start_pc values potentially
due to instrumentation which is commonly done.

Thanks again for you response.

Kind regards,
John.

On 15/01/15 12:29, Andrew Dinn wrote:
> On 14/01/15 23:01, John Bergin wrote:
>> To me this means the start_pc value must be the index of an opcode --
>> the opcode's starting code-array offset only, and not an interval for
>> the size of the opcode.
>>
>> But maybe I am interpreting the specification incorrectly.
> That's how I read it i.e. a start pc index into the middle of a
> multibyte bytecode instruction sequence (i.e. which address a bytecode
> operand rather than the bytecode operator itself) is not valid according
> to the spec.
>
> Your summary above omits the extra requirement that the end pc index is
> likewise constrained modulo the one special case that it can be the
> first index beyond the end of the array.
>
> However, I'll note that my experience over the last 6 years with Byteman
> is that quite a few classfile transformer programs (both offline and
> online) fail to update these indexes when they rewrite bytecode,
> frequently leaving indices addressing instructuon operands ... and,
> clearly, these programs were not punished for it by the JVM class file
> checking routines or else they would have had to correct the omission.
> That's been my experience on JDK5/6/7. I have not seen examples when
> running on 8 but I don't believe it is any different.
>
> regards,
>
>
> Andrew Dinn
> -----------
>

[prev in list] [next in list] [prev in thread] [next in thread]