[jira] Updated: (HARMONY-4773) [drlvm][jit][opt] Enabling of per-method locks in Jitrino.OPT compiler

["Mikhail Fursov (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HARMONY-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mikhail Fursov updated HARMONY-4773:
------------------------------------

    Attachment: pml.diff

> [drlvm][jit][opt] Enabling of per-method locks in Jitrino.OPT compiler
> ----------------------------------------------------------------------
>
>                 Key: HARMONY-4773
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4773
>             Project: Harmony
>          Issue Type: Improvement
>          Components: DRLVM
>            Reporter: Mikhail Fursov
>            Assignee: Mikhail Fursov
>         Attachments: pml.diff
>
>
> Currently Jitrino.OPT uses 1 global lock to synchronize updates of method data (info-maps, generated code).
> Jitrino.OPT locks method data after HLO all sessions are finished and before CG sessions are started to avoid resolution calls from inside of the lock. In CG everything is resolved, so locking CG sessions is safe.
> This is bad, because on some applications like SpecJApp server or even in our smoke tests (thread.SmallStackThreadTest) there are >N*1000 threads starting to compile the same method. This can cause native OOME if compiled method is large.
> Solution I see here: 
> 1) Enable lazy resolution mode in all modes
> 2) Lock whole compilation session with per-method lock
> 3) Use per-method lock because in -Xverify:none mode Jitrino.OPT calls to resolve some classes even in lazy resolution mode (exception handlers), so we can't use global lock here (if exception class is loaded in a separate thread that needs to compile some method)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.