On 11/7/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
please see the following JIRA issue for the missing function:
http://issues.apache.org/jira/browse/HARMONY-2086
Nik.
On 11/7/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
While I'm not familiar with j.u.concurrent build infrastructure
While I'm not familiar with j.u.concurrent build infrastructure, but
the issue about missing native function is known and I'll file a jira
and provide a fix today.
Nik.
1) Natives are missing. In particular,
java.util.concurrent.atomic.AtomicLong.VMSupportsCS8 looks like should be
implemented
please see the following JIRA issue for the missing function:
http://issues.apache.org/jira/browse/HARMONY-2086
Nik.
On 11/7/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
While I'm not familiar with j.u.concurrent build infrastructure, but
the issue about missing native function is known
Let me answer for Artem :), he is on vacation and most probably won't
answer soon.
We do occasionally use GCv4 to verify some threading issues, since
native threading resource allocation depends on weak references.
Thus I would agree with Ivan, that sometimes it is helpful to switch
to different
Hello,
this is legacy thread structure. You're right, there was no HyThread
at first, but VM_thread structure. Also different DRLVM modules used
to have dedicated fields in this structure. Further it was decided to
make threading module independent and make usage model of threading
module the
in
VM_thread block, and maybe the VM_thread block will be replaced by TLS in
HyThread, right?
Bin
- Original Message -
From: Nikolay Kuznetsov [EMAIL PROTECTED]
To: harmony-dev@incubator.apache.org
Sent: Monday, October 30, 2006 9:13 PM
Subject: Re: [drlvm] what's the difference between
Hello All,
in general we do not have any objections to implement such
functionality, but as far as I understand this will be quite unique TM
feature (no other threading library have this, or give me a link)
which is intended to improve performance. And if we going to extend TM
interface for
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
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)
Hello All,
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.
1) I found that
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
I have a quick note about detaching current thread. I've filled
HARMONY-1816 issue about counting non daemon threads. And concerning
DetachCurrentThread we should either detach it or rewrite
wait_for_all_nondaemon threads to take into account the fact that main
thread is also non daemon.
Nik.
On
Evgueni,
On 10/11/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
I have a quick note about detaching current thread. I've filled
HARMONY-1816 issue about counting non daemon threads. And concerning
DetachCurrentThread we should either detach it
I don't understand your concern what should
thread with appropriate subject. It seems to be
out of current topic.
Evgueni
On 10/11/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
Evgueni,
On 10/11/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
I have a quick note about detaching current thread. I've filled
HARMONY-1816 issue about
, j.l.ThreadTest
Thank you.
Nik.
On 10/9/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
I'm running debug build on WinXP, and I have following results so far:
c_unit tests passed;
smoke tests passed except gc.Los which hangs as usual;
kernel tests works with the following success rates:
Jet
are:
j.l.ObjectTest, j.l.RuntimeTest2, j.l.ThreadTest
Thank you.
Nik.
On 10/9/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
I'm running debug build on WinXP, and I have following results so far:
c_unit tests passed;
smoke tests passed except gc.Los which hangs as usual;
kernel tests
to this bug. I
updated H-1789 with instructions how to reproduce this.
On 10/10/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
Elena,
thanks for the help, the problem discovered by ThreadTest explained in
HARMONY-1789.
Are you going to fix the issue or investigate test failures?
Thank you.
Nik
Evgueni,
according to the spec the thread wait method should throw interrupted
exception even if it was interrupted before call.
citing from the Object.wait method specification:
Throws:
InterruptedException - if another thread interrupted the current
thread before or while the current thread
:
Ok, I see. Then it should be TM problem right?
On 10/9/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
Evgueni,
according to the spec the thread wait method should throw interrupted
exception even if it was interrupted before call.
citing from the Object.wait method specification
Jr. [EMAIL PROTECTED] wrote:
Ok - I just committed 1582. Lets build on it... can someone test on
winxp? I'll get to it in a bit, but would be happy to know sooner than
later.
Evgueni Brevnov wrote:
Ok, I see. Then it should be TM problem right?
On 10/9/06, Nikolay Kuznetsov [EMAIL
Salikh,
out of curiosity, do you know why it happens that Intel Compiler
requires librt at build time to resolve symbols in run time, while gcc
works fine w/o this option.
Also parent system libset contains librt, but not being forwarded to
hythread (due to ant bug I believe), but if just copy
Fixed, patch submitted to JIRA. Thread constructor used to initialize
main thread simply didn't set alive status. This patch also corrects
main thread's name and sets context class loader to SystemClassLoader.
Thank you.
Nik.
On 9/22/06, Elena Semukhina [EMAIL PROTECTED] wrote:
Kernel test
Hello,
I was able to run ActiveQM on Linux with patch attached. Looks like
something is broken in logger static initialization sequence. Though
this patch helpps in running ActiveQM, I would treat this patch as
workaround, this issue requires some more analysis and testing.
Nik.
On 9/22/06,
at the fact that global isn't set...or tell me why it
shouldn't be
geir
On Sep 22, 2006, at 1:51 PM, Nikolay Kuznetsov wrote:
Hello,
I was able to run ActiveQM on Linux with patch attached. Looks like
something is broken in logger static initialization sequence.
Though
this patch
Yes, I've seen the same, please keep us informed if you find a solution.
On 9/23/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
GNU gdb 6.4
Attaching is ok, but it is not quite convinient to do attaching when
running small test, I prefer: gdb --args prog args... but it no longer
works for me after
Ok then, it was suse 9, ia32.
On 9/23/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
what platform? I'm not seeing that...
On Sep 22, 2006, at 4:01 PM, Nikolay Kuznetsov wrote:
core dumps in debug and prints something like this in release:
WARN DefaultJDBCAdapter - Could
Hello Spark Shen,
It seems that Matcher.region(int, int) will not have any effects when
called. This can be demonstrated by the following test case
there is an issue quite similar to one you have raised filled by Richard:
http://issues.apache.org/jira/browse/HARMONY-759
I'll try to provide a
Richard,
We have two issues here:
[688] java.util.regex.Matcher does not support Unicode supplementary characters
[696] Harmony regex does not support Character.isXXX character classes
I would prefer, if you don't mind, to fix them separately. I know that
supplementary character support is a
Unfortunately, I can provide some test cases to demonstrate other
constructs, such as X{n}, DO support supplementary characters. But I'm
not sure if other constructs need special processing.
OK, I see, I'll provide general support for supplementary characters,
instead of patching some special
Hello Richard,
Thanks for pointing this out. While implementing java character
classes I missed the fact that _all_ Character.isXXX methods except
deprecated should have corresponding \\p{javaXXX} character class
analogues. So the the answer to your question whether we should
implement javaDigit
Hello Richard,
Thank you for this find. For some reason I've missed these character classes.
Will update JIRA issue in a moment.
--
Regards,
Nikolay Kuznetsov,
Intel Middleware Products Division
-
Terms of use : http
Done.
Nikolay,
please provide a single patch that resolves the problem
Thanks,
Mikhail
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Yes, I saw that too, and I agree that it makes it virtually impossible
to see exactly what was changed. I used a windows machine to apply your
patch and commit the code, so I can only assume that's why the file was
converted to DOS EOL.
I'll poke around to see if I can make it preserve the
Actually, you need to set 2 properties:
svn:mime-type : text/plain
svn:eol-style : native
It depends a lot from the svn client, though. I tried this, but in my
case files are returning from repository in the format they are stored
in repository.
Thanks a lot for the comment, I'll try to use
there are exceptions which are not
stated in javadoc, but those exceptions should be checked on case by
case basis.
Also I think that exact checks for null arguments are not necessary
(except those cases when they have special meaning) and moreover could
cause performance impact.
--
Nikolay Kuznetsov,
Intel
=${OS.any.match}/
/not
Thank you.
Nikolay Kuznetsov
Intel Middleware Products Division
37 matches
Mail list logo
