Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
It turned out that DRL implementation of hythread_monitor_init / hythread_monitor_init_with_name initializes and acquires a monitor. Eugeni, Both drlvm and classlib hythread work this way. This original hythread design that for compatibility reason was implemented in drlvm. Thanks Artem On 11/10/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hi, While investigating deadlock scenario which 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 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
Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
Oops, You were right. I take a llook into classlib hythread code. It looks like I incorrectly understand the documentation. This is a bug. Thanks Artem On 11/13/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Could someone familiar with classlib's implementation comment on that ? Thanks in advance. Evgueni On 11/13/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hello Artem, Are you 100% sure? I've looked at the classlib's implementation and can't find where the monitor is acquired. Moreover if you look at the initializeSignalTools() located in modules\portlib\src\main\native\port\linux\hysignal.c you will find that it initializes new monitors with hyhtread_monitor_init_with_name and never frees these monitors. That turned out to be the reason of a deadlock in HARMONY-2006. Thanks Evgueni On 11/13/06, Artem Aliev [EMAIL PROTECTED] wrote: It turned out that DRL implementation of hythread_monitor_init / hythread_monitor_init_with_name initializes and acquires a monitor. Eugeni, Both drlvm and classlib hythread work this way. This original hythread design that for compatibility reason was implemented in drlvm. Thanks Artem On 11/10/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hi, While investigating deadlock scenario which 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 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
[classlib][awt] AWT does not work without HARMONY-1823 (was: Re: [drlvm]Debug Error! dialog window occurs when running junit.awtui.TestRunner.
Commiters, AWT does not work at all, because of HARMONY-1823. The patch is ready for a week. there are a lot of messages on this list and duplicate issues on it. There are a lot of verification done. Could you please apply nterrupt_fix.patch and states.patch. The patch does not fix ALL problems in harmony but some of them. Thanks Artem On 10/20/06, Tim Ellison [EMAIL PROTECTED] wrote: Elena Semukhina wrote: I tried this patch too, it works! HARMONY-1916 can be closed as a duplicate. Marked as dupe. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][threadmanager] Fast thread local data access
Mikhail,
Right now the TM uses vm helper approach for the fast TLS access.
See vm/thread/src/thread_helpers.cpp:
fast_tls_func* get_tls_helper(hythread_tls_key_t key);
It looks reasonable for performance, to divide it in two part,
get_tls_pointer_accesor() and get_tls_storage_offset().
First one is already implemented but not added to interface:
/**
* Generates tmn_self() call.
* The code should not contains safepoint.
* The code uses and doesn't restore eax register.
*
* @return tm_self() in eax register
*/
char* gen_hythread_self_helper(char *ss) {
#ifdef FS14_TLS_USE
//ss = mov(ss, eax_opnd, M_Base_Opnd(fs_reg, 0x14));
*ss++ = (char)0x64;
*ss++ = (char)0xa1;
*ss++ = (char)0x14;
*ss++ = (char)0x00;
*ss++ = (char)0x00;
*ss++ = (char)0x00;
#else
ss = call(ss, (char *)hythread_self);
#endif
return ss;
}
It will be also good to make order on TLS usage
1. refactor HyThread-jit_private_data, to be usual TSL data.
2. add hythread_get_tls_suspend_request_offset function for JIT
back-branch polling.
3. refacor vm_get_gc_thread_local() to use hythread TLS directly.
I'm looking forward for a patch from you.
Thanks
Artem
On 10/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
All,
The TM architecture implies any component that needs to store threadlocal
data to reserve a slot:
extern HY_CFUNC IDATA VMCALL hythread_tls_alloc
PROTOTYPE((hythread_tls_key_t* handle));
The key can be used to get/set the allocated memory before its freed.
The problem is that JIT must know the final offset of the memory inside of
the TLS local struct to emit optimized code. The examples are: BBP, escape
analyzer, fast-helpers...
We can solve the task by adding this method to the TM interface:
size_t hythread_tls_get_storage_offset(hythread_tls_key_t handle);
Is it OK?
If yes, could I do this or anyone else wants to do it by himself?
--
Mikhail Fursov
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][threading] Is it safe to use hythread_suspend_all and hythread_resume_all?
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 suspend_all.
The bottom line is that to make the system easy to reason about, a
thread should always be in suspend_enable mode before it does anything that
might block.
We already talk about that in the top of the thread. I agree with
that, and will add some debug capacity to the TM.
Eugeny,
Actually, the code is not ideal, and there is a lot of things to do on it.
You could contribute you ideas into the code, and test them.
The suspend_all code contains a number of compromises that was
produced by different workloads and stress tests failures.
I attach patch that implement one of you ideas: to hold global thread
lock between
suspend_all / resume_all.
As I remember it could cause deadlock in JVMTI. Probably, something
change in mean time.
Thanks
Artem
Index: vm/thread/src/thread_native_suspend.c
===
--- vm/thread/src/thread_native_suspend.c (revision 464417)
+++ vm/thread/src/thread_native_suspend.c (working copy)
@@ -420,7 +420,7 @@
}
hythread_iterator_reset(iter);
-hythread_iterator_release(iter);
+//hythread_iterator_release(iter);
if(t)
{
*t=iter;
@@ -450,6 +450,8 @@
}
hythread_iterator_release(iter);
+hythread_iterator_release(iter);
+
return TM_ERROR_NONE;
}
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][threading] Infinite loop in atomic16_inc/atomic16_dec?
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 please file a JIRA issue with a patch. It looks reasonable to replace inc16 by inc32 as a fix. Thanks Artem On 10/19/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: 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 esp,0Ch movzx edx,ax -zero extention movsx eax,word ptr [old_value] sign extention cmp edx,eax je atomic16_inc+45h (10004A15h) 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? Thanks Evgueni - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][classlib] thread library - let there be one!
Angela, all, I see you point and agree. But if we move hythread lib to the VM we will require all VMs fully support it. Is it necessary dependency? So Here is the third way I see. Leave the minimum implementation of hythread in the classlib, with the set of functions any VM should provide for classlib. This will simplifies adopting classlib to new VM and allows to have solid threading model. So any VM could have its own super set of threading functions. Note: Classlib uses only monitor, TLS, and thread_create() from hythread. Thanks Artem On 10/18/06, Angela Lin [EMAIL PROTECTED] wrote: Artem et al, Sorry for jumping in late here. I maintain the J9VM thread lib. Option 1 worries me because it implies that the classlib could use a different threading model from the VM. This is bad because they both operate on the same threads. For example: Layer (2) of hythread might include internal thread state tracking, which is needed to support inspecting the thread state. Using layer (1) directly would bypass the thread state tracking. Angela On 10/16/06, Artem Aliev [EMAIL PROTECTED] wrote: Tim, Reading through discussion, I find two option for the second step. Let's discuss them. 1. - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and upper layer (hythead_xxx) - migrate classlib code to the bottom layer (1) of hythread Then move the rest of hythread to VM. In this case we will move all VM releated functionality out of a classlib. The classlib will use tls, mutex and thread_create from *.h files. VM will be free to implement threading in any way. 2. Move hythread out from the drlvm to a portlib. In this case classlib will contains a lot of only VM releated code. So we will meet the same problems with an new VM. But we will have common place for all synchronization primitives and could control them. Thanks Artem On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Tim Ellison wrote: First step (moving out of luni) looks good to me. I'd like some more discussion around the second step (picking up drlvm version) before you do a wholesale replacement. Yes please. Lets do small, reversible steps. geir Regards, Tim Weldon Washburn wrote: Artem, Thanks. I will take a look. On 10/12/06, Artem Aliev [EMAIL PROTECTED] wrote: Guys, 1. Make classlib/modules/portlib directory (or portlib in the root?) and move hyprt, hysig and hythread code into it. Update build to work with new directory. [Andrey]- pull out hythread from classlib, make it a shared component The first step is done in JIRA HARMONY-1843. I move common, pool, port, thread, sig from luni to new component portlib. The first idea was to move only port, thread, sig, but they depend on common and pool libs. It looks natural to do not produce cyclic dependencies among components, so I move these two also to portlib. Unfortunately, this does not fully solve two stage luni building process (build-native-core and build-native-secondary), but this is another problem. So If we are still committed on these reorganization, please review and apply the patch. A move_to_portlib.sh script create portlib directory structure and move appropriate files from luni to portlib (by svn move). A portlib_files.patch update build to works with new structure. Thanks Artem On 9/29/06, Artem Aliev [EMAIL PROTECTED] wrote: Guys, Let me try to make this changes. Here is my understanding of the steps I need to do. 1. Make classlib/modules/portlib directory (or portlib in the root?) and move hyprt, hysig and hythread code into it. Update build to work with new directory. [Andrey]- pull out hythread from classlib, make it a shared component 2. Move DRLVM hythread to classlib and update drlvm build for it. So both classlib and drlvm will work on the drlvm hythread. - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and upper layer (hythead_xxx) - migrate classlib code to the bottom layer (1) of hythread I do not think it is necessary because the hythread will be shared library. This make sense only in case we move only layer(1) into the shared directory. 3. merge hythreads into one library getting bast code from both sources. migrate DRLVM's thread manager to (1) from APR Will be done on this stage. 4. merge classlib and drlvm signal handling code. 5. merge port libs code. 6. Thanks Artem On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote: On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote: +1 on the below. I am assuming Andrey and his team will do this work. (Andrey, when will you
Re: [classlib][luni] signalis interruptus in hysock
Geir,
I create HARMONY-1904 issue for this case.
Thanks
Artem
On 10/17/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Artem Aliev wrote:
Gier,
I'd like to resurrect this topic.
Oh goody!
We try to run JBoss on Harmony and meet the same problem.
Here is an except from the stack trace:
java.net.SocketException: The call was cancelled
at
org.apache.harmony.luni.platform.OSNetworkSystem.availableStreamImpl(OSNetworkSystem.java)
at
org.apache.harmony.luni.platform.OSNetworkSystem.availableStream(OSNetworkSystem.java:216)
at
org.apache.harmony.luni.net.PlainSocketImpl.available(PlainSocketImpl.java:150)
at
org.apache.harmony.luni.net.SocketInputStream.available(SocketInputStream.java:50)
at
com.mysql.jdbc.util.ReadAheadInputStream.available(ReadAheadInputStream.java:212)
at com.mysql.jdbc.MysqlIO.clearInputStream(MysqlIO.java:774)
Actually, my old patch (attached) fix this problem too.
So could you please take a look at the patch one more time
or implement your fix for the availableStreamImpl() and other
functions that call
hysock_select().
Yes - that was something on my list. I knew that first iteration was
incomplete, but wanted to wait to see what happened. I still don't
agree that those low level calls should simply swallow the EINTR, but
let the higher levels in our 10,000 layer stack :) decide what to do.
Thanks
Artem
PS:
And one other comment on the proposed patch... it doesn't respect the
timeout as it restarts the select() with the original timeout..
# man select
On Linux, the function select modifies timeout to reflect the
amount of time not slept; most other implementations do not do
this. This causes problems both when Linux code which
reads timeout is ported to other operating systems, and when code is
ported to Linux that reuses a struct timeval for multiple
selects in a loop without reinitializing it. Consider timeout to
be
undefined after select returns.
PPS: FYI: the comments and revision for previous fix.
svn log modules/luni/src/main/native/luni/shared/socket.c
r441311 | geirm | 2006-09-08 04:51:36 +0400 (Fri, 08 Sep 2006) | 12 lines
modifications to hysock_select() to report when
interrupted, and then in pollSelectRead() in
socket.c for linux only to handle the
interrupt return code.
This passes all tests and also fixes the problem
with tomcat. I'd like to continue with the other
uses of hysock_select() in socket.c and elsewhere
but want to commit to let others review before
I go further
On 9/7/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
And one other comment on the proposed patch... it doesn't respect the
timeout as it restarts the select() with the original timeout...
Geir Magnusson Jr. wrote:
Weldon Washburn wrote:
On 9/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Artem Aliev wrote:
The hyport and hy* are a porting layer that provides os independent
interface.
hysock_select() does not return EINTR on windows why it should
do it
under linux?
either user presses Ctrl-c or ctrl-\ or VM uses other signals
for its
owns needs.
I think you just gave me the answer.
The *caller* to hysock_select() needs to decide what to do on
EINTR, not
hysock_select() itself.
I still don't think this is a perfect solution, but I think it's
better :)
Does the above solve the problem completely or is it a temporary
patch?
I don't know, but happy to call it a temporary patch - right now we're
stuck, because we can't even run tomcat and I want to do a new
snapshot.
Will the caller to hysock_select() need to have #ifdef Windows
#ifdef
Linux...?
We already have platform specific code that calls hysock_select()
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- modules/luni/src/main/native/port/linux/hysock.c
+++ modules/luni/src/main/native/port/linux/hysock.c
@@ -2570,11 +2570,16 @@ hysock_select (struct HyPortLibrary * po
I_32 rc = 0;
I_32 result = 0;
- result =
+ do
+ {
+result =
select (nfds, readfds == NULL ? NULL : readfds-handle,
writefds == NULL ? NULL : writefds-handle,
exceptfds == NULL ? NULL : exceptfds-handle,
timeout == NULL ? NULL : timeout-time);
+ }
+ while (result == -1 errno == EINTR);
+
if (result == -1)
{
rc = errno
Re: [drlvm] Thread me tender, thread me true, never throw an OOM...
Gier,
I do some experiments on this issue.
It is funny, but it is reproduced only by ubuntu user that logged to console.
It does not reproduce on SuSe at all.
Following sequence is more funny : ))
[EMAIL PROTECTED] java Test
fail ... on 370
[EMAIL PROTECTED] su - kna
[EMAIL PROTECTED] java Test
passed with 470
[EMAIL PROTECTED] su - ali
[EMAIL PROTECTED] java Test
passed with 470
I'll try to solve the mystery.
It could be a problem with freeing memory from dead threads and with
the linkage.
Attached build fix introduce -lpthread shared linkage. This allows
specify thread stack size in our VM (1M by default). thread count int
Test increase from 370 to 1000.
Thanks
Artem
On 17 Oct 2006 16:14:58 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x205 day of Apache Harmony Geir Magnusson, Jr. wrote:
So, with
public class Test implements Runnable {
static int i = 0;
public void run() {
try {
Thread.sleep(1);
} catch (Throwable e) { e.printStackTrace();
}
}
Test() {
new Thread(this).start();
}
public static void main(String args[]) {
for(;;) {
i++;
if (i % 1000 == 0) {
System.out.println(Iteration: + i);
}
new Test();
}
}
}
How far do you get? I get to 340... and then OOM. Why are threads so
heavy?
4435000 on SUSE9 with:
object_handles.cpp:270: ObjectHandlesNew*
oh_add_new_handles(ObjectHandlesNew**): Assertion `n' failed
Jrockit gave no more than 405000. Even more interesting...
--
Egor Pasko, Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: build/make/components/vm/vmcore.xml
===
--- build/make/components/vm/vmcore.xml (revision 464417)
+++ build/make/components/vm/vmcore.xml (working copy)
@@ -292,13 +292,6 @@
select os=lnx
syslibset type=shared libs=m,dl,stdc++,z,xml2,pthread,gcc_s,rt /
-linkerarg value=--export-dynamic /
-!--linkerarg value=-lz /
-linkerarg value=-lxml2 /
-linkerarg value=-lm /
-linkerarg value=-ldl /
-linkerarg value=-lpthread /
-linkerarg value=-lstdc++ /--
/select
/linker
/target
Index: build/make/components/vm/hythr.xml
===
--- build/make/components/vm/hythr.xml (revision 464417)
+++ build/make/components/vm/hythr.xml (working copy)
@@ -95,11 +95,11 @@
/select
select os=lnx
-syslibset libs=rt /
+syslibset libs=pthread,rt /
linkerarg value=-Wl,-init /
linkerarg value=-Wl,hythread_library_init /
linkerarg value=-Wl,--version-script,${src}/thread/src/hythr.exp /
-/select
+ /select
select os=win
syslibset libs=advapi32,ws2_32 /
Index: build/make/targets/common_vm.xml
===
--- build/make/targets/common_vm.xml (revision 464417)
+++ build/make/targets/common_vm.xml (working copy)
@@ -207,8 +207,8 @@
syslibset libs=advapi32,odbc32,userenv,ws2_32,mswsock /
/select
select os=lnx arch=ia32
-syslibset type=static libs=z,pthread,xml2 /
-syslibset type=shared libs=m,dl,stdc++,rt /
+syslibset type=static libs=z,xml2 /
+syslibset type=shared libs=m,dl,stdc++,rt,pthread /
/select
select os=lnx cxx=gcc arch=ia32
linkerarg value=-lgcc_s /
Index: build/make/targets/common_extra.xml
===
--- build/make/targets/common_extra.xml (revision 464417)
+++ build/make/targets/common_extra.xml (working copy)
@@ -46,8 +46,8 @@
syslibset libs=advapi32,odbc32,userenv,ws2_32,mswsock /
/select
select os=lnx
-syslibset type=static libs=z,pthread,xml2 /
-syslibset type=shared libs=m,dl,stdc++ /
+syslibset type=static libs=z,xml2 /
+syslibset type=shared libs=m,dl,stdc++,pthread /
/select
select os=lnx cxx=gcc
syslibset type=shared libs=gcc_s /
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Thread me tender, thread me true, never throw an OOM...
-Dvm.finalize=off also help :)
On 10/17/06, Weldon Washburn [EMAIL PROTECTED] wrote:
Geir,
I am running Test.java on windows with an svn revision from late last week.
Right now, it is at Iteration: 140 and still going. Because of MMTk
porting, GCV4.0 is configured in. Perhaps you can try with GCV4.0 to narrow
down where the bug is?
On 17 Oct 2006 16:14:58 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x205 day of Apache Harmony Geir Magnusson, Jr. wrote:
So, with
public class Test implements Runnable {
static int i = 0;
public void run() {
try {
Thread.sleep(1);
} catch (Throwable e) { e.printStackTrace();
}
}
Test() {
new Thread(this).start();
}
public static void main(String args[]) {
for(;;) {
i++;
if (i % 1000 == 0) {
System.out.println(Iteration: + i);
}
new Test();
}
}
}
How far do you get? I get to 340... and then OOM. Why are threads so
heavy?
4435000 on SUSE9 with:
object_handles.cpp:270: ObjectHandlesNew*
oh_add_new_handles(ObjectHandlesNew**): Assertion `n' failed
Jrockit gave no more than 405000. Even more interesting...
--
Egor Pasko, Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Weldon Washburn
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Gier,
I'd like to resurrect this topic.
We try to run JBoss on Harmony and meet the same problem.
Here is an except from the stack trace:
java.net.SocketException: The call was cancelled
at
org.apache.harmony.luni.platform.OSNetworkSystem.availableStreamImpl(OSNetworkSystem.java)
at
org.apache.harmony.luni.platform.OSNetworkSystem.availableStream(OSNetworkSystem.java:216)
at
org.apache.harmony.luni.net.PlainSocketImpl.available(PlainSocketImpl.java:150)
at
org.apache.harmony.luni.net.SocketInputStream.available(SocketInputStream.java:50)
at
com.mysql.jdbc.util.ReadAheadInputStream.available(ReadAheadInputStream.java:212)
at com.mysql.jdbc.MysqlIO.clearInputStream(MysqlIO.java:774)
Actually, my old patch (attached) fix this problem too.
So could you please take a look at the patch one more time
or implement your fix for the availableStreamImpl() and other
functions that call
hysock_select().
Thanks
Artem
PS:
And one other comment on the proposed patch... it doesn't respect the
timeout as it restarts the select() with the original timeout..
# man select
On Linux, the function select modifies timeout to reflect the
amount of time not slept; most other implementations do not do
this. This causes problems both when Linux code which
reads timeout is ported to other operating systems, and when code is
ported to Linux that reuses a struct timeval for multiple
selects in a loop without reinitializing it. Consider timeout to
be
undefined after select returns.
PPS: FYI: the comments and revision for previous fix.
svn log modules/luni/src/main/native/luni/shared/socket.c
r441311 | geirm | 2006-09-08 04:51:36 +0400 (Fri, 08 Sep 2006) | 12 lines
modifications to hysock_select() to report when
interrupted, and then in pollSelectRead() in
socket.c for linux only to handle the
interrupt return code.
This passes all tests and also fixes the problem
with tomcat. I'd like to continue with the other
uses of hysock_select() in socket.c and elsewhere
but want to commit to let others review before
I go further
On 9/7/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
And one other comment on the proposed patch... it doesn't respect the
timeout as it restarts the select() with the original timeout...
Geir Magnusson Jr. wrote:
Weldon Washburn wrote:
On 9/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Artem Aliev wrote:
The hyport and hy* are a porting layer that provides os independent
interface.
hysock_select() does not return EINTR on windows why it should do it
under linux?
either user presses Ctrl-c or ctrl-\ or VM uses other signals for its
owns needs.
I think you just gave me the answer.
The *caller* to hysock_select() needs to decide what to do on EINTR, not
hysock_select() itself.
I still don't think this is a perfect solution, but I think it's
better :)
Does the above solve the problem completely or is it a temporary patch?
I don't know, but happy to call it a temporary patch - right now we're
stuck, because we can't even run tomcat and I want to do a new snapshot.
Will the caller to hysock_select() need to have #ifdef Windows
#ifdef
Linux...?
We already have platform specific code that calls hysock_select()
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- modules/luni/src/main/native/port/linux/hysock.c
+++ modules/luni/src/main/native/port/linux/hysock.c
@@ -2570,11 +2570,16 @@ hysock_select (struct HyPortLibrary * po
I_32 rc = 0;
I_32 result = 0;
- result =
+ do
+ {
+result =
select (nfds, readfds == NULL ? NULL : readfds-handle,
writefds == NULL ? NULL : writefds-handle,
exceptfds == NULL ? NULL : exceptfds-handle,
timeout == NULL ? NULL : timeout-time);
+ }
+ while (result == -1 errno == EINTR);
+
if (result == -1)
{
rc = errno;
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][classlib] thread library - let there be one!
Tim, Reading through discussion, I find two option for the second step. Let's discuss them. 1. - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and upper layer (hythead_xxx) - migrate classlib code to the bottom layer (1) of hythread Then move the rest of hythread to VM. In this case we will move all VM releated functionality out of a classlib. The classlib will use tls, mutex and thread_create from *.h files. VM will be free to implement threading in any way. 2. Move hythread out from the drlvm to a portlib. In this case classlib will contains a lot of only VM releated code. So we will meet the same problems with an new VM. But we will have common place for all synchronization primitives and could control them. Thanks Artem On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Tim Ellison wrote: First step (moving out of luni) looks good to me. I'd like some more discussion around the second step (picking up drlvm version) before you do a wholesale replacement. Yes please. Lets do small, reversible steps. geir Regards, Tim Weldon Washburn wrote: Artem, Thanks. I will take a look. On 10/12/06, Artem Aliev [EMAIL PROTECTED] wrote: Guys, 1. Make classlib/modules/portlib directory (or portlib in the root?) and move hyprt, hysig and hythread code into it. Update build to work with new directory. [Andrey]- pull out hythread from classlib, make it a shared component The first step is done in JIRA HARMONY-1843. I move common, pool, port, thread, sig from luni to new component portlib. The first idea was to move only port, thread, sig, but they depend on common and pool libs. It looks natural to do not produce cyclic dependencies among components, so I move these two also to portlib. Unfortunately, this does not fully solve two stage luni building process (build-native-core and build-native-secondary), but this is another problem. So If we are still committed on these reorganization, please review and apply the patch. A move_to_portlib.sh script create portlib directory structure and move appropriate files from luni to portlib (by svn move). A portlib_files.patch update build to works with new structure. Thanks Artem On 9/29/06, Artem Aliev [EMAIL PROTECTED] wrote: Guys, Let me try to make this changes. Here is my understanding of the steps I need to do. 1. Make classlib/modules/portlib directory (or portlib in the root?) and move hyprt, hysig and hythread code into it. Update build to work with new directory. [Andrey]- pull out hythread from classlib, make it a shared component 2. Move DRLVM hythread to classlib and update drlvm build for it. So both classlib and drlvm will work on the drlvm hythread. - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and upper layer (hythead_xxx) - migrate classlib code to the bottom layer (1) of hythread I do not think it is necessary because the hythread will be shared library. This make sense only in case we move only layer(1) into the shared directory. 3. merge hythreads into one library getting bast code from both sources. migrate DRLVM's thread manager to (1) from APR Will be done on this stage. 4. merge classlib and drlvm signal handling code. 5. merge port libs code. 6. Thanks Artem On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote: On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote: +1 on the below. I am assuming Andrey and his team will do this work. (Andrey, when will you start?) We have to start first by pulling hythread out, but where? After thinking about it for 5 more seconds, putting it on the top level enhanced/something is IMO a bad idea. There's nothing worse than going to a project's SVN and finding tons of confusing things. I agree making thread a standalone component at the level of enhanced/something probably isn't worth doing. What may make a sense is to consider thread a part of the portlib and make the portlib a separate component at that level. Portlib is the only piece which is shared between VM and classlib, this could justify it's appearance at the high level. Is there any downside to keeping it somewhere under /classlib/trunk My only guess would be the inability to build VM independently from the classlib. Sure, you'll still need either to build the /portlib or the /classlib and simply make it a module by itself? If we can not have a portlib as a high level component (like classlib or drlvm), then at least having it as a separate module within classlib would be nice. This is one of those things where doing the small step (do it in classlib) and then consider the large step (do it as a peer) seems to be reasonable, but i don't feel too strongly... geir Thanks, Andrey. Hopefully we can clean up how drlvm handles
Re: [drlvm][threading] Possible race condition in implementation of conditional variables?
Weldon, Ok, I'll try to do something like you describe. But it is not very easy to do, I think. Thanks Artem 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 fact, the thread is in suspend enabled mode. If the thread is not, do something like a printf(WARNING: root set enumeration is unstable, hytsem.cpp line #285\n); Then do a non-destructive stack unwind and printf a stack trace An even better idea would be to log the printf's out to a file that can later be retrieved. 2) Second phase. Analyze the code paths that lead to the enable/disable problems. Are there fundamental design flaws? Implementation flaws? 3) Third phase. Assume the above turns up easy to fix bugs and minor architectural issues. And that these issues are settled. Then commit a mod to svn that will cause the system to do an assert(0); in debug mode and exit w/ stack trace in release mode. Artem, Does it make sense for you to create a patch that does the above?? On 10/13/06, Artem Aliev [EMAIL PROTECTED] wrote: A classloader and some other components assume that semaphores and latches does not reset suspend disable count and some time ago latches and semaphores work this way. A java monitor ,in reverse, resets the suspend disable status in monitorEnter and monitor_wait command, and DRLVM takes care 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. For example by putting assert(gc enabled == true() and checking failed places. Thanks Artem On 10/13/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: 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 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 mode and enables thread suspension. As a result GC can happen when it must not. hysem_wait is based on conditional variables so the same can happen when conditional variables is used. Do you see the problem here? Or I miss something? Thanks Evgueni - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][threading] Possible race condition in implementation of conditional variables?
A classloader and some other components assume that semaphores and latches does not reset suspend disable count and some time ago latches and semaphores work this way. A java monitor ,in reverse, resets the suspend disable status in monitorEnter and monitor_wait command, and DRLVM takes care 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. For example by putting assert(gc enabled == true() and checking failed places. Thanks Artem On 10/13/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: 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 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 mode and enables thread suspension. As a result GC can happen when it must not. hysem_wait is based on conditional variables so the same can happen when conditional variables is used. Do you see the problem here? Or I miss something? Thanks Evgueni - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][classlib] thread library - let there be one!
Guys, 1. Make classlib/modules/portlib directory (or portlib in the root?) and move hyprt, hysig and hythread code into it. Update build to work with new directory. [Andrey]- pull out hythread from classlib, make it a shared component The first step is done in JIRA HARMONY-1843. I move common, pool, port, thread, sig from luni to new component portlib. The first idea was to move only port, thread, sig, but they depend on common and pool libs. It looks natural to do not produce cyclic dependencies among components, so I move these two also to portlib. Unfortunately, this does not fully solve two stage luni building process (build-native-core and build-native-secondary), but this is another problem. So If we are still committed on these reorganization, please review and apply the patch. A move_to_portlib.sh script create portlib directory structure and move appropriate files from luni to portlib (by svn move). A portlib_files.patch update build to works with new structure. Thanks Artem On 9/29/06, Artem Aliev [EMAIL PROTECTED] wrote: Guys, Let me try to make this changes. Here is my understanding of the steps I need to do. 1. Make classlib/modules/portlib directory (or portlib in the root?) and move hyprt, hysig and hythread code into it. Update build to work with new directory. [Andrey]- pull out hythread from classlib, make it a shared component 2. Move DRLVM hythread to classlib and update drlvm build for it. So both classlib and drlvm will work on the drlvm hythread. - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and upper layer (hythead_xxx) - migrate classlib code to the bottom layer (1) of hythread I do not think it is necessary because the hythread will be shared library. This make sense only in case we move only layer(1) into the shared directory. 3. merge hythreads into one library getting bast code from both sources. migrate DRLVM's thread manager to (1) from APR Will be done on this stage. 4. merge classlib and drlvm signal handling code. 5. merge port libs code. 6. Thanks Artem On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote: On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote: +1 on the below. I am assuming Andrey and his team will do this work. (Andrey, when will you start?) We have to start first by pulling hythread out, but where? After thinking about it for 5 more seconds, putting it on the top level enhanced/something is IMO a bad idea. There's nothing worse than going to a project's SVN and finding tons of confusing things. I agree making thread a standalone component at the level of enhanced/something probably isn't worth doing. What may make a sense is to consider thread a part of the portlib and make the portlib a separate component at that level. Portlib is the only piece which is shared between VM and classlib, this could justify it's appearance at the high level. Is there any downside to keeping it somewhere under /classlib/trunk My only guess would be the inability to build VM independently from the classlib. Sure, you'll still need either to build the /portlib or the /classlib and simply make it a module by itself? If we can not have a portlib as a high level component (like classlib or drlvm), then at least having it as a separate module within classlib would be nice. This is one of those things where doing the small step (do it in classlib) and then consider the large step (do it as a peer) seems to be reasonable, but i don't feel too strongly... geir Thanks, Andrey. Hopefully we can clean up how drlvm handles the classlib portlib function table at the same time. Currently two versions of this table are created during startup. Portlib function table - let there be one! Seriously, this is incredibly difficult code to maintain. On 9/26/06, Tim Ellison [EMAIL PROTECTED] wrote: Yes, exactly. Regards, Tim Andrey Chernyshev wrote: On 9/26/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote: Weldon, I agree with your comments and observations below. Let's take baby steps to get fully unified. I'm sure we all want to keep things working throughout. So what's the first stop? Move hythread as-is out of classlib to a peer in the tree? I can suggest the following steps: - pull out hythread from classlib, make it a shared component - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and upper layer (hythead_xxx) - migrate classlib code to the bottom layer (1) of hythread - migrate DRLVM's thread manager to (1) from APR Each step can be done without breaking the whole code stack. As a result, we'll
Re: [drlvm][gc/threading] need the two lsb's from object header for MMTk port
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 the current state of the object header (object_info)
* (the second DWORD of any java object)
*
* Here is except form the object_layout.h:
* typedef struct ManagedObjectCompressedVtablePtr {
uint32 vt_offset;
uint32 obj_info;
*
* The obj_info(also known as obj_header, lockword) is mostly used
for java monitor implementation (22bit) in ThreadManager. The other 10
bits could be shared among other components.
* At this time, the vmcore uses 6 bits to store hash code, and GC
uses some bits for marking purposes.
*
* Because there are 3 component that share the same DWORD.
* Here is a rules for this header usage.
*
* Rationale:
* The monitor implementation uses CAS32 (lock cmpxcg) to set the LOCK_ID bits.
* (acquires lock). if LOCK_ID is equals THREAD_ID of the current thread,
* the dword is updated with regular store command (for example in
monitor exit)
* So to update the other header bits carefully anyone should follows
next rules:
*
* 1. All updates should be done in hythread_suspend_disable().
* Elsewhere the GC could move the object while you are preparing for
* writing.
* 2. It is safe to update the field in there stop_the_world_fase of GC
* (after hythread_suspend_all_threads() call). No one else
actives at that point.
* 3. It is safe to update, if the thread is the owner of the object monitor
*hythread_thin_monitor_get_owner(header_ptr) == hythread_self().
* 3a. The monitor owner could be suspended or monitor could be
acquired, before the update in case of 3.
* 4. If the monitor have been inflated to fat monitor,
*hythread will not update the header. So you could update it.
*is_fat_monitor(*header_ptr) == TRUE.
*
* 5. in case of 3 or 4, it is recommended to use CAS, because more
then one thread could still update the header.
* 6. if THREAD_ID==0, the monitor is not owned or reserved, CAS
should be used to update data.
*
*
*/
// the TM monitor implementation bits.
// 1100
#define LOCKWORD_MASK (0x ^ 0x3FF)
// THREAD_ID
#define THREAD_ID_MASK (0x)
// 6bit default hashcode
// 0110
// custom hashcode algorithm could free these bits
#define HASH_MASK 0x7e
// free bits for GC usage
// 0011 1001
#define GC_BIT_MASK (0x ^ (LOCKWORD_MASK | HASH_MASK))
Thanks
Artem
On 10/6/06, Weldon Washburn [EMAIL PROTECTED] wrote:
From reading current svn HEAD, it looks like thread_native_thin_monitor.c
reserves the bottom 10 bits of the object's lock word for object hashcode.
If this is true, I'd like to take the bottom two bits for MMTk port. Please
tell me what #defines I need to change to make this happen.
Thanks
--
Weldon Washburn
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Evgueni, 1) Which of the patches is a final? 2) It looks like you do not find a way to remove hythread_library_t from parameters and JavaVM from thread manager code. Well, leave it as is, I will try to fix this later. 2) Is the following global variable is necessary? extern hythread_library_t TM_LIBRARY; Thanks Artem - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Evgueni,
I got most of your changes, but still disagree with all
hythread/jthread interface changes. Could leave interface unchanged.
See following possible solutions, that could solve the same problems
without interface changes.
1) daemon attribute is a java specific. (Andrey mentioned this already).
Could you please move it back. to the jthread layer. It is better
to rename
hythread_wait_for_all_nondaemon_threads() to
jthread_wait_for_all_nondaemon_threads().
2) JavaVM could be retrieved from JNIEnv by jni_get_java_vm(). So
let the jthread_create() and others to use JNIEnv (that is passed from
java native method).
The vm_attach could get old JNI env and create new one for the new thread.
The first JNIEnv is created in CreateVM call and could be passed to
the first thread at startup.
4) Original classlib hythread do not use hythread_library_t in arguments,
It uses following code:
hythread_library_t lib = GLOBAL_DATA (default_library);
or
hythread_library_t library = thread-library;
So could you please use the same mechanism and remove hythread_*_ex functions.
5. You introduce more then one jni env, but still use global variable for it.
So all changes like following:
-JNIEnv *jenv = (JNIEnv*)jni_native_intf;
+JNIEnv *jenv = jni_native_intf;
should be like:
-JNIEnv *jenv = (JNIEnv*)jni_native_intf;
+JNIEnv *jenv = get_jni_env(jthread_self());
6). And small remarks:
+jint vm_init1(JavaVM_Internal * java_vm, JavaVMInitArgs * vm_arguments);
+jint vm_init2(JNIEnv_Internal * jni_env);
Could you make names more meaningful, then 1,2,3...?
class VM_thread {
...
+JNIEnv_Internal * jni_env;
The jthread already has the jni_env pointer, you do not need to
duplicate it here.
forexample by using jthread_get_JNI_env(jthread_self());
Thanks
Artem
On 9/28/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
I suppose two days silence means that there is no objects (maybe
interest) against proposed patch. I would suggest to commit it ASAP.
It really works! There are some cases when current VM crashes but the
patch fixes it. I can work on bringing cunit tests to live as soon as
the patch is committed This is just my understanding.
Thanks
Evgueni
On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
So where are we here?
On Sep 28, 2006, at 12:41 AM, Evgueni Brevnov wrote:
On 9/28/06, Weldon Washburn [EMAIL PROTECTED] wrote:
On 9/26/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
On 9/27/06, Andrey Chernyshev [EMAIL PROTECTED] wrote:
(3)
One more lock is added - hythread_lib_lock. How is that differ
from
the hythread_global_lock that we already have? Each extra lock
to the
system may add more possibilities for deadlocks, as well as can
negatively impact the scalability (unless some of the existing
locks
are split).
hythread_lib_lock acquires exactly the same lock as
hythread_global_lock. Probably I miss something but we need to be
compatible with IBM threading library now. This library has such
function. That's why I added it. Sounds right?
Well, this sort of, kind of sounds right but not quite. Its a
little more
subtle than being compatible with IBM threading library. The
first goal is
to identify the parts of IBM threading library that are JVM
independent. It
makes sense for DRLVM to be compatible with the independent
parts. This
should be a nobrainer.
The parts of IBM threading library that assume a specific JVM
implementation
will be a problem. We will need to find a solution that is
endorsed by all
the stakeholders (including J9 folks). The hythread_global_lock
falls into
this category. For starts, I would like to see a concise
description from
the portlib owners on what hythread_global_lock protects, which
locks have
to be held before grabbing this lock, are there any restrictions
on what
system calls can be made while holding this lock (like sleep or
wait), etc.
Weldon, I completely agree with what your are saying. It's common
problem of current hythread that should be resolved some how. I just
go inline with current implementation and added two missing functions.
Missing these can lead to the same problems as with hythread_exit
discussed in another thread [drlvm] [launcher] Executable hangs.
To get a better idea what's in the patch.diff, I printed it out.
Its 120+
pages. Quite a big patch! Most of it looks like straight forward
JNI
interface glue. There are some tricky parts. I would like to
know the
design review process for these parts. Using grep, I found 20
locations
where ...suspend_enable... and ...suspend_disable... have been
added. And
25 locations where enable/disable have been removed. Failure in
this logic
can lead to incorrect reference pointer enumeration. These are
probably the
hardest bugs to find. Please tell us who has looked at this code
in depth.
Only me and you :-) Honetsly I think it
Re: [drlvm][classlib] thread library - let there be one!
Guys, Let me try to make this changes. Here is my understanding of the steps I need to do. 1. Make classlib/modules/portlib directory (or portlib in the root?) and move hyprt, hysig and hythread code into it. Update build to work with new directory. [Andrey]- pull out hythread from classlib, make it a shared component 2. Move DRLVM hythread to classlib and update drlvm build for it. So both classlib and drlvm will work on the drlvm hythread. - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and upper layer (hythead_xxx) - migrate classlib code to the bottom layer (1) of hythread I do not think it is necessary because the hythread will be shared library. This make sense only in case we move only layer(1) into the shared directory. 3. merge hythreads into one library getting bast code from both sources. migrate DRLVM's thread manager to (1) from APR Will be done on this stage. 4. merge classlib and drlvm signal handling code. 5. merge port libs code. 6. Thanks Artem On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote: On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote: +1 on the below. I am assuming Andrey and his team will do this work. (Andrey, when will you start?) We have to start first by pulling hythread out, but where? After thinking about it for 5 more seconds, putting it on the top level enhanced/something is IMO a bad idea. There's nothing worse than going to a project's SVN and finding tons of confusing things. I agree making thread a standalone component at the level of enhanced/something probably isn't worth doing. What may make a sense is to consider thread a part of the portlib and make the portlib a separate component at that level. Portlib is the only piece which is shared between VM and classlib, this could justify it's appearance at the high level. Is there any downside to keeping it somewhere under /classlib/trunk My only guess would be the inability to build VM independently from the classlib. Sure, you'll still need either to build the /portlib or the /classlib and simply make it a module by itself? If we can not have a portlib as a high level component (like classlib or drlvm), then at least having it as a separate module within classlib would be nice. This is one of those things where doing the small step (do it in classlib) and then consider the large step (do it as a peer) seems to be reasonable, but i don't feel too strongly... geir Thanks, Andrey. Hopefully we can clean up how drlvm handles the classlib portlib function table at the same time. Currently two versions of this table are created during startup. Portlib function table - let there be one! Seriously, this is incredibly difficult code to maintain. On 9/26/06, Tim Ellison [EMAIL PROTECTED] wrote: Yes, exactly. Regards, Tim Andrey Chernyshev wrote: On 9/26/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote: Weldon, I agree with your comments and observations below. Let's take baby steps to get fully unified. I'm sure we all want to keep things working throughout. So what's the first stop? Move hythread as-is out of classlib to a peer in the tree? I can suggest the following steps: - pull out hythread from classlib, make it a shared component - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and upper layer (hythead_xxx) - migrate classlib code to the bottom layer (1) of hythread - migrate DRLVM's thread manager to (1) from APR Each step can be done without breaking the whole code stack. As a result, we'll have a bottom part of hythread which will be shared between the classlib and DRLVM. Some additional steps could be: - pull the rest of the portlib out of the classlib, make it a shared component as well - migrate DRLVM to portlib Thanks, Andrey. geir Regards, Tim Weldon Washburn wrote: On 9/20/06, Tim Ellison [EMAIL PROTECTED] wrote: Artem Aliev wrote: Gier, The hythread is just most visible example. There are also signal handling problem. classlib hysig lib setup signal handlers and then drlvm overrides them by its owns. There are code duplication in classlib hyprt.dll drlvm port.lib: classlib/trunk/modules/luni/src/main/native/port vm/ port/src These three pair of components contains significant part of the system dependent code for both VM and CLASSLIB. I think, all this code naturally defines portlib component that could be shared between classlib and VMs. So, as a first step, we could move all this code in to the one place, name portlib to have three directories classlib
[drlvm] Please integrate HARMONY -1340.
Committers, Could you please integrate fix from: HARMONY -1340 Fix invalid assertion in thread_native_fat_monitor.c The patch is trivial. The assertion in the current code is incorrect, it check that monitor is entered not more then once (recursion_count 1) It was left in the code by mistake. The monitor recursion count could be any positive number (the number of nested monitorEnter calls). This assert happend quite often: in self hosting mode, and always on EM64T. Thanks Artem - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [launcher] Patch is available for harmonyvm.properties parsing
Alexey, Could you please put the patch again. I got following error when try to access it. HTTP Status 404 - Could not find specified attachment: /usr/local/tomcat/tomcat-jira/attachments/HARMONY/HARMONY-1376/12341371_H-1376.diff (No such file or directory) Thanks Artem On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ahh, thanks! :) On Sep 22, 2006, at 5:55 AM, Alexey Varlamov wrote: Dear comitters, Please find the patch attached to HARMONY-1376 which fixes number of issues with harmonyvm.properties: 1) Robust file parsing with any EOLs; 2) The buffer overflow; 3) Added support for %VM_DIR% tokens, now easy to add any others; 4) Command-line -Xbootclasspath: option now really overrides whole BCP. -- WBR, Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] Thread Manager jvmti related issues fixes (was: Re: [jira] Commented: (HARMONY-1421))
Ivan, We do a lot for this cyclic suspend problem, I hope we does it right. I think the problem is in typo that was done in last patch. Fix attached. Could you please verify it. I will also attach it to the HARMONY-1421 we already try to has global lock for suspend_other(). Here is a deadlock scenario: thread1:thread2 assert(hythread_is_suspend_enabled()); global_lock(); supend(thread2); global_unlock(); ... assert(hythread_is_suspend_enabled()); global_lock(); supend(thread1); global_unlock(); safe_point() // stop heresafe_point() // stop here Thanks Artem On 9/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: I have found one fundamental design flow in implementation of: hythread_suspend_other() hythread_suspend_all() The functions should be called only from suspend enabled state, because the should be itself a valid point of suspension to prevent deadlocks. The other problem is: hythread_suspend_other() should also utilize hythread_global_lock() as the hythread_suspend_all() do via hythread_iterator_create(), otherwise this two functions can deadlock either. I have made a patch, but the assertion for suspend_disable_count fails almost in every test. I'm continue hunting the bug. -- Ivan On 9/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Artem, it looks like two thread mutually suspended each other. This is only reproducible when jvmti.patch from the JIRA is applied. -- Ivan On 9/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: I have reproduced the problem with the stack trace same as reported by Gregory. Here is the stack trace of thread starting GC: #4 0xb7af84bc in sched_yield () from /lib/libc.so.6 #5 0xb7bd5efd in hythread_yield () at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_basic.c:296 #6 0xb7bd8360 in wait_safe_region_event (thread=0x863e470) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_suspend.c:226 #7 0xb7bd8580 in hythread_suspend_all (t=0xbfce15d4, group=0x0) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_suspend.c:401 #8 0xb6eb2872 in stop_the_world_root_set_enumeration () at /home/ivan/svn/drlvm/trunk/vm/vmcore/src/gc/stop_the_world_root_set_enum.cpp:89 #9 0xb6eb2b89 in vm_enumerate_root_set_all_threads () at /home/ivan/svn/drlvm/trunk/vm/vmcore/src/gc/stop_the_world_root_set_enum.cpp:141 #10 0xb6c845aa in enumerate_universe () at /home/ivan/svn/drlvm/trunk/vm/gc/src/collect.cpp:127 #11 0xb6c8584a in force_gc () at /home/ivan/svn/drlvm/trunk/vm/gc/src/collect.cpp:363 #12 0xb6c9503b in select_force_gc () at /home/ivan/svn/drlvm/trunk/vm/gc/src/selector.cpp:287 #13 0xb6c9007e in gc_force_gc () at /home/ivan/svn/drlvm/trunk/vm/gc/src/gc_for_vm.cpp:336 #14 0xb6e289e1 in Java_java_lang_VMMemoryManager_runGC () Two other threads: #3 0xb7be9704 in tm_tls_size () from /home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/default/libhythr.so #4 0xb7af84bc in sched_yield () from /lib/libc.so.6 #5 0xb7bd5efd in hythread_yield () at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_basic.c:296 #6 0xb7bd8360 in wait_safe_region_event (thread=0x805ce50) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_suspend.c:226 #7 0xb7bd83e0 in hythread_suspend_other (thread=0x805ce50) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_suspend.c:286 #8 0xb7bd8b22 in unreserve_lock (lockword_ptr=0xa65da07c) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_thin_monitor.c:168 #9 0xb7bd8ece in hythread_thin_monitor_try_enter (lockword_ptr=0xa65da07c) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_thin_monitor.c:313 #4 0xb7b792be in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #5 0xb7b76074 in _L_mutex_lock_150 () from /lib/libpthread.so.0 #6 0xb7fdb290 in fixup () from /lib/ld-linux.so.2 #7 0xb7bd79e4 in hymutex_lock (mutex=0x805d150) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_mutex.c:71 #8 0xb7bd6d29 in hythread_monitor_enter (mon_ptr=0x805d118) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_fat_monitor.c:95 #9 0xb7fc2fef in asynchSignalReporter () from /home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/libhyprt.so #10 0xb7bd67ca in thread_start_proc (thd=0x805f380, p_args=0x805f2e8) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_basic.c:704 #11 0xb7bdd386 in dummy_worker (opaque=0xfffc) at thread.c:138 #12 0xb7b74420 in
Re: [drlvm] is_name_lowercase() in natives_support.cpp
Geir,
The current DRLVM build is still failed.
I attach patch for the current state of VM.
Could you please apply it or commit new version of natives_support.cpp
Thanks
Artem
On 9/18/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Geir,
The DRLVM build is broken now on gcc3.3.3 (SUSE9):
build.native.cpp:
[cc] 135 total files to be compiled.
[cc] drlvm/vm/vmcore/src/util/natives_support.cpp: In
[cc]function `apr_dso_handle_t* natives_load_library(const
Index: vm/vmcore/src/util/natives_support.cpp
===
--- vm/vmcore/src/util/natives_support.cpp (revision 447423)
+++ vm/vmcore/src/util/natives_support.cpp (working copy)
@@ -203,7 +203,12 @@
char *localLibName = (char *) library_name;
NativeLibraryHandle returnCode = NULL;
-
+NativeLibInfo* pfound;
+NativeLibInfo* pinfo;
+NativeLibraryHandle handle;
+apr_status_t apr_status;
+Global_Env *ge;
+jint UNREF res;
#ifdef PLATFORM_NT
TRACE2(init, ### lib name = library_name);
@@ -221,7 +226,7 @@
jni_libs.lock._lock();
-NativeLibInfo* pfound = search_library_list(localLibName);
+pfound = search_library_list(localLibName);
if (pfound)
{
@@ -237,8 +242,7 @@
*just_loaded = true;
// library was not loaded previously, try to load it
-NativeLibraryHandle handle;
-apr_status_t apr_status = port_dso_load_ex(handle, localLibName,
+apr_status = port_dso_load_ex(handle, localLibName,
PORT_DSO_BIND_DEFER, jni_libs.ppool);
if (APR_SUCCESS != apr_status)
{
@@ -255,7 +259,7 @@
goto NATIVES_LOAD_LIBRARY_EXIT;
}
-NativeLibInfo* pinfo = (NativeLibInfo*)apr_palloc(jni_libs.ppool, sizeof(NativeLibInfo));
+pinfo = (NativeLibInfo*)apr_palloc(jni_libs.ppool, sizeof(NativeLibInfo));
if (NULL == pinfo)
{
apr_dso_unload(handle);
@@ -270,7 +274,7 @@
pinfo-handle = handle;
-Global_Env *ge = VM_Global_State::loader_env;
+ge = VM_Global_State::loader_env;
pinfo-name = ge-string_pool.lookup(localLibName);
pinfo-next = jni_libs.lib_info_list;
@@ -278,7 +282,7 @@
jni_libs.lock._unlock();
-jint UNREF res = find_call_JNI_OnLoad(pinfo-handle); // What to do with result???
+res = find_call_JNI_OnLoad(pinfo-handle); // What to do with result???
*pstatus = APR_SUCCESS;
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Hello, guys. Do not forgot about portability Hysock lib is a porting layer and it should work the same way on all platforms. The windows does not support signals at all So the porting layer should hide all OS depended signal processing including this select() problem. +1 to my patch. The patch removes implementation depended feature. The other question is how to interrupt read/select operations in hyport libraries. The close() operation as I remember interrupt read() operation but not interrupt select(). Select for example could be interrupted with special file that could be added to the file list. One more time: signals is not correct way because there is no signals under Win32 and there is no signals API in porting layer. Thanks Artem - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM][VM] set_hash_bits() in vmcore/src/thread/mon_enter_exit.cpp -- is it a bug or a feature?
Guys,
The problem looks much broader then just a hash code placing.
There is no common place that describe object header format and object
header sharing protocol.
There are 3 components that use object header together.
VMcore -- store VT pointer and hashcode
ThreadManager -- update lockword
GC -- tries to find unused bits for its own purpose
Different GC algorithms use different unused bits:
2-bits from aligned VT pointer,
move hashcode to the synthetic field and use last byte
truncate hashcode
So by moving hash_code() handling to GC and drop VT bit usage
scenario, you simplify the problem to GC- TM interaction but not solve
it.
We still need the protocol.
The other problem is the 64bit platforms.(for example EM64T).
It looks natural to have 64bit VT and lockword on such platforms
So we need not only sharing protocol bu also a more flexible object layout.
Thanks
Artem
PS:
At this time we have following 64bit object header fromat
| -- 32 bit ---|
Virtual Method Table pointer
|- 22bit ---|--10bit-|
Monitor lockword bits ^unused/hashcode/gc_bits
On 8/29/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
This is the GC_V4 specifics. It uses two bits of least significant
byte of the status word during GC, but it always return zeros to this
bits after GC.
Here is the atomic way to do the changes:
do {
unsigned char lsb = *P_HASH_CONTENTION(p_obj);
unsigned char new_lsb = lsb | hb;
unsigned char uptodate_lsb =
port_atomic_cas8(P_HASH_CONTENTION(p_obj), new_lsb, lsb);
while (lsb != uptodate_lsb);
BTW, atomic operations is only needed if GC wants to update those two
bits during mutator work. Otherwise, non-atomic operations is ok, as
the same value can be safely written to the same address by multiple
threads. This is one pros for moving this code to GC.
--
Ivan
On 8/28/06, Weldon Washburn [EMAIL PROTECTED] wrote:
While porting MMTk to harmony/drlvm, I hit an integration problem. It
could even be a bug. set_hash_bits() assumes the least significant
bit is zero. Assuming that the LSB can be owned by the garbage
collector for its purposes, set_hash_bits() will fail if the GC sets
this bit to one. Somehow I think the code should read the target
location, create the intended bit pattern before attempting to do the
atomic compare and swap. Currently the code assume the target CAS
location holds zero.
SInce I am working only in single thread right now, I hacked around
the problem with the below. Thoughts?
C:\t_harmony\drlvm\trunk\vm\vmcore\src\threadsvn diff mon_enter_exit.cpp
Index: mon_enter_exit.cpp
===
--- mon_enter_exit.cpp (revision 425482)
+++ mon_enter_exit.cpp (working copy)
@@ -368,7 +368,12 @@
hb = (23 HASH_MASK); // NO hash = zero allowed, thus hard map hb
= 0
to a fixed prime number
// don't care if the cmpxchg fails -- just means someone else already
set t
he hash
-port_atomic_cas8(P_HASH_CONTENTION(p_obj),hb, 0);
+//port_atomic_cas8(P_HASH_CONTENTION(p_obj),hb, 0);
+unsigned char lsb = *P_HASH_CONTENTION(p_obj);
+lsb = lsb 0x01; //wjw need to keep the LSB, its used by MMTk Garbage
Col
lector
+hb = hb | lsb;
+if ( (*P_HASH_CONTENTION(p_obj) HASH_MASK) == 0 ) // wjw non-atomic
hack
for now
+*P_HASH_CONTENTION(p_obj) = hb;
}
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Gier, That's crazy. This isn't an implementation dependent feature - it's a side effect. The standard says: It is implementation-dependent behaviour, not a side effect :) http://www.opengroup.org/onlinepubs/007908799/xsh/select.html ---quote begins [EINTR] The select() function was interrupted before any of the selected events occurred and before the timeout interval expired. If SA_RESTART has been set for the interrupting signal, it is implementation-dependent whether select() restarts or returns with [EINTR]. ---quote ends The key is that signals are an important part of Unix IPC - for example, what happens w/ a ctrl-c? Will these processes (yes, under linux, a thread is a process) quit? The hyport and hy* are a porting layer that provides os independent interface. hysock_select() does not return EINTR on windows why it should do it under linux? either user presses Ctrl-c or ctrl-\ or VM uses other signals for its owns needs. By the way It looks like hyport library try to provide portable interface for signal handling. So we handle the signals in OS independent way. It setups handler for the all commonly used signals with SA_RESTART flag. See classlib/modules/luni/src/main/native/port/linux/hysignal.c The drlvm override some of the handlers but also use the SA_RESTART. Thus signals should not interrupt system calls in hyport base implementations. So the patch should not provide other side effects. Thanks Artem On 9/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: Artem Aliev wrote: Hello, guys. Do not forgot about portability Hysock lib is a porting layer and it should work the same way on all platforms. The windows does not support signals at all So the porting layer should hide all OS depended signal processing including this select() problem. +1 to my patch. The patch removes implementation depended feature. That's crazy. This isn't an implementation dependent feature - it's a side effect. Sorry - this came across wrong. I was just kidding, (and in the lines below), but for a non-native english speaker, you might mis-interpret. The key is that signals are an important part of Unix IPC - for example, what happens w/ a ctrl-c? Will these processes (yes, under linux, a thread is a process) quit? I worry about this and other side effects by masking *all* signals like we'd be effectively be doing... The other question is how to interrupt read/select operations in hyport libraries. The close() operation as I remember interrupt read() operation but not interrupt select(). Select for example could be interrupted with special file that could be added to the file list. This is just getting worse and worse. One more time: signals is not correct way because there is no signals under Win32 and there is no signals API in porting layer. Right, but this isn't a feature we've put into the linux version, it's a side effect. Thanks Artem - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM][VM] -- which header bits are available for GC mark and GC forwarding use?
On 8/24/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Weldon, I have some information for this case. There bit layout was the following before new thread manager integration: object info word contains: 0 bit - available for GC 1-6 bits - object hashcode 7 bit - contention bit unused by TM, but used by GC_V4 8-31 bits - other thread manager's data I have some changes for this layout in the GC v4.1 patch. Patch introduces new GC interface function: gc_get_hashcode() If garbage collector exports that function it hash full management of all bits in the lowest byte of object info word, but it should provide implementation of identity hashcode for heap objects. If garbage collector doesn't have this function, the previous (described above) layout of bits will be used. -- Ivan On 8/24/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Weldon, the bits your mentioned are for obj_info. Vtable can't have its bits overloaded simply without special handling. Thanks, xiaofeng On 8/24/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 8/23/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Weldon, I experimented with last two bits for marking and forwarding without problem. I assume you are referring to the 2 lowest bits in the vtable pointer. The two lowest bits will step on the recursion mask in sync_bits.h... won't it? I am confused. It turns out that MMTk keeps the mark bits around even between GCs. Leaving an LSB of the vtable ptr set and then resuming application execution will surely cause a failure. Thus there needs to be a full time dedicated mark bit in the object header. This is in addition to the need for a forwarding bit. The GC_OBJECT_MARK_BIT_MASK is for obj_info field, not the vt field. ( So far as I experimented, it's only used for heap verification). Thanks, xiaofeng On 8/24/06, Weldon Washburn [EMAIL PROTECTED] wrote: Looking at drlvm/trunk, it looks like vmcore/include/sync_bits.h defines the use of *(ref_ptr +4) for 32-bit environment. Just guessing that #define BUSY_FORWARDING_OFFSET 0 is intended to tell the GC that it can use the least significant bit out of these four bytes. Is this correct? I would like to use this bit as an MMTk mark bit. Will this work? (Actually the name, BUSY_FORWARDING_OFFSET is probably not the best...) There is also a gc/src/gc_header.h file that contains, #define GC_OBJECT_MARK_BIT_MASK 0x80. This seems to step on top of sync_bits.h use of this area???Can I assume gc_header.h is incorrect? -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM][VM] -- which header bits are available for GC mark and GC forwarding use?
Weldon, There bit layout was the following before new thread manager integration: object info word contains: 0 bit - available for GC 1-6 bits - object hashcode 7 bit - contention bit unused by TM, but used by GC_V4 8-31 bits - other thread manager's data The new Thread Manager use only 10-31 bit for its own data. So you could also use 8-9 bits for GC purpose. These bits could be read any time, but modified only at GC stop the world phase, because they share a byte with a monitor recursion count and other bits. This byte is updated without a lock Thanks Artem - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] problem when TM patch applied
Gier,
The DRLVM uses SIGUSR2 in thread suspend algorithm.
hysock_select() returns EINTR error when the signal appears, and
Socket.accept() throws exception.
The New ThreadManager use thread_suspend() more extensively ( in lock
reservation algorithm). So the problem appears more frequently.
Following patch to hysock.c fixes the problem in hysock.
Probably classlib experts could provide better way to fix this problem.
--
Artem Aliev, Intel Middleware Products Division
--- modules/luni/src/main/native/port/linux/hysock.c
+++ modules/luni/src/main/native/port/linux/hysock.c
@@ -2570,11 +2570,16 @@ hysock_select (struct HyPortLibrary * po
I_32 rc = 0;
I_32 result = 0;
- result =
+ do
+ {
+result =
select (nfds, readfds == NULL ? NULL : readfds-handle,
writefds == NULL ? NULL : writefds-handle,
exceptfds == NULL ? NULL : exceptfds-handle,
timeout == NULL ? NULL : timeout-time);
+ }
+ while (result == -1 errno == EINTR);
+
if (result == -1)
{
rc = errno;
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][vm] Prerequisites for java.util.concurrent
Nathan, VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to a VM-specific API for atomic gets and sets. This API will need to be defined and then implemented by the various VMs. Many of the lock APIs also make use of this API. I have done some experiments with concurrent in DRLVM. So there are two kernel classes in the DRLVM that, probably, provide full set of VM dependent functionality required by util.concurrent. Both have special VM support. vm/vmcore/src/kernel_classes/javasrc/java/util/concurrent/locks/LockSupport.java -- park/unpark methods The special queue could be used in case you need to implement it in VM independent way. vm/vmcore/src/kernel_classes/javasrc/org/apache/harmony/util/concurrent/Atomics.java -- CAS operations on references, ints, longs etc. The methods are aware of internal object layout and reference format. VM independent implementation could be done base on java monitors, but it kills the idea of the util.concurrent. Thanks Artem Aliev Intel Middleware Product Division On 6/14/06, Nathan Beyer [EMAIL PROTECTED] wrote: I stubbed out the method in luni-kernel (as well as two other methods that were missing). I looked at DRLVM and it already has nanoTime implementation, but it's not using the method you mentioned. I took a peek at the JCHEVM/classlibadaptar, but I couldn't quite discern the various artifacts. -Nathan -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 6:34 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent Nathan Beyer wrote: snip Does this mean we can stub out the luni-kernel System and just get the VMs to implement it in their kernel classes using this method? That's what I was thinking, and we can implement it in the luni-kernel / classpathadapter as a reference for VMs if we so choose. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using APR for Harmony's native link to the OS?
I tried to create sub-pool for each object as workaround. This hits memory footprint and performance. You are correct about that. There is no free call. Memory can be either reused by calling apr_pool_clear or freed by calling apr_pool_destroy. Because for any IO system object (file, socket, mutex, etc.) you usually need some additional struct, the standard implementation look like: struct my_struct; my_struct = malloc(...); my_truct-fh = open(...) ... do something with object close(my_truct-fh); free(my_struct); With APR it would look like: struct my_struct; pool = apr_pool_create(...) my_struct = apr_palloc(pool, ...) my_truct-fh = apr_xxx_open(pool, ...) ... do something with object apr_xxx_close(my_truct-fh); apr_pool_destroy(pool); Since each created object has it's own cleanup function when calling apr_pool_destroyed all objects created with that pool will call it's cleanup functions, so there is no need to call the apr_xxx_close. I tried to do as you recommended: create pool for each portLib object. The only problem here is a memory footprint. Each apr_pool_create(...) allocates 8k memory: #define MIN_ALLOC 8192 Thus each portLib object costs 8k. I would be happy with at least SUGGGESTED_SIZE parameter in apr_pool_create() function. APR_DECLARE(apr_status_t) apr_pool_create_ex(apr_pool_t **newpool, apr_pool_t *parent, apr_abortfunc_t abort_fn, apr_allocator_t *allocator apr_size_t SUGGGESTED_SIZE Thank you, Artem Aliev Intel Middleware Products Division
Re: Using APR for Harmony's native link to the OS?
Hello, I did some experiments with developing harmony portlib over APR. The main problem for me is an APR memory model. It is well suitable only for transactions. There is no free() memory call. You could destroy only whole memory pool. This works well only for short living threads or tasks. This is typical for HTTP server, not Java application. (All apr_*_create functions require apr_pool_t* as argument) I tried to create sub-pool for each object as workaround. This hits memory footprint and performance. So APR memory model should be extended. For example portlib memory pools could be integrated into APR. The second problem is ugly Developing wrappers over wrappers. For example, a call stack for read() method will look like following, in case we will develop Portlib over APR: Java_java_io_FileInputStream_read() calls portlib-hyfile_read(portLib...) calls apr_file_read(apr_file, ...) calls read() system calls. If we change portlib interface to be apr compatible, call stack could be a little bit better: Java_java_io_FileInputStream_read(...) calls portLib-apr_file_read(portLib-files[fd], ...) calls read(...) system calls. And definitely we will need to add a lot of new functions into APR. Thank you, Artem Aliev Intel Middleware Products Division
Re: Using APR for Harmony's native link to the OS?
You can always still use plain old malloc(), right? Unfortunately, all apr_*_create functions require apr_pool_t* as argument. For example: APR_DECLARE(apr_status_t) apr_file_open(apr_file_t **newf, const char *fname, apr_int32_t flag, apr_fileperms_t perm, apr_pool_t *pool); APR_DECLARE(apr_status_t) apr_mmap_create(apr_mmap_t **newmmap, apr_file_t *file, apr_off_t offset, apr_size_t size, apr_int32_t flag, apr_pool_t *cntxt); APR_DECLARE(apr_status_t) apr_thread_mutex_create(apr_thread_mutex_t **mutex, unsigned int flags, apr_pool_t *pool); Thank you, Artem Aliev Intel Middleware Products Division
