OS::TimeCurrentMillis should return double not long double

OS::TimeCurrentMillis should return double not long double

Make sure the value returned from OS::TimeCurrentMillis is cast to double (not long double). I also tried assigning the result of the expression to double variable and doing static_cast<double> but those are not enough on gcc. Not sure if we want this patch. I'm going to change profiler code to return microseconds as int64_t anyways.

BUG=v8:2824

[yurys, 2013-08-05 10:06:16]

Here is the assembler code for the function without and with volatile:

=> 0x085647e0 <+0>:	sub    $0x2c,%esp
   0x085647e3 <+3>:	lea    0x18(%esp),%eax
   0x085647e7 <+7>:	movl   $0x0,0x4(%esp)
   0x085647ef <+15>:	mov    %eax,(%esp)
   0x085647f2 <+18>:	call   0x804a0d0 <gettimeofday@plt>
   0x085647f7 <+23>:	test   %eax,%eax
   0x085647f9 <+25>:	js     0x8564818
<_ZN2v88internal2OS17TimeCurrentMillisEv+56>
   0x085647fb <+27>:	fildl  0x18(%esp)
   0x085647ff <+31>:	flds   0x8ebb0d4
   0x08564805 <+37>:	fmul   %st,%st(1)
   0x08564807 <+39>:	fildl  0x1c(%esp)
   0x0856480b <+43>:	add    $0x2c,%esp
   0x0856480e <+46>:	fdivp  %st,%st(1)
   0x08564810 <+48>:	faddp  %st,%st(1)
   0x08564812 <+50>:	ret    
   0x08564813 <+51>:	nop
   0x08564814 <+52>:	lea    0x0(%esi,%eiz,1),%esi
   0x08564818 <+56>:	fldz   
   0x0856481a <+58>:	add    $0x2c,%esp
   0x0856481d <+61>:	ret    


=> 0x085647e0 <+0>:	sub    $0x2c,%esp
   0x085647e3 <+3>:	lea    0x18(%esp),%eax
   0x085647e7 <+7>:	movl   $0x0,0x4(%esp)
   0x085647ef <+15>:	mov    %eax,(%esp)
   0x085647f2 <+18>:	call   0x804a0d0 <gettimeofday@plt>
   0x085647f7 <+23>:	test   %eax,%eax
   0x085647f9 <+25>:	js     0x8564820
<_ZN2v88internal2OS17TimeCurrentMillisEv+64>
   0x085647fb <+27>:	fildl  0x18(%esp)
   0x085647ff <+31>:	flds   0x8ebb0d4
   0x08564805 <+37>:	fmul   %st,%st(1)
   0x08564807 <+39>:	fildl  0x1c(%esp)
   0x0856480b <+43>:	fdivp  %st,%st(1)
   0x0856480d <+45>:	faddp  %st,%st(1)
   0x0856480f <+47>:	fstpl  0x10(%esp)
   0x08564813 <+51>:	fldl   0x10(%esp)
   0x08564817 <+55>:	add    $0x2c,%esp
   0x0856481a <+58>:	ret    
   0x0856481b <+59>:	nop
   0x0856481c <+60>:	lea    0x0(%esi,%eiz,1),%esi
   0x08564820 <+64>:	fldz   
   0x08564822 <+66>:	add    $0x2c,%esp
   0x08564825 <+69>:	ret

[Benedikt Meurer, 2013-08-05 10:13:03]

Using FPs for time values is never actually a good idea. So, I suggest to fix
the real issue instead and use integers to represent time offsets.

[yurys, 2013-08-05 10:24:48]

On 2013/08/05 10:13:03, Benedikt Meurer wrote:
> Using FPs for time values is never actually a good idea. So, I suggest to fix
> the real issue instead and use integers to represent time offsets.

Yes, as I promised the test failure is addressed in
https://codereview.chromium.org/22172002/. I just though that this might bite us
in another place and we might want this fix regardless of the profiler.

[Benedikt Meurer, 2013-08-05 10:29:10]

I think OS::TimeCurrentMillis() should be replaced with OS::Ticks().

[Sven Panne, 2013-08-05 10:41:18]

On 2013/08/05 10:29:10, Benedikt Meurer wrote:
> I think OS::TimeCurrentMillis() should be replaced with OS::Ticks().

+1 for killing the TimeCurrentMillis() / double nonsense! :-)

[Sven Panne, 2013-08-21 10:23:09]

What's the current state of the CL? Will it be subsumed by fixing
https://code.google.com/p/v8/issues/detail?id=2853?

[Benedikt Meurer, 2013-08-21 10:49:21]

On 2013/08/21 10:23:09, Sven Panne wrote:
> What's the current state of the CL? Will it be subsumed by fixing
> https://code.google.com/p/v8/issues/detail?id=2853?

To a certain degree, yes. OS::TimeCurrentMillis() will be dropped and the
profiler will use high-res timer tick clocks instead, and of course time is not
represented as floating point anymore.

[yurys, 2013-08-21 11:24:57]

On 2013/08/21 10:49:21, Benedikt Meurer wrote:
> On 2013/08/21 10:23:09, Sven Panne wrote:
> > What's the current state of the CL? Will it be subsumed by fixing
> > https://code.google.com/p/v8/issues/detail?id=2853?
> 
> To a certain degree, yes. OS::TimeCurrentMillis() will be dropped and the
> profiler will use high-res timer tick clocks instead, and of course time is
not
> represented as floating point anymore.

Closing this issue as we decided not to go this route.