Bug 25244 - JDIThread#getTopStackFrame() performance
Summary: JDIThread#getTopStackFrame() performance
Status: RESOLVED DUPLICATE of bug 16036
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 2.0   Edit
Hardware: PC Linux
: P4 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Luc Bourlier CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2002-10-23 09:27 EDT by Luc Bourlier CLA
Modified: 2003-05-14 11:18 EDT (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Luc Bourlier CLA 2002-10-23 09:27:43 EDT 
The current implementation of JDIThread#getTopStackFrame() calls
computeStackFrames() to update the stack frame list if needed.

computeStackFrames() is not a trivial method, it retrieve all stack frames and
can be expensive (ReferenceTypeImpl#findMethod(MethodID) calls, see bug 24720).

The implementation should be:
- if the cached stack frames are valid, return the top stack frame from this cache.
- otherwise, ask the vm for the top stack frame and cache the value.
Comment 1 Darin Wright CLA 2002-10-23 10:10:40 EDT 
Luc, please investigate if this has any real impact on performance. From what I 
can tell (breif look), the potentially expensice calls to #getTopStackFrame() 
only happen when a thread is suspended, and the UI has to render all frames 
anyway. Thus, in practice, I think that all frames will be retrieved anyway. We 
may just end up doing more calls - i.e. get the top frame, and then get all 
frames.
Comment 2 Darin Wright CLA 2002-10-29 11:55:51 EST 
Please investigate.
Comment 3 Darin Wright CLA 2003-02-05 09:59:09 EST 
Deferred
Comment 4 Darin Wright CLA 2003-05-14 11:17:30 EDT 
This is fixed in 3.0 - the model is populated lazily. Each stack frame has an 
index into the stack.
Comment 5 Darin Wright CLA 2003-05-14 11:18:41 EDT 
This is a dup of the first part of 16036.

*** This bug has been marked as a duplicate of 16036 ***