harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm][jit] VM-JIT interface extension
Date Mon, 18 Dec 2006 15:40:17 GMT
On 12/18/06, Pavel Pervov <pmcfirst@gmail.com> wrote:
> As I understand OPT pipeline, it was NOT originally designed to return
> compilation error from within its internals. But now I see it being a
> requirement.

This is not true. OPT pipeline is designed to return JIT_Failure if
something broken. But it's true that we can have a bug here :)

In the example in JIRA we have this stack:

  harmonyvm.dll!TypeDesc::load_type_desc() Line 135 + 0x16 C++
  harmonyvm.dll!type_info_get_class(TypeDesc * tih=0x095ff2f8) Line 2013 +
0x8 C++
* typeHandle=0x095ff2f8, bool isManagedPointer=false) Line 520 + 0xc C++
  jitrino.dll!Jitrino::DrlVMMethodSignatureDesc::getReturnType() Line 331
  jitrino.dll!Jitrino::JavaByteCodeTranslator::invokeinterface(unsigned int
constPoolIndex=489, unsigned int count=1) Line 2101 + 0xd C++
unsigned char * byteCodes=0x0470c5f8, unsigned int off=31) Line 617 + 0x36
* cb=0x0012739c) Line 70 + 0x1a C++

and the body JavaByteCodeTranslator::invokeinterface has special handling
for this situation:

        if (returnType == NULL) {
            // This means that it was not resolved successfully but it can
be resolved later
            // inside the callee (with some "magic" custom class loader for
            // Or respective exception will be thrown there (in the callee)
at the attempt to create (new)
            // an object of unresolved type
            returnType = typeManager.getNullObjectType();

So the method will be compiled and passed to VM.
Are you proposing to reject compilation here if some VM flag (exception
flag) is set?

Mikhail Fursov

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message