You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Mikhail Fursov (JIRA)" <ji...@apache.org> on 2007/07/17 13:19:05 UTC
[jira] Assigned: (HARMONY-2769) [drlvm][jit] use per-region
InlineInfo from global storage in VM to report stack frames of inlined
methods
[ https://issues.apache.org/jira/browse/HARMONY-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikhail Fursov reassigned HARMONY-2769:
---------------------------------------
Assignee: Mikhail Fursov
> [drlvm][jit] use per-region InlineInfo from global storage in VM to report stack frames of inlined methods
> ----------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-2769
> URL: https://issues.apache.org/jira/browse/HARMONY-2769
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Environment: all
> Reporter: Egor Pasko
> Assignee: Mikhail Fursov
> Priority: Minor
>
> In current implementation there are 2 mechanisms that allow to detect areas of inlined methods:
> 1. per-call-inline-info represents the whole inline nesting chain of each
> inlined 'call' instructions. All information is stored by JIT in the
> corresponding CodeChunkInfo->_jit_info_block and is decoded by JIT upon VM
> requests (during filling stack traces)
> 2. per-region-inline-info is collected within VM as an action raised by the
> CompiledMethodLoad(...) event (necessary for JVMTI) as in HARMONY-2145.
> This issue proposes to replace per-call-inline-info with per-region-inline-info
> to make a single storage and a single method to access inlining-related info in
> VM and JIT.
> there is one disadvantage to this approach:
> Relying on per-region-inline-info introduces some constraints for JIT
> design. Specifically, it becomes not easy to move instruction regions
> across method boundaries.
> but per-call-inline-info has other disadvantages:
> using per-call-inline-info is not sufficient to cover the functionality
> necessary for CompiledMethodLoad(...) event
> we cannot afford reporting stack frames on exceptions (because there are a
> lot fo potentially exceptional instructions and storing inline chains for
> all of them would be ineffective) see HARMONY-2114
> refer to the mailing list for details:
> http://thread.gmane.org/gmane.comp.java.harmony.devel/18590/focus=18999
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.