Mailing-List: contact harmony-commits-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Message-ID: <27008289.1163455839022.JavaMail.jira@brutus>
Date: Mon, 13 Nov 2006 14:10:39 -0800 (PST)
From: "Alexei Fedotov (JIRA)" <jira@apache.org>
To: harmony-commits@incubator.apache.org
Subject: [jira] Commented: (HARMONY-1969) [drlvm][jit] nested synchronized
 blocks make Jitrino.OPT crash meeting multiple loop entrances to a single
 loop
In-Reply-To: <14727399.1161846257033.JavaMail.root@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/HARMONY-1969?page=comments#action_12449506 ] 
            
Alexei Fedotov commented on HARMONY-1969:
-----------------------------------------

I believe Alexey meant HARMONY-1908.

> [drlvm][jit] nested synchronized blocks make Jitrino.OPT crash meeting multiple loop entrances to a single loop
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-1969
>                 URL: http://issues.apache.org/jira/browse/HARMONY-1969
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: any
>            Reporter: Egor Pasko
>         Assigned To: Alexey Varlamov
>         Attachments: 0001-more-monexit-patterns-transformed-to-correct-loop-structure.txt, DoubleSync.java
>
>
> this is a sub-bug for HARMONY-1908. The reason is $subj. I suggest to restore a normal loop structure in this case (i. e. generalize the eliminateUnnestedLoopsOnDispatch() a little)
> of course, loop nesting may be broken in specially crafted bytecode samples (and we will not repair them with the proposed solution), but a reasonable behavoiur in this case would be to move bytecodes like this to JET. Here I am not for moving to JET because of the common nature of the code pattern (nested synches, javac) that we need to run heavily optimized.
> To reproduce, disable profiling-related asserts in ControlFlowGraph.cpp, rebuild Jitrino in debug mode.
> run DoubleSync (attached) with -Xem:opt
> java: /export/users/evpasko/svn/3/trunk/working_vm/vm/jitrino/src/shared/ControlFlowGraph.cpp:384: bool Jitrino::ControlFlowGraph::isEdgeProfileConsistent(bool, bool, bool): Assertion `doAssert?false:true' failed.
> SIGABRT in VM code.
> Stack trace:
>         1: ?? (??:-1)
>         2: abort (??:-1)
>         3: __assert_fail (??:-1)
>         4: Jitrino::ControlFlowGraph::isEdgeProfileConsistent(bool, bool, bool) (/export/users/evpasko/svn/3/trunk/working_vm/vm/jitrino/src/shared/ControlFlowGraph.cpp:385)
>         5: Jitrino::ControlFlowGraph::smoothEdgeProfile() (/export/users/evpasko/svn/3/trunk/working_vm/vm/jitrino/src/shared/ControlFlowGraph.cpp:947)
>         6: Jitrino::StaticProfiler::estimateGraph(Jitrino::IRManager&, double, bool) (/export/users/evpasko/svn/3/trunk/working_vm/vm/jitrino/src/dynopt/StaticProfiler.cpp:253)
>         7: Jitrino::StaticProfilerPass::_run(Jitrino::IRManager&) (/export/users/evpasko/svn/3/trunk/working_vm/vm/jitrino/src/dynopt/StaticProfiler.cpp:293)
>         8: Jitrino::OptPass::run() (/export/users/evpasko/svn/3/trunk/working_vm/vm/jitrino/src/optimizer/optpass.cpp:61)
>         9: Jitrino::runPipeline(Jitrino::CompilationContext*) (/export/users/evpasko/svn/3/trunk/working_vm/vm/jitrino/src/main/Jitrino.cpp:226)
>         10: Jitrino::compileMethod(Jitrino::CompilationContext*) (/export/users/evpasko/svn/3/trunk/working_vm/vm/jitrino/src/main/Jitrino.cpp:261)
> <snip>
> dumping dot files helps significantly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira