A baffling bug...

[Thomas Wuerthinger]

Andrew,

Thanks for the report! Best way for us to look at this in more detail would be to get access to the compiler graphs. You can get these graphs sent to the IdealGraphVisualizer by running -Dgraal.Dump=:1 and -Dgraal.MethodFilter=Foo.bar. The IGV then has an option to export the graphs to a file.

- thomas


> On 11 Nov 2016, at 19:38, Andrew Haley <aph at redhat.com> wrote:
> 
> I've been having some problems with my tests, which include one
> failure I can't explain.
> 
> What happens is that Graal-generated code tries to re-lock an object
> which is already locked in this method using a stack slot for the
> displaced header which is already in use for the same object.  This
> should not be possible if locks are correctly nested.
> 
> The code roughly looks like this:
> 
>    public final int readUnsignedShort() throws IOException {
>        int ch1 = in.read();
>        int ch2 = in.read();
>        ...
> 
> where read is():
> 
>    public synchronized int read() throws IOException {
>        if (pos >= count) {
>            fill();
>            if (pos >= count)
>                return -1;
>        }
>        return getBufIfOpen()[pos++] & 0xff;
> 
> It's extremely hard to tell exactly what is going on because the
> generated code has very convoluted control flow.  However, my guess is
> that Graal has tried to coalesce two monitor regions into one but got
> it wrong.  (These two monitor regions are for the two synchronized
> calls to in.read().)
> 
> So, my questions:
> 
> Does Graal try to coalesce monitor regions?  If so, is there some way
> to turn that off?
> 
> Does anyone have any other suggestions?
> 
> Or want to look at the generated code?  ;-)
> 
> Andrew.
>