Evgueni Brevnov wrote:
In other words we will observe the crash as we do now if sem_wait
completes unsuccessfully for whatever reason...
Well it shouldn't return an error except for signal, shouldn't it? Two
possible other errors are EINVAL and EDEADLK which should never happen.
Maybe we
the
threading library AFAIU that doesn't mean to lock the
monitor but
get it from the threading library. So the hythread_monitor_init
should
not lock the monitor.
Could somebody comment on that?
It might be that semantic is different on different platforms
which
Evgueni Brevnov wrote:
You can look at the change here
http://issues.apache.org/jira/browse/HARMONY-2203
Could someone who knowns classlib native code internals better than me
comment on this JIRA? I've added my comment from the general POV.
I would change the loop to detect only signal
Yes - that's why I was poking him to see the patch. I was going to
suggest something very similar.
geir
Gregory Shimansky wrote:
Evgueni Brevnov wrote:
You can look at the change here
http://issues.apache.org/jira/browse/HARMONY-2203
Could someone who knowns classlib native code
Gregory,
The code which goes after sem_wait doesn't work properly if sem_wait
returns with an error code. So we need to either loop until sem_wait
returns successfully or adjust the code after sem_wait to handle
irregular cases.
Thanks
Evgueni
On 11/16/06, Geir Magnusson Jr. [EMAIL PROTECTED]
In other words we will observe the crash as we do now if sem_wait
completes unsuccessfully for whatever reason...
On 11/17/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Gregory,
The code which goes after sem_wait doesn't work properly if sem_wait
returns with an error code. So we need to either
the
threading library AFAIU that doesn't mean to lock the monitor but
get it from the threading library. So the hythread_monitor_init should
not lock the monitor.
Could somebody comment on that?
It might be that semantic is different on different platforms which is
probably even worse. Your
and acquires a monitor.
Original spec reads: Acquire and initialize a new monitor from the
threading library AFAIU that doesn't mean to lock the
monitor but
get it from the threading library. So the hythread_monitor_init
should
not lock the monitor.
Could somebody comment
out one interesting thing. It turned out
that DRL
implementation of hythread_monitor_init /
hythread_monitor_init_with_name initializes and acquires a
monitor.
Original spec reads: Acquire and initialize a new monitor
from the
threading library AFAIU that doesn't mean to lock
and acquires a
monitor.
Original spec reads: Acquire and initialize a new monitor
from the
threading library AFAIU that doesn't mean to lock the
monitor but
get it from the threading library. So the hythread_monitor_init
should
not lock the monitor.
Could somebody
/
hythread_monitor_init_with_name initializes and acquires a monitor.
Original spec reads: Acquire and initialize a new monitor from the
threading library AFAIU that doesn't mean to lock the monitor but
get it from the threading library. So the hythread_monitor_init should
not lock
.
Original spec reads: Acquire and initialize a new monitor from the
threading library AFAIU that doesn't mean to lock the monitor but
get it from the threading library. So the hythread_monitor_init should
not lock the monitor.
Could somebody comment on that?
Thanks
Evgueni
Hi community,
I'd like to discuss one particular feature of DRL threading library
with you. TM provides four interface functions that can be used to
create a new native thread or attach existing one to TM. Here they
are:
1. hythread_create(hythread_t *handle, UDATA stacksize, UDATA
priority
is described in
HARMONY-2006 I found out one interesting thing. It turned out that DRL
implementation of hythread_monitor_init /
hythread_monitor_init_with_name initializes and acquires a monitor.
Original spec reads: Acquire and initialize a new monitor from the
threading library AFAIU
/
hythread_monitor_init_with_name initializes and acquires a monitor.
Original spec reads: Acquire and initialize a new monitor from the
threading library AFAIU that doesn't mean to lock the monitor but
get it from the threading library. So the hythread_monitor_init should
not lock
and acquires a monitor.
Original spec reads: Acquire and initialize a new monitor from the
threading library AFAIU that doesn't mean to lock the monitor but
get it from the threading library. So the hythread_monitor_init should
not lock the monitor.
Could somebody comment
/
hythread_monitor_init_with_name initializes and acquires a monitor.
Original spec reads: Acquire and initialize a new monitor from the
threading library AFAIU that doesn't mean to lock the monitor but
get it from the threading library. So the hythread_monitor_init should
not lock the monitor.
Could somebody comment
Evgueni,
That was great.
Artem,
It's nice to see you online. Could you please check the last comments
to http://issues.apache.org/jira/browse/HARMONY-1904 and decide what
should we do about this issue?
Gregory,
I can't reproduce the problem described by you on my local Ubuntu
machine. So I can only guess. And my guess is that
mapPortLibSignalToUnix can't find corresponding signal in the map.
That's why you have undefined sig (-1215196204) in jsig_handler. I can
think of two reasons why
and acquires a monitor.
Original spec reads: Acquire and initialize a new monitor from the
threading library AFAIU that doesn't mean to lock the monitor but
get it from the threading library. So the hythread_monitor_init should
not lock the monitor.
Could somebody comment on that?
It might
monitor from the
threading library AFAIU that doesn't mean to lock the monitor but
get it from the threading library. So the hythread_monitor_init should
not lock the monitor.
Could somebody comment on that?
Thanks
Evgueni
I might be misunderstanding the code but the local variable,
hythread_monitor_t monitor; is used as a parameter to a call to
array_add(jvmti_monitor_table, monitor);. It seems that once
jthread_raw_monitor_create() returns, the jvmti_monitor_table will end up
with an invalid pointer. Is this
On Saturday 11 November 2006 01:36 Weldon Washburn wrote:
I might be misunderstanding the code but the local variable,
hythread_monitor_t monitor; is used as a parameter to a call to
array_add(jvmti_monitor_table, monitor);. It seems that once
jthread_raw_monitor_create() returns, the
a monitor.
Original spec reads: Acquire and initialize a new monitor from the
threading library AFAIU that doesn't mean to lock the monitor but
get it from the threading library. So the hythread_monitor_init should
not lock the monitor.
Could somebody comment on that?
It might
done:[JET_DPGO n=788: OK] java/lang/Object::notifyAll()V
most likely, threading library failed to load, because:
(gdb) bt 20
#0 0x40007de5 in do_lookup_x () from /lib/ld-linux.so.2
#1 0x400080dc in _dl_lookup_symbol_x () from /lib/ld-linux.so.2
#2 0x40558f16 in do_sym () from /lib/tls/libc.so.6
#3
] java/lang/Thread::runImpl()V
EM: compile done:[JET_DPGO n=787: OK] java/lang/Thread::runImpl()V
EM: compile start:[JET_DPGO n=788] java/lang/Object::notifyAll()V
EM: compile done:[JET_DPGO n=788: OK] java/lang/Object::notifyAll()V
most likely, threading library failed to load, because:
(gdb) bt 20
::notifyAll()V
most likely, threading library failed to load, because:
(gdb) bt 20
#0 0x40007de5 in do_lookup_x () from /lib/ld-linux.so.2
#1 0x400080dc in _dl_lookup_symbol_x () from /lib/ld-linux.so.2
#2 0x40558f16 in do_sym () from /lib/tls/libc.so.6
#3 0x4055904a in _dl_sym () from /lib/tls
I did some digging. It looks like what's in today's svn HEAD does the
following:
thread_native_semaphore.c::hysem_wait() calls
thread_native_semaphore.c::sem_wait_impl() calls
thread_native_condvar.c::condvar_wait_impl() which does the following:
{
disable_count =
On 10/19/06, Artem Aliev [EMAIL PROTECTED] wrote:
Eugeny,
The problem can be easily fixed by changing int16 to unit16 in
atomic16_dec. Do you think this is accaptable way to fix the problem.
BTW, could somebody explain why 16-bit atomic operation is used for
32-bit value?
The
The patch for the problem was created
http://issues.apache.org/jira/browse/HARMONY-1929
Evgueni
On 10/20/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
On 10/19/06, Artem Aliev [EMAIL PROTECTED] wrote:
Eugeny,
The problem can be easily fixed by changing int16 to unit16 in
atomic16_dec. Do
Evgueni,
Please also test on Linux. This looks like a reasonable patch to me.
Regarding the 16-bit CAS. A long time ago, there was a 16-bit, byte-aligned
field for thread ID. monenter() would do a 16-bit CAS. Maybe this is left
over from old monenter()??
On 10/19/06, Artem Aliev [EMAIL
On 10/20/06, Weldon Washburn [EMAIL PROTECTED] wrote:
Evgueni,
Please also test on Linux. This looks like a reasonable patch to me.
Unfortunately, I don't have access to Linux today (work from home).
Regarding the 16-bit CAS. A long time ago, there was a 16-bit, byte-aligned
field for
Weldon,
If the current scheme is the same that we had 1 or 2 years ago, the answer
is no
This is just the same scheme!
I am really hoping that all of this is simply an implementation
bug.
There are no open issues on this scheme, there is no examples that
fail right now because of the
On 10/18/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
I agree it is required to have a solid model in mind. I also believe
it is required to have such design/implementation which doesn't allow
to break that model.
No, that's the point if functionality is so safe that it's impossible
to
Hi,
Today, I had several hangs of cunit tests. It turned out to be
infinite cycling in
while loop of atomic16_inc/atomic16_dec (see
vm/thread/src/thread_native_suspend.c)
Here is a snip of assembler code produced by msvc for atomic16_dec:
callport_atomic_cas16 (10004A90h)
add
Eugeny,
The problem can be easily fixed by changing int16 to unit16 in
atomic16_dec. Do you think this is accaptable way to fix the problem.
BTW, could somebody explain why 16-bit atomic operation is used for
32-bit value?
The suspend_request could be 16bit value some time ago.
Could you
with the
one discussed in [drlvm][threading] Possible race condition in
implementation of conditional variables? Your thoughts?
The code of suspend_all method is dedicated to the cyclic suspension problem.
The fact that this method is being called from suspend_disable region and
have safe_point
seems to be very similar with the
one discussed in [drlvm][threading] Possible race condition in
implementation of conditional variables? Your thoughts?
The code of suspend_all method is dedicated to the cyclic suspension
problem.
The fact that this method is being called from
in [drlvm][threading] Possible race condition in
implementation of conditional variables? Your thoughts?
The code you see is there to prevent following deadlock scenario:
Thread A Thread B
| |
| suspend(A);
| A-suspend_request = 1
Evgueni,
first of all I'd like to emphasize that suspend/resume_all functions
are potentially unsafe
and should be used with care.
secondly, those methods were designed mainly to support
stop_the_world_enumeration
and thus usually being used under certain conditions.
hmmm... it is
hmm I never thought of it that way. My initial reaction is no. Suspend
enable/disable and global thread lock are seperate, distinct concepts. The
thread lock should protect the VM internal thread structs when they
are being modified. For example, the thread lock should allow only
one
Hi Nikolay!
On 10/18/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
Evgueni,
first of all I'd like to emphasize that suspend/resume_all functions
are potentially unsafe
and should be used with care.
secondly, those methods were designed mainly to support
stop_the_world_enumeration
I agree it is required to have a solid model in mind. I also believe
it is required to have such design/implementation which doesn't allow
to break that model.
No, that's the point if functionality is so safe that it's impossible
to break the model,
it's not so highly important(as in our case)
It seems we are not in sync I don't suggest changing current
suspention scheme...I like it I'm talking about one particular
case.and still can't see any disadvantages in what I propose...
On 10/18/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
I agree it is required to have a solid
hythread_suspend_all. The problem seems to be very similar with the
one discussed in [drlvm][threading] Possible race condition in
implementation of conditional variables? Your thoughts?
The code you see is there to prevent following deadlock scenario:
Thread A Thread B
On 10/18/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
hmm I never thought of it that way. My initial reaction is
no. Suspend
enable/disable and global thread lock are seperate, distinct
concepts. The
thread lock should protect the VM internal thread structs when they
are being
(at least me) expects to have a safe point during
hythread_suspend_all. The problem seems to be very similar with the
one discussed in [drlvm][threading] Possible race condition in
implementation of conditional variables? Your thoughts?
The code you see is there to prevent following
entering
hythread_suspend_all. So it can be called in suspend disabled state
and nobody (at least me) expects to have a safe point during
hythread_suspend_all. The problem seems to be very similar with the
one discussed in [drlvm][threading] Possible race condition in
implementation of conditional
with the
one discussed in [drlvm][threading] Possible race condition in
implementation of conditional variables? Your thoughts?
The code of suspend_all method is dedicated to the cyclic suspension problem.
The fact that this method is being called from suspend_disable region and
have safe_point
be deadlock or
latency problems.
Did you try the above approach? ARe there deadlocks?
The problem seems to be very similar with the
one discussed in [drlvm][threading] Possible race condition in
implementation of conditional variables? Your thoughts?
The code of suspend_all method is dedicated
regarding thread's state upon entering
hythread_suspend_all. So it can be called in suspend disabled state
and nobody (at least me) expects to have a safe point during
hythread_suspend_all. The problem seems to be very similar with the
one discussed in [drlvm][threading] Possible race condition
The simplest model is to grab the thread lock whenever thread A wants to
suspend thread B at a safepoint. While this serializes thread suspension
and can potentially be a bottleneck, let's wait until its a proven
performance problem to change this model. For thread A to be ready to grab
the
On 10/17/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
The simplest model is to grab the thread lock whenever thread A wants to
suspend thread B at a safepoint. While this serializes thread
suspension
and can potentially be a bottleneck, let's wait until its a proven
performance problem
it.
It looks like someone changed the behavior of semaphores to be
compatible with the monitors.
I agree with Xiao-Feng: the sleeping thread should be in suspend_enable
mode.
So I vote for leaving the current threading code as is but checking
DRLVM for a code that not ready for the new behavior
Hi,
Is there any known bug related to this issue?
Rana
On 10/15/06, Weldon Washburn [EMAIL PROTECTED] wrote:
After thinking about it a while, how about the following course of
action:
1)
First phase is to modify hysem_wait() and any other hy blocking
functions to test if, in
Its a design rule kind of thing. Breaking the design rule leads to
undefined behavior. My experience is that the kind of problem described
here leads to very hard to diagnose system instability. If anything, a
known bug of general, intermittant instability could be associated with
this issue.
about it.
It looks like someone changed the behavior of semaphores to be
compatible with the monitors.
I agree with Xiao-Feng: the sleeping thread should be in suspend_enable mode.
So I vote for leaving the current threading code as is but checking
DRLVM for a code that not ready for the new behavior
Hi,
I do the following:
hythread_suspend_disable();
do unsafe actions
hysem_wait(semaphore);
do unsafe actions
hythread_suspend_enable();
By saying hythread_suspend_disable(); I expect the thread can't be
suspended until hythread_suspend_enable() is called. But hysem_wait()
resets disabled
On 10/12/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Hi,
I do the following:
hythread_suspend_disable();
do unsafe actions
hysem_wait(semaphore);
do unsafe actions
hythread_suspend_enable();
By saying hythread_suspend_disable(); I expect the thread can't be
suspended until
GC should be enabled in waiting state. In case that a GC can happen,
the code should do bookkeeping to guarantee the correctness.
Thanks,
xiaofeng
On 10/13/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Hi,
I do the following:
hythread_suspend_disable();
do unsafe actions
Hi, when I tested with GCv5 in DRLVM, I found there is design issue in
threading part. That is, after gc is initiated (gc_init) in runtime,
the main thread can't allocate object based on its allocation context
(thread local gc info), because the allocation context is not
initialized
Before this bug is fixed in threading part, for any people who are
interested in GCv5, please use patch below for workaround, just to add
two lines.
GCv5 only works in Windows at the moment. Please get it in latest SVN,
and patch it with http://issues.apache.org/jira/browse/HARMONY-1785
On 10/9/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Hi, when I tested with GCv5 in DRLVM, I found there is design issue in
threading part. That is, after gc is initiated (gc_init) in runtime,
the main thread can't allocate object based on its allocation context
(thread local gc info), because
Weldon Washburn wrote:
Artem,
I'd like to confirm what you said. For GC_BIT_MASK, it looks like the
bottom
two bits of byte number one is available for exclusive GC use. If the GC
needs to alter these two bits while the mutator(s) are running, the GC
needs
to use CAS on the entire 32 bits
On 10/9/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
Artem,
I'd like to confirm what you said. For GC_BIT_MASK, it looks like the
bottom
two bits of byte number one is available for exclusive GC use. If the
GC
needs to alter these two bits while the mutator(s) are
Weldon, All
Here is the updated vm/vmcore/sync_bit.h header file.
That, I think, describes current state of the object header.
I olso try define rules: How to update the header correctly.
Welcome to discussion on them.
#ifndef _sync_bits_H
#define _sync_bits_H
/**
* These defines describe
Artem,
I'd like to confirm what you said. For GC_BIT_MASK, it looks like the bottom
two bits of byte number one is available for exclusive GC use. If the GC
needs to alter these two bits while the mutator(s) are running, the GC needs
to use CAS on the entire 32 bits of obj_info. Does this sound
A long, long time ago...
Craig Blake wrote:
Seems to me that you might want to be open to either using the
platform's threading when a platform has good scalability, and punt
and do it in VM when the platform doesn't offer it.
If it can be done then I am all for it. Once the Harmony VM
examine this today - is there any way to take advantage
of OS threading at all? How do you do thread management now?
Most likely the
merged/unified thread scheduler will be written in a type-safe
language such as Java. The interesting long term question is when
will the entire JVM be merge
, its likely to become
a bottleneck on tomorrow's multicore boxes.
So how do we examine this today - is there any way to take advantage
of OS threading at all? How do you do thread management now?
I can only speak for how ORP JVM was designed. THe short answer is,
yes, the JVM takes
threading model, where the VM scheduled its own
green threads on top of posix threads, and multiple posix threads were
supported. One view of this was that it was pointless to have more than
one posix thread per physical CPU (since multiple posix threads would
only have to time slice anyway). Under
El dom, 22-05-2005 a las 21:09 +1000, Steve Blackburn escribi:
Incidentally, this is a good example of where James Gosling misses
the
point a little: MITRE got involved in Jikes RVM not because it is
better than the Sun VM, but because it was OSS which meant they
could
fix a limitation
on posix style threads. Of course in that
case your scalability will largely depend on your underlying kernel
threads implementation.
Whether or not it's worth it depends on your needs. The lack of a
highly scalable threading model in the current popular VMs is the
reason why we have to use
of the key goals of the project was to achieve
much greater levels of scalability than the commercial VMs could deliver
(BTW, the project was then known as Jalapeno). The design decision
was to use a multiplexed threading model, where the VM scheduled its own
green threads on top of posix threads
as far as I know, most
VMs these days just rely on posix style threads. Of course in
that case your scalability will largely depend on your underlying
kernel threads implementation.
Whether or not it's worth it depends on your needs. The lack of a
highly scalable threading model
Seems to me that you might want to be open to either using the
platform's threading when a platform has good scalability, and punt
and do it in VM when the platform doesn't offer it.
If it can be done then I am all for it. Once the Harmony VM becomes
modular it is something that can
On May 22, 2005, at 2:59 PM, Craig Blake wrote:
Seems to me that you might want to be open to either using the
platform's threading when a platform has good scalability, and
punt and do it in VM when the platform doesn't offer it.
If it can be done then I am all for it. Once
). The design decision
was to use a multiplexed threading model, where the VM scheduled its own
green threads on top of posix threads, and multiple posix threads were
supported. One view of this was that it was pointless to have more than
one posix thread per physical CPU (since multiple posix
Just out of curiosity, can anyone familiar with the various OSS VM
implementations being discussed share their insights regarding the
respective threading capabilities? I have heard of some commercial
specialty VMs handling upwards of 30,000 concurrent threads easily
and it would
79 matches
Mail list logo
