[aarch64-port-dev ] assertion failure bcp doesn't belong to this method

[D.Sturm]

i) yep that's the format I used

ii) tried with both 12 and 16 offsets

iii) Graal hasn't compiled anything itself because it's still bootstrapping
itself at that stage (to make this clear: the compiler is written in Java
and we fail while interpreting some of the bootstrap java classes it needs)
- but I did put print statements at all the points where Hotspot calls into
it just to be on the safe side. So the problem must be on the hotspot side
in some of the stubs or adapters I think. This is actually the confusing
part to me: While stepping through a few loops of the offending loop in the
simulator it works perfectly fine, but when I let it continue the loop
after removing the breakpoint it fails. So there must be some kind of
interaction after some specific loop count, the question is just what
exactly. I guess the next point is to see what is begin called in src/share
when something should be compiled and check if the problem isn't there.
Maybe it expects graal to compile some code which it obviously can't at
this stage and gets confused there.

iv) good to know for future reference as soon as the basic problems are
worked out.

> Well, hope the above helps.
Very much appreciated!

regards,
Daniel

On 19 February 2014 17:10, Andrew Dinn <adinn at redhat.com> wrote:

> On 19/02/14 14:08, D.Sturm wrote:
> > Thank you very much for the pointers, they proved very helpful.
> >
> > I stepped through the code (ZoneFileInfo calling readUTF on a
> > DataInputStream) and it works fine in the interpreter, so I guess this
> > means it fails the first time it tries to compile the method or does
> > some other special magic in the background. I used simbreakreloc for
> > each of the methods on the callstack (although since I run with OSR
> > disabled I'd expect this to only happen for DataInputStream.readUTF) but
> > none trigger a break. simcompiled lists only adapter methods and one
> > method from the Graal classes (the only java entry), but no new entries
> > appear between me checking in the interpreter and after the assertion
> > has been triggered.
>
> i) how did you specify the name of the method to break?
>
> You need to provide the name with fully package qualified class, method
> and signature e.g.
>
> simbreakreloc "java.lang.Object.<init>()V" 24
>
> ii) did you provide an offset like 16 or 24?
>
> iii) are you sure any method has actually been compiled -- it is not
> always clear when C2 will kick in and compile something.
>
> iv) it may be that the Graal compiler is not compiling code or is
> installing the code via a different path. we hooked into the points
> where native method instances and stubs are created/installed. look for
> calls to simulator method notifyCompile in the hotspot/src/share tree
> and see if it is actually being called. if it is step through and check
> that the methods are being entered into the compiled method table. This
> will also allow you to check the syntax used to name the method.
>
> Also check that notifyRelocate is being called when the method is moved
> into is executable code buffer (as opposed to the temporary buffer used
> to generate the code). Break points only become live when te code has
> been assembled and relocated.
>
> > I'm still learning all the details of HotSpot and I'm not sure how to
> > best approach such a problem, I'm pretty stumped on how to proceed here.
>
> Well, hope the above helps.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Principal Software Engineer
> Red Hat UK Ltd
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
> (USA), Paul Hickey (Ireland)
>