Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 160511

Summary:

Profiling times returned by the JVMPI agent are incorrect under some circumstances on some Intel laptops.

Product:

z_Archived

Reporter:

Navid Mehregani <nmehrega>

Component:

TPTP

Assignee:

Bing Xu <xubing>

Status:

CLOSED WONTFIX

QA Contact:

Severity:

critical

Priority:

CC:

amehrega, asaf.yaffe, guru.nagarajan, jkubasta, smith, viacheslav.g.rybalov

Version:

unspecified

Keywords:

plan

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

closed460

Attachments:

Description	Flags
Java class that was profiled	none
Trace file	none
44_Profiling	none

Description Navid Mehregani

2006-10-11 13:11:57 EDT

The attached class makes 5 calls to a method (called 'methodA') which does a 1 second wait: Thread.sleep(1000);  When profiling this method, I expected its base and cumulative times to be close to 5 seconds and its average base time to be close to 1 second.  However, this is the result I get when profiling this class with the JVMPI agent:

methodA()
Base time: 0.703765
Average base time: 0.140753
Cumulative Time: 0.703765
Calls: 5

These statistics are completely different than what I expected.

Comment 1 Navid Mehregani

2006-10-11 13:12:31 EDT

Created attachment 51772 [details]
Java class that was profiled

Comment 2 Navid Mehregani

2006-10-11 13:12:53 EDT

Created attachment 51773 [details]
Trace file

Comment 3 Bob Duncan

2006-10-30 11:56:33 EST

*** Bug 134849 has been marked as a duplicate of this bug. ***

Comment 4 Bob Duncan

2006-11-03 13:01:25 EST

The underlying problem is a spec change to the hardware. The processor frequency now varies dynamically on mobile Intel PCs. The cause is that the SpeedStep laptop battery-saving technology on mobile Intel PCs can vary the power/voltage impacting the clock rate. This renders the timestamp counter (TSC) useless. The fix is to change from directly reading the timestamp tick counter to use the QueryPerformanceFrequency and QueryPerformanceCounter system calls (which are invariant particularly relative to the SpeedStep/power-saving technology).

Some characteritics of these system calls need to be carefully accounted for in our time-acquisition code. First, they depend on an optional hardware facility (which appears to be present wherever the SpeedStep technology is present). An initial call will indicate whether the service is available or not and, if not, the old direct read of the TSC must be employed. Secondly, these services give an effective 1-3MHz clock frequency on some platforms rather than the hundreds or thousands of MHz frequency of the cpu clocks on many/most of our target platforms. This means the ticksPerMicrosecond integer we use to convert ticks to time can cause an over-report time by 10% to 100%. This must be managed in the code (which is intricate) with minmal change to data types/etc in order to preserve stability, especially across platforms and at this late point in the release.

The diagnosis has been proven and the fix has been protoyped and validated. The fix is being carefully worked into final form so as to minimize cross-platform impact and to handle the system call characteristics. Cross-platform testing also remains to be done. This is targetted for completion by end of day today.

Comment 5 Bob Duncan

2006-11-03 20:02:34 EST

Code reviewed and checked into cvs (head).

Comment 6 Asaf Yaffe

2006-11-06 04:10:41 EST

This bug is also relevant for the JVMTI CPU Profiler. The JVMTI effort is tracked under Bugzilla 163469

Comment 7 Navid Mehregani

2006-11-06 10:09:19 EST

Marking as FIXED, since the code has been checked in.

Comment 8 Bob Duncan

2006-11-06 18:18:50 EST

Fix for build break (missing "else closer" on EM64t/IPF-specifci path) reviewed and checked-in to head.

Comment 9 Navid Mehregani

2006-11-10 12:19:15 EST

Verified on TPTP-4.3.0-200611070100. Closing.

Comment 10 Liz Dancy

2007-02-23 15:48:18 EST

Re-opening after this problem was found in TPTP 4.4 i1 TP2 candidate driver. To reproduce:
1) Profile the attached '44_Profiling' class, selecting Code Coevrgae Statistics only. Ensure you are using the default filter.
2) The correct statistics should show 80% of the methods hit, with MethodC being missed and MethodA being called 10 times.

(Ensure you have refreshed the view before examining stats)

The above expected results are produceed on my Desktop using AC. However, on my laptop I can consistently reproduce different results, where only 20% of the methods show as being hit (although the console prinout proves otherwise). When I switch to the IAC the correct profiling statistics are returned.

I have tried refreshing and restarting the workbench with no success.

Comment 11 Liz Dancy

2007-02-23 15:48:51 EST

Created attachment 59710 [details]
44_Profiling

Please use this class to reproduce

Comment 12 Samson Wai

2007-03-06 10:02:05 EST

Entered sizing.

Comment 13 Samson Wai

2007-11-27 09:30:13 EST

Hi Bing. I have transferred my bugs to you for triage. Thanks.

Comment 14 jkubasta

2007-11-27 10:10:44 EST

No plan to fix

Comment 15 Paul Slauenwhite

2009-06-30 13:22:30 EDT

As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.