unsubscribe
begin:vcard n:Juarez Martinez;Fco. Javier x-mozilla-html:TRUE fn;quoted-printable:Fco. Javier Juá=3BrezeresMas Dpto Ingenieria y Desarrollo org:http://www.eresmas.com">http://eventos.eresmas.com/evento145/img/banner_eresmas.gif" border="0" alt="[eresMas]"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title: x-mozilla-cpt:;-1088 end:vcard
Has the ARM JDK1.3 port been completed yet?
Subject says it all - what is the status of the port? If no one is doing it, can anyone comment on the size of the task: what has to be done, if it is feasible for a couple of good SW engineers to knock over quickly? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thread.yield() on 2.4 - more (follow up)
On Sun, 11 Feb 2001, Dimitris Vyzovitis wrote: > > I'm not sure what you want to show with test_fairness. You have three > > threads which all count up to the same number. Then finally you print > > out the three counters which always will be the same. There's nothing > > in this code testing fairness of scheduling. > > Two things: first that all threads run equally often (this is the > farinees test, succeeds). Second, to illustrate that the behavior of the > vm changes substantially from the behavior observed in test_yield, in a > manner that appears to be inconsistent. > > > > > Dimitris> If you run test_yield with a longer sleep period, you'll > > Dimitris> notice that there is a dominant thread which gets approx > > Dimitris> as many runs as the other two. Although this does not > > Dimitris> violate the fairness conditions imposed by the jls, it > > Dimitris> is not quite what I expect given the perfectly fair > > Dimitris> behavior when no i/o is performed. > > > > Ah, fix test_fairness and you'll see that it isn't IO related. > > > > Dimitris> Once again, this is not a bug in the blackdown vm since > > Dimitris> it still satisfy the jls, but the behavior of ibm's vm > > Dimitris> is more *consistent*. > > > > [Actually, I would consider such a significant difference a bug.] > > > > As said in my previous posting: The difference you see is is not > > caused by scheduling and/or a specific Thread.yield() implementation. > > You just see a comparison of _interpreted_ vs _compiled_ code. > > Intersting of you to say. So, does the presence of the jitter modify vm > behavior so drastically? Isn't the bahavior of the vm without jit > inconsistent? I think that this deserves some more attention. doh! Revoke that - mea culpa. I was under the mistaken impression that two threads were running slowly, which seemed weird. Since only the fist one runs slowly, the discrepancy is obviously the matter of the jitter intervening in the second invokation of test_yield.run() and compiling for the last two threads (as you say above). Behavior is absolutely consistent, sorry for prolonging the discussion. -- dimitris mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Has the ARM JDK1.3 port been completed yet?
It's not JDK ... but I think I remember seeing reports that GCJ may be working on ARM. Unless you need Swing, check it out at http://gcc.gnu.org/java/ ... if it's not running on ARM, a couple good engineers should be able to make a solid dent in that problem! Evidently the "libffi" support (in bytecode interpreter) needs some work yet. - Dave - Original Message - From: "Tim Lindquist" <[EMAIL PROTECTED]> To: "Java-Linux Blackdown Mailing List" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, February 12, 2001 2:38 AM Subject: Has the ARM JDK1.3 port been completed yet? > Subject says it all - what is the status of the port? > > If no one is doing it, can anyone comment on the size of > the task: what has to be done, if it is feasible for a couple > of good SW engineers to knock over quickly? > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thread.yield() on 2.4 - more
Juergen Kreileder wrote:
>
>
> Please note that it is perfectly legal with respect to the JLS to
> implement Thread.yield() as nop in JVMs based LinuxThreads. Actually
> it is not only legal, it's desirable to implement it as nop on JVMs
> that employ preemptive scheduling policies (especially on
> multiprocessor machines).
Look, if Thread.yield() is ever called by the programmer, he has a
reason for it.
In my case, I'm calling it because I want the thread handling the rmi
call to return before the thread that calls exit() calls exit() because
I don't want the client to get an EOFException. With the 2.2.15 kernel
it worked perfectly. With 2.4.0 it doesn't, and my clients are getting
EOFExceptions.
public void exit() throws RemoteException{
new Thread((new Runnable(){
public void run () { Thread.yield() ; System.exit(0); }
})).start(); //allow this method to end so the client doesn't get an
error.
}
>
> Given the loose semantics of Thread.yield(), it is merely a pure
> heuristic *hint* to the JVM. The JVM may interpret this hint in any
> way it likes.
May doesn't mean should. I imagine the spec was so loose because it
could be expected that fine control over the threading might not be
available to the implementors of the jvm on every platform, not because
the writers of the spec didn't think Thread.yield() would be useful.
--
Joseph Shraibman
[EMAIL PROTECTED]
Increase signal to noise ratio. http://www.targabot.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Does jdb work on linux?
There are some 1.3 hotspot related jdb bugs for example the one listed below. If you happen to come across one I would recommend using the classic VM (jdb -classic) until those bugs are fixed regards calvin Joi Ellis wrote: > > On Sat, 10 Feb 2001, Jesus M. Salvo Jr. wrote: > > > I had more success with 1.2.2's jdb than those of 1.3 in debugging my > > apps. > > > > With 1.3's jdb ( using Sun and IBM's ), sometimes it hangs after 'run', > > sometimes at other points after 'cont', sometimes I can debug until I > > exit. > > > > With Blackdown's 1.2.2 jdb, so far, everything seems to work. > > > > I went hunting and found these disturbing reports: > > http://developer.java.sun.com/developer/bugParade/bugs/4369489.html > > (well, I was going to attach two more but they "aren't available at this time." > > I just allocated one vote on this one. > > -- > Joi EllisSoftware Engineer > Aravox Technologies [EMAIL PROTECTED], [EMAIL PROTECTED] > > No matter what we think of Linux versus FreeBSD, etc., the one thing I > really like about Linux is that it has Microsoft worried. Anything > that kicks a monopoly in the pants has got to be good for something. >- Chris Johnson > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thread.yield() on 2.4 - more
Joseph Shraibman wrote: > > Please note that it is perfectly legal with respect to the JLS to > > implement Thread.yield() as nop in JVMs based LinuxThreads. Actually > > it is not only legal, it's desirable to implement it as nop on JVMs > > that employ preemptive scheduling policies (especially on > > multiprocessor machines). > > Look, if Thread.yield() is ever called by the programmer, he has a > reason for it. Look, if the programmer uses Thread.yield() in a way it was not designed for than the reasons for it simply don't matter. It may have worked in some environments, but that does not mean you can expect all environments to work this way. > In my case, I'm calling it because I want the thread handling the rmi > call to return before the thread that calls exit() calls exit() because > I don't want the client to get an EOFException. With the 2.2.15 kernel > it worked perfectly. With 2.4.0 it doesn't, and my clients are getting > EOFExceptions. Yeah. So what? Do it right. "Java Thread Programming" by Paul Hyde describes possible (correct) solutions to your problem (the problem being "one thread needs to wait for another one to finish" if I interpret this correctly). Thread.yield() is not one of the correct solutions. Thread.yield() means "I have nothing to do right now, you may use the CPU for other purposes". Nothing more, especially no "you HAVE to use the CPU for..." . Ciao -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
System.exit() value not being observed with 1.3.0 FCS?
Hi,
looks like System.exit(1) doesn't cause the java executable to
terminate with an exit status of 1 with the Blackdown 1.3.0.
It works fine with the IBM 1.3.0, though. Here's my test program:
import java.io.*;
public class foo {
public static void main(String args[]) {
System.out.println("Failing...");
System.exit(1);
}
}
And here's the shell script I run it with:
#!/bin/sh
set -x
set -e
java foo
echo Hmm: exit status was $?
With Blackdown 1.3.0, I see
$ sh foo.sh
+ set -e
+ java foo
Failing...
+ echo Hmm: exit status was 0
Hmm: exit status was 0
$
which is incorrect, but with IBM, I see the expected
$ sh foo.sh
+ set -e
+ java foo
Failing...
$
I suppose this is an old known problem... any workaround?
- Dan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Does jdb work on linux?
On Mon, 12 Feb 2001, Calvin Austin wrote: > There are some 1.3 hotspot related jdb bugs for example the one listed > below. If you happen to come across one I would recommend using the classic > VM (jdb -classic) until those bugs are fixed Yes, I've seen those. However, I've tested Sun 1.2.2 for Linux, which doesn't have a native threads *or* a hotspot, and it fails there as well. I've gotten it to launch on simple test cases, but not ever on a real live project. :/ -- Joi EllisSoftware Engineer Aravox Technologies [EMAIL PROTECTED], [EMAIL PROTECTED] No matter what we think of Linux versus FreeBSD, etc., the one thing I really like about Linux is that it has Microsoft worried. Anything that kicks a monopoly in the pants has got to be good for something. - Chris Johnson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: System.exit() value not being observed with 1.3.0 FCS?
On Mon, 12 Feb 2001, Dan Kegel wrote: > Hi, > looks like System.exit(1) doesn't cause the java executable to > terminate with an exit status of 1 with the Blackdown 1.3.0. There is a bug open on this on Sun's BugParade. Some versions of the Linux pthreads library trigger issues when the thread which calls exit() is not the main() thread. I believe one of the comments at the end of the report mentioned the same problem is in BlackDown. http://developer.java.sun.com/developer/bugParade/bugs/4388732.html -- Joi EllisSoftware Engineer Aravox Technologies [EMAIL PROTECTED], [EMAIL PROTECTED] No matter what we think of Linux versus FreeBSD, etc., the one thing I really like about Linux is that it has Microsoft worried. Anything that kicks a monopoly in the pants has got to be good for something. - Chris Johnson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thread.yield() on 2.4 - more
> "Joseph" == Joseph Shraibman <[EMAIL PROTECTED]> writes:
Joseph> Juergen Kreileder wrote:
>> Please note that it is perfectly legal with respect to the JLS
>> to implement Thread.yield() as nop in JVMs based LinuxThreads.
>> Actually it is not only legal, it's desirable to implement it
>> as nop on JVMs that employ preemptive scheduling policies
>> (especially on multiprocessor machines).
Joseph> Look, if Thread.yield() is ever called by the programmer,
Joseph> he has a reason for it. In my case, I'm calling it
Joseph> because I want the thread handling the rmi call to return
Joseph> before the thread that calls exit() calls exit() because I
Joseph> don't want the client to get an EOFException. With the
Joseph> 2.2.15 kernel it worked perfectly. With 2.4.0 it doesn't,
Joseph> and my clients are getting EOFExceptions.
Joseph> public void exit() throws RemoteException{
Joseph> new Thread((new Runnable(){
Joseph> public void run () { Thread.yield() ;
Joseph> System.exit(0); }
Joseph> })).start(); //allow this method to end so the
Joseph>client doesn't get an
Joseph>error.
This is non-portable code. Thread.yield() is not an adequate tool for
this task. Your code makes several assumptions about the underlying
VM/OS implementation and configuration. It may work with a specific
setup but -- as seen -- may break if you change something: In your
case it's likely that some change in the new kernel changed timing
just a little bit and now your code fails.
>> Given the loose semantics of Thread.yield(), it is merely a
>> pure heuristic *hint* to the JVM. The JVM may interpret this
>> hint in any way it likes.
Joseph> May doesn't mean should. I imagine the spec was so loose
Joseph> because it could be expected that fine control over the
Joseph> threading might not be available to the implementors of
Joseph> the jvm on every platform, not because the writers of the
Joseph> spec didn't think Thread.yield() would be useful.
Actually Thread.yield() is useful, it was added for VMs which do not
use time-sliced preemptive scheduling, e.g. the classic green threads
VM.
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://www.blackdown.org/java-linux.html
JVM'01: http://www.usenix.org/events/jvm01/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: System.exit() value not being observed with 1.3.0 FCS?
I've seen this before on redhat 7.0 and it is logged on the redhat
bug page as a known bug, currently they had fixed it in 7.1 but have
not issued a patch to 7.0
RedHat bug Id: 23758
location: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=23758
The classic VM in 1.3 does return the expected result.
regards
calvin
Dan Kegel wrote:
>
> Hi,
> looks like System.exit(1) doesn't cause the java executable to
> terminate with an exit status of 1 with the Blackdown 1.3.0.
> It works fine with the IBM 1.3.0, though. Here's my test program:
>
> import java.io.*;
> public class foo {
> public static void main(String args[]) {
> System.out.println("Failing...");
> System.exit(1);
> }
> }
>
> And here's the shell script I run it with:
>
> #!/bin/sh
> set -x
> set -e
> java foo
> echo Hmm: exit status was $?
>
> With Blackdown 1.3.0, I see
>
> $ sh foo.sh
> + set -e
> + java foo
> Failing...
> + echo Hmm: exit status was 0
> Hmm: exit status was 0
> $
>
> which is incorrect, but with IBM, I see the expected
>
> $ sh foo.sh
> + set -e
> + java foo
> Failing...
> $
>
> I suppose this is an old known problem... any workaround?
> - Dan
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
4 alphaWorks XML Tool Updates, half-dozen leading XML editors, Transformusing XSLT and XPath, Relational database to XML, Why SOAP
<<0>>-<>-<>-<>-<<0>> XML developer resources written in Japanese Go to the developerWorks XML Zone to find XML development articles, white-papers, and tutorials written in Japanese. At the dW XML Zone You can get over 40 pieces of XML content that is Written in Japanese. dW Japan XML Zone - developer content written in Japanese http://www.alphaworks.ibm.com/aw.nsf/html/dW-Japan-XML?open&l=xmllst05,t=gr,p=Japan-XML <<0>>-<>-<>-<>-<<0>> Soapbox: Why I'm using SOAP In the XML zone's new opinion department, Benoît Marchal steps up on the soapbox to tell why SOAP is winning him over. SOAP's selling point is its simplicity, Marchal says. Because the new protocol builds on familiar technologies, in particular the Web server and XML, it's relatively easy for developers to design and deploy SOAP servers. Learn when its best to consider and use SOAP http://www-106.ibm.com/developerworks/library/x-soapbx1.html?open&l=xmllst05,t=gr,p=WHY-SOAP <<0>>-<>-<>-<>-<<0>> Transforming Python performance data This article covers how to use XML technologies to build a better profiling tool for Python programs. It also describes how to generate an XML call tree from collected profile data, including function call information, such as the number of calls and cumulative time spent in function calls. This article includes several examples with sample Code. Use XML and XSLT to devise a Python performance profiling tool http://www-106.ibm.com/developerworks/library/x-transpy/?open&l=xmllst05,t=gr,p=XML-XSLT-Python <<0>>-<>-<>-<>-<<0>> The Python Web services Developer, Part 1 Python's motto has always been "batteries included," referring to the large array of standard libraries and facilities that come with the language installation. This article presents an overview and survey of tools and facilities available for Web services development in Python. This includes built-in Python features and third-party open-source tools. Python tools for Web services http://www-106.ibm.com/developerworks/library/ws-pyth1.html?open&l=xmllst05,tp=WS-Python A useful overview of Web services, UDDI, and WSDL http://www-106.ibm.com/developerworks/library/ws-overview.pdf?open&l=xmllst05,p=WS-UDDI IBM XML and Web Services development environment http://www-106.ibm.com/developerworks/library/ibm-lunar.html?open&l=xmllst05,t=gr,p=WS-Dev <<0>>-<>-<>-<>-<<0>> Tutorial: Practical transformation using XSLT and XPath Transforming XML documents is one of the hottest topics in the XML community today. The most common transformation is converting an XML document, into HTML, however the World Wide Web Consortium (W3C) is currently working on two proposed standards for transforming XML documents: XSLT and XPath. This tutorial introductory version of Ken Holman's "Practical transformation using XSLT and XPath (XSL transformations and the XML Path Language) will help you understand these important standards efforts. Practical transformation using XSLT and XPath http://www-106.ibm.com/developerworks/education/xslt-xpath-tutorial.html?open&l=xmllst05,t=gr,p=Trans-XSLT-XPATH <<0>>-<>-<>-<>-<<0>> Portable database reporting using Java and XML This article explains how to generate printable reports from a database using Java- and XML-related technologies like Xalan, Xerces, and FOP. It demonstrates how Java and XML make it possible to develop reporting tools that work under different operating systems using the same source code. How to generate printable reports with Java, XML, and FOP http://www-106.ibm.com/developerworks/library/x-dbrep/?open&l=xmllst05,t=gr,p=XML-Database <<0>>-<>-<>-<>-<<0>> XML Structures for Existing Databases This book chapter, excerpted from the just-published Wrox Press book Professional XML Databases, offers clear, authoritative guidance for how to deal with an existing database that you need to move to XML, from modeling the tables and keys to dealing with orphaned elements. The chapter provides an overview of the issues involved and details 11 rules for creating XML data structures for data in a relational database. The article includes suggestions for creating data structures that can be processed rapidly. Used with the permission of the publisher. Eleven rules for moving a relational database to XML http://www-106.ibm.com/developerworks/library/x-struct/?open&l=xmllst05,t=gr,p=11Rules <<0>>-<>-<>-<>-<<0>> XML Matters #6 - A roundup of editors In this column David Mertz gives an up-to-date review of a half-dozen leading XML editors. He compares the strengths, weaknesses and capabilities of each -- especially for handling text-heavy prose documents. The column addresses the very practical question of just how one goes about creating, modifying, and maintaining prose-oriented XML documents. Review of a half-dozen leading XML editors http://www-106.ibm.com/developerworks/library/x-matters6.html?open&l=xmllst05,t=gr,p=XML-Editors <<0>>-<>-<>-<>-<<0>> alphaWorks XML Tools Updates XML Lightweight Extractor
