harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Dmitriev (JIRA)" <j...@apache.org>
Subject [jira] Created: (HARMONY-3619) Object.wait(Long.MAX_VALUE) exits immediately
Date Wed, 11 Apr 2007 08:55:32 GMT
Object.wait(Long.MAX_VALUE) exits immediately
---------------------------------------------

                 Key: HARMONY-3619
                 URL: https://issues.apache.org/jira/browse/HARMONY-3619
             Project: Harmony
          Issue Type: Bug
          Components: DRLVM
         Environment: Linux
            Reporter: Sergey Dmitriev


Current implementation of Object.wait(long ms[, long nano]) behaves
incorrectly in case of big enough 'ms', for example equal to
Long.MAX_VALUE. Meaning that in such cases Object.wait() just returns
immediately. (See below to find out what 'big enough' means here). We
are talking about linux.

Here is the mini test:

--- currenttimemillis.java ---
public class currenttimemillis {
    public static void main(String args[]) throws Exception {
        String lock = "lock";
        synchronized (lock) {
            lock.wait(Long.MAX_VALUE, 0);
        }
        System.out.println("Actually you should see this message after approx " +
                           Long.MAX_VALUE/1000/60/24/365 + " years.");
 
    }
}

--- console logs ---
] sam@linuxbox
] java -showversion currenttimemillis
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-linux-ia32, R25.0.0-75, GC: System
optimized over throughput (initial strategy singleparpar))
 
// hangs up as expected
^C


] sam@linuxbox
] ~/jre.0804-gcc-debug/bin/java -showversion currenttimemillis                           
                                
Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors,
as applicable.
java version "1.5.0" 
pre-alpha : not complete or compatible
svn = r526433, (Apr  8 2007), Linux/ia32/gcc 3.3.3, debug build
http://incubator.apache.org/harmony
Actually you should see this message after approx 17548272520 years.


The root problem goes from the vm/thread/src/linux/os_condvar.c,
method os_cond_timewait(hycond *cond, hymutex_t *mutex, I_64 ms, IDATA nano).
This method incorrectly converts the provided wait period from the
ms:nanos format into the sec:nanos format (absolute time from the
epoch) which is acceptable by pthreads. The first mistake here is the
multiplication of 'ms' (64 bit value) by 1000 at:

       apr_time_t then = apr_time_now() + ms*1000 + nano/1000;

If we have a 'big enough' 'ms' value - overflow comes into play.

So I've attached the proposed fix for the code (regression test patch
on its way). One note: the code fix assumes that the 'nano' parameter
can be more than 999999 to not to risk. Since it is unclear whether
the 'nano' is 100% lays in [0-999999] segment. (See
java.lang.Object#wait(long, long) javadoc). If someone can advocate
that 'nano' is always in [0-999999] or provide appropriate comments
here we can remove a couple of divisions/modulos from the patch.

This issue is not repro on Win32.

Thanks to Aleksey Shipilev and Rustem Rafikov for helping me in
tracing this issue.


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


Mime
View raw message