Re: J2SE compliant RE for Arm Linux
See also http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/LockSupport.html
Re: J2SE compliant RE for Arm Linux
On Wed, 2007-06-27 at 14:39 +0100, Robert Lougher wrote: > Hi, > > Park and unpark are empty stubs, but everything else should be > implemented... If anybody can tell me what park/unpark should do, > I'll implement them too! I saw gcj has an implementation, but I didn't have time to do it. But you can also look in HotSpot's code what should be done :-) - twisti
Re: J2SE compliant RE for Arm Linux
Robert Lougher writes:
> Park and unpark are empty stubs, but everything else should be
> implemented... If anybody can tell me what park/unpark should do,
> I'll implement them too!
I'll bite.
park() stops a thread until some other thread calls unpark() on that
thread or the thread is interrupted. park() may wake up spuriously,
or indeed it may return immediately. If unpark() is called before
park(), park() returns immediately. Therefore, the order in which
park() and unpark() are called makes no difference.
So, empty definitions of park() and unpark() are correct but
inefficient.
I've attached the gcj POSIX definitions.
Andrew.
/**
* Releases the block on a thread created by _Jv_ThreadPark(). This
* method can also be used to terminate a blockage caused by a prior
* call to park. This operation is unsafe, as the thread must be
* guaranteed to be live.
*
* @param thread the thread to unblock.
*/
void
ParkHelper::unpark ()
{
using namespace ::java::lang;
volatile obj_addr_t *ptr = &permit;
/* If this thread is in state RUNNING, give it a permit and return
immediately. */
if (compare_and_swap
(ptr, Thread::THREAD_PARK_RUNNING, Thread::THREAD_PARK_PERMIT))
return;
/* If this thread is parked, put it into state RUNNING and send it a
signal. */
if (compare_and_swap
(ptr, Thread::THREAD_PARK_PARKED, Thread::THREAD_PARK_RUNNING))
{
pthread_mutex_lock (&mutex);
pthread_cond_signal (&cond);
pthread_mutex_unlock (&mutex);
}
}
/**
* Sets our state to dead.
*/
void
ParkHelper::deactivate ()
{
permit = ::java::lang::Thread::THREAD_PARK_DEAD;
}
/**
* Blocks the thread until a matching _Jv_ThreadUnpark() occurs, the
* thread is interrupted or the optional timeout expires. If an
* unpark call has already occurred, this also counts. A timeout
* value of zero is defined as no timeout. When isAbsolute is true,
* the timeout is in milliseconds relative to the epoch. Otherwise,
* the value is the number of nanoseconds which must occur before
* timeout. This call may also return spuriously (i.e. for no
* apparent reason).
*
* @param isAbsolute true if the timeout is specified in milliseconds from
* the epoch.
* @param time either the number of nanoseconds to wait, or a time in
* milliseconds from the epoch to wait for.
*/
void
ParkHelper::park (jboolean isAbsolute, jlong time)
{
using namespace ::java::lang;
volatile obj_addr_t *ptr = &permit;
/* If we have a permit, return immediately. */
if (compare_and_swap
(ptr, Thread::THREAD_PARK_PERMIT, Thread::THREAD_PARK_RUNNING))
return;
struct timespec ts;
jlong millis = 0, nanos = 0;
if (time)
{
if (isAbsolute)
{
millis = time;
nanos = 0;
}
else
{
millis = java::lang::System::currentTimeMillis();
nanos = time;
}
if (millis > 0 || nanos > 0)
{
// Calculate the abstime corresponding to the timeout.
// Everything is in milliseconds.
//
// We use `unsigned long long' rather than jlong because our
// caller may pass up to Long.MAX_VALUE millis. This would
// overflow the range of a timespec.
unsigned long long m = (unsigned long long)millis;
unsigned long long seconds = m / 1000;
ts.tv_sec = seconds;
if (ts.tv_sec < 0 || (unsigned long long)ts.tv_sec != seconds)
{
// We treat a timeout that won't fit into a struct timespec
// as a wait forever.
millis = nanos = 0;
}
else
{
m %= 1000;
ts.tv_nsec = m * 100 + (unsigned long long)nanos;
}
}
}
if (compare_and_swap
(ptr, Thread::THREAD_PARK_RUNNING, Thread::THREAD_PARK_PARKED))
{
pthread_mutex_lock (&mutex);
if (millis == 0 && nanos == 0)
pthread_cond_wait (&cond, &mutex);
else
pthread_cond_timedwait (&cond, &mutex, &ts);
pthread_mutex_unlock (&mutex);
/* If we were unparked by some other thread, this will already
be in state THREAD_PARK_RUNNING. If we timed out, we have to
do it ourself. */
compare_and_swap
(ptr, Thread::THREAD_PARK_PARKED, Thread::THREAD_PARK_RUNNING);
}
}
Re: J2SE compliant RE for Arm Linux
Hi, Park and unpark are empty stubs, but everything else should be implemented... If anybody can tell me what park/unpark should do, I'll implement them too! Rob. On 6/27/07, Christian Thalinger <[EMAIL PROTECTED]> wrote: On Wed, 2007-06-27 at 12:47 +0200, Christian Thalinger wrote: > java.lang.UnsatisfiedLinkError: putObject > > I'll implement the missing sun.misc.Unsafe functions and get back to > you. Hi! I've implemented putObject and park (only an empty stub, like jamvm). If more is missing, let me know. - twisti
Re: J2SE compliant RE for Arm Linux
On Wed, 2007-06-27 at 12:47 +0200, Christian Thalinger wrote: > java.lang.UnsatisfiedLinkError: putObject > > I'll implement the missing sun.misc.Unsafe functions and get back to > you. Hi! I've implemented putObject and park (only an empty stub, like jamvm). If more is missing, let me know. - twisti
Re: J2SE compliant RE for Arm Linux
On Wed, 2007-06-27 at 10:16 +0200, Søren Boll Overgaard wrote: > [EMAIL PROTECTED]:~/classes$ /usr/local/cacao/bin/cacao > LinkedBlockingQueueTest > Exception in thread "main" java.lang.IllegalMonitorStateException >at java.util.concurrent.locks.ReentrantLock > $Sync.tryRelease(ReentrantLock.java:126) >at > java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1139) >at > java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:430) >at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:368) >at LinkedBlockingQueueTest.main(LinkedBlockingQueueTest.java:9) > [EMAIL PROTECTED]:~/classes$ > > I am using classpath 0.95 and cacao with the following options: Hi! Funny that the real exception is hidden somewhere: java.lang.UnsatisfiedLinkError: putObject I'll implement the missing sun.misc.Unsafe functions and get back to you. - twisti
Re: J2SE compliant RE for Arm Linux
Il giorno mer, 27/06/2007 alle 10.16 +0200, Søren Boll Overgaard ha
scritto:
> Anyway, let me just run the error I am seeing by you, and if it's
> genuine (and not due to a screw up on my part) I will file an
> appropriate bug:
>
> Running a simple program like this:
>
> import java.util.concurrent.LinkedBlockingQueue;
>
> public class LinkedBlockingQueueTest {
> public static void main(String[] args) {
> LinkedBlockingQueue q = new
> LinkedBlockingQueue();
> try {
> q.take();
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> }
Hi Søren,
Works for me on an i386 (dual core) with jamvm: The program waits
forever doing nothing :). I don't have cacao ATM to test it.
Could you give a look at jamvm, maybe this is a bug triggered with
cacao?
Mario
--
Lima Software - http://www.limasoftware.net/
GNU Classpath Developer - http://www.classpath.org/
Fedora Ambassador - http://fedoraproject.org/wiki/MarioTorre
Jabber: [EMAIL PROTECTED]
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/
signature.asc
Description: Questa è una parte del messaggio firmata digitalmente
Re: J2SE compliant RE for Arm Linux
Hi Andrew,
Thank you very much for your reply.
On Sun, 2007-06-24 at 22:18 +0100, Andrew John Hughes wrote:
> > As part of my switch to a new job, I've been trying to convince my
> > employers to switch from C++ to java on an embedded ARM based platform.
> >
> > However, in order for the switch to be reasonably painless, we will need
> > a J2SE compliant (although we don't need any GUI components) runtime
> > environment for the embedded platform. I've been looking at various
> > alternatives based on GNU classpath (as well as a few others). They
> > include jamvm, mika, PERC, kaffe, gcj and a few more. So far, none of
> > the the platforms I've been looking at (except PERC, which is
> > prohibitively priced) support J2SE 5.0. Thus, my question is, can you
> > provide me with a pointer to a J2SE 5.0 JRE (GNU classpath based or
> > otherwise) which will run on an ARM Linux platform?
>
> Hi Søren,
>
> It really depends what you mean by a 'J2SE 5.0 JRE' -- what particular
> features have you found lacking in the solutions you've tried? GNU Classpath
> itself should support 95%+ of the 1.5 API, and, as of the 0.95 release, is
> only buildable with a 1.5 supporting compiler. Personally, I've been using
> JamVM with 1.5 stuff for about the last three years.
>
> If there is something missing, please file a bug with the respective project
> and let them know (GNU Classpath for library classes, the appropriate VM
> otherwise). Which version of gcj and kaffe did you try? These projects
> differ quite significantly between their current release versions and the
> version in their source repositories, and don't (as yet) directly use GNU
> Classpath, so there is some delay between code being written there and being
> imported into their own local tree.
>
> Hope that helps,
Thanks for your input.
JamVM and CACAO currently look to be the most promising candidates. I am
however having trouble with GNU classpath. Specifically, the
LinkedBlockingQueue and NetworkInterface classes. Hmm, I just now
realised that upgrading to Classpath 0.95 fixes the
NetworkInterface.getNetworkInterface() method.
Anyway, let me just run the error I am seeing by you, and if it's
genuine (and not due to a screw up on my part) I will file an
appropriate bug:
Running a simple program like this:
import java.util.concurrent.LinkedBlockingQueue;
public class LinkedBlockingQueueTest {
public static void main(String[] args) {
LinkedBlockingQueue q = new
LinkedBlockingQueue();
try {
q.take();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
Results in the following error:
[EMAIL PROTECTED]:~/classes$ /usr/local/cacao/bin/cacao
LinkedBlockingQueueTest
Exception in thread "main" java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock
$Sync.tryRelease(ReentrantLock.java:126)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1139)
at
java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:430)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:368)
at LinkedBlockingQueueTest.main(LinkedBlockingQueueTest.java:9)
[EMAIL PROTECTED]:~/classes$
I am using classpath 0.95 and cacao with the following options:
Configure/Build options:
./configure:
'--with-classpath-classes=/usr/local/share/classpath/glibj.zip'
'--with-classpath-includedir=/usr/local/include/'
'--with-classpath-libdir=/usr/local/lib/' '--disable-disassembler'
CC : (4.1.2 (Ubuntu 4.1.2-0ubuntu4))
CFLAGS : -O2 -g3 -D__I386__ -D__LINUX__ -ansi -pedantic -Wall
-Wno-long-long -D_POSIX_C_SOURCE=199506L -D_XOPEN_SOURCE=500
-D_XOPEN_SOURCE_EXTENDED -D_BSD_SOURCE
Default variables:
maximum heap size : 134217728
initial heap size : 2097152
stack size : 65536
java.boot.class.path :
/usr/local/cacao/share/cacao/vm.zip:/usr/local/share/classpath/glibj.zip
gnu.classpath.boot.library.path: /usr/local/lib//classpath
Runtime variables:
maximum heap size : 134217728
initial heap size : 2097152
stack size : 65536
libjvm.so : /usr/local/cacao/lib/libjvm
java.boot.class.path :
/usr/local/cacao/share/cacao/vm.zip:/usr/local/share/classpath/glibj.zip
gnu.classpath.boot.library.path: /usr/local/lib//classpath
java.class.path: .
Again, thanks for your input.
--
Søren O.
"Oh, bother" said the Borg, "we've assimilated Pooh".
