From owner-freebsd-java Sun Dec 9 10:40:15 2001 Delivered-To: freebsd-java@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 8C12F37B405 for ; Sun, 9 Dec 2001 10:40:09 -0800 (PST) Received: from dhcp151-67-151-24.nt01-c3.cpe.charter-ne.com ([24.151.67.151]) by harrier.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 16D8rw-0006kU-00 for freebsd-java@freebsd.org; Sun, 09 Dec 2001 10:40:09 -0800 Received: by dhcp151-67-151-24.nt01-c3.cpe.charter-ne.com (sSMTP sendmail emulation); Sun, 9 Dec 2001 13:40:05 -0500 Date: Sun, 9 Dec 2001 13:40:05 -0500 From: Dylan Carlson To: freebsd-java@freebsd.org Subject: [newbeb@yahoo.com: Re: Java crashes on FreeBSD?] Message-ID: <20011209134005.C1480@absinthe> Reply-To: absinthe@pobox.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: Retrovertigo X-Editor: VIM - Vi IMproved 6.0 2001 Sep 26 http://www.vim.org/ Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello Am curious what, if anything (besides heap) are tuneable in the VM? Also if people should make any adjustments to the FreeBSD kernel when using the VM as a heavily-trafficked application server. I have made a few adjustments to the kernel, specifically NMBCLUSTERS ... but I would appreciate any advice that would allow our VMs to scale and perform better under FreeBSD. Wondering how many of you are using RMI and the 1.3.1 patchset 5 build under Tomcat 3.2.3? Would like to compare notes. As a third, but much less important question -- I have not had any luck trying to build a VM with native threads using the 1.3.1 port/patchset 5. Are there any instructions towards this? We would like to build a VM with native threads (even if it is "alpha-quality code") to test it running under Tomcat first, then our RMI apps second. Cheers, -- Dylan Carlson (absinthe@pobox.com) --qMm9M+Fa2AknHoGS Content-Type: message/rfc822 Content-Disposition: inline X-Apparently-To: damage_z@yahoo.com via web10407; 30 Nov 2001 13:19:43 -0800 (PST) X-RocketRCL: 2157;1;2937881039 Return-Path: X-Track: 1: 40 Received: from mx2.FreeBSD.org (EHLO mx2.freebsd.org) (216.136.204.119) by mta401.mail.yahoo.com with SMTP; 30 Nov 2001 07:22:02 -0800 (PST) Received: from hub.freebsd.org (hub.FreeBSD.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 1EB9C5596F; Fri, 30 Nov 2001 07:21:01 -0800 (PST) (envelope-from owner-freebsd-java@FreeBSD.ORG) Received: by hub.freebsd.org (Postfix, from userid 538) id B0FEE37B42A; Fri, 30 Nov 2001 07:20:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id DEB232E8012; Fri, 30 Nov 2001 07:20:50 -0800 (PST) Received: by hub.freebsd.org (bulk_mailer v1.12); Fri, 30 Nov 2001 07:20:50 -0800 Delivered-To: freebsd-java@freebsd.org Received: from web12902.mail.yahoo.com (web12902.mail.yahoo.com [216.136.174.69]) by hub.freebsd.org (Postfix) with SMTP id 4D84537B417 for ; Fri, 30 Nov 2001 07:20:32 -0800 (PST) Message-ID: <20011130152032.65495.qmail@web12902.mail.yahoo.com> Received: from [66.66.241.54] by web12902.mail.yahoo.com via HTTP; Fri, 30 Nov 2001 07:20:32 PST Date: Fri, 30 Nov 2001 07:20:32 -0800 (PST) From: Brian Lloyd-Newberry Subject: Re: Java crashes on FreeBSD? To: Brad Cox Cc: freebsd-java@freebsd.org In-Reply-To: <222D2DAF-E500-11D5-97CC-0005022D9F0A@virtualschool.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-java@FreeBSD.ORG List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Precedence: bulk --- Brad Cox wrote: > Problem is, the application are disappearing off the net every couple > of > days leaving no diagnostics to go by in the log files. ps ax shows > that > the whole VM disappears, not just jetty or the two applications. If a > > core file exists, I've not managed to find it. Is it possible that your application is throwing a run time exception that you are not logging or catching? We have had a problem with a JVM (not sure which one right now, but I could find out) where this issue was causing a silent death. The person who debugged this should be back in town this weekend, and I will ask him about it and try to let you know. > 1) Is the Linux 1.2.2 port thought to be stable on FreeBSD? Not on my machine. 4.4-RELEASE FreeBSD SMP > 2) Is reverting to JDK 1.1.8 likely to improve matters? > 3) Is upgrading to IBM 1.3.x likely to improve matters if I can > overcome the space problem somehow? I have severe problems with the IBM JDK locking or not exiting. I have only seen the behavior in ant builds right now, but I have not tried anything else that is heavy duty with it. My few tests with hello world applications (even multithreaded ones) couldn't replicate the behavior. I have spent too many hours playing with it to not try to warn you off. > 4) Does someone have a cron script handy that could restart jetty > as a workaround? > 5) Am on the wrong track altogether? I would suck it up and use 1.2.2 native on FreeBSD or possible 1.3 native (although I am not brave enough yet). You will be without JIT unless you install one, but that might cause problems for you as well (with space and possibly reliability). OpenJIT was pretty easy to install, IMHO. Good luck. -Brian ===== Brian S. Lloyd-Newberry Vertical Learning Curve Solutions newbeb@yahoo.com __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message --qMm9M+Fa2AknHoGS-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Sun Dec 9 14:27:59 2001 Delivered-To: freebsd-java@freebsd.org Received: from sonic.kks.net (sonic.kks.net [213.161.0.18]) by hub.freebsd.org (Postfix) with ESMTP id 6674837B416 for ; Sun, 9 Dec 2001 14:27:56 -0800 (PST) Received: from voyager.kksonline.com (5-51.ro.cable.kks.net [213.161.5.51]) by sonic.kks.net (Postfix) with ESMTP id 3B9B922C for ; Sun, 9 Dec 2001 23:28:07 +0100 (CET) Message-Id: <5.0.2.1.0.20011209232702.02cf15f0@sundance.kks.net> X-Sender: arozman@sundance.kks.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 09 Dec 2001 23:27:51 +0100 To: freebsd-java@FreeBSD.ORG From: Aleksander Rozman - Andy Subject: Re: DBMS and BSD Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Subject: Re: DBMS and BSD > >At 7.12.2001, you wrote: >>Hi all, >> >>I was wondering as to which DBMSes most of you were running on our >>kick-ass O/S. :) I have found it an unbelievable pain in the arse to run >>Oracle 8i, what with the severe lack of support. And so I would like >>some input concerning your trials and tribulations and successes >>regarding the DBMS you use in conjunction with the jdbc drivers and jdks >>available to us currently. >> >>So to put it simply: What dbms do you use and which drivers/jdks as well. >> >> >>Thanks so much for the help! >> >>-Mel My reply here: >Hi Mel ! > >I use PostgeSQL and I am very satisfied with how it works. I used versions >from 7.0.x to latest stable release which I think is 7.1.3. I use supplied >drivers from pgsql package, works like a charm... So far I haven't tried >my application on BSD since it's not finished, but I have java 1.3.1 >patchetset5 ready to start the work... So far I jdbc driver to access this >db from net and it works OK. > >Andy > > ************************************************************************** * Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie * * andy@kksonline.com * Sentinel, BH 90210, True's Trooper, * * andy@atechnet.dhs.org * Heller's Angel, Questie, Legacy, PO5, * * Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender * * ICQ-UIC: 4911125 ********************************************* * PGP key available * http://www.atechnet.dhs.org/~andy/ * ************************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Sun Dec 9 16:17:13 2001 Delivered-To: freebsd-java@freebsd.org Received: from web14303.mail.yahoo.com (web14303.mail.yahoo.com [216.136.173.79]) by hub.freebsd.org (Postfix) with SMTP id B6B3B37B405 for ; Sun, 9 Dec 2001 16:17:02 -0800 (PST) Message-ID: <20011210001702.10731.qmail@web14303.mail.yahoo.com> Received: from [203.94.135.34] by web14303.mail.yahoo.com via HTTP; Mon, 10 Dec 2001 00:17:02 GMT Date: Mon, 10 Dec 2001 00:17:02 +0000 (GMT) From: =?iso-8859-1?q?shanon=20loveridge?= Subject: jdk1.3.1p5 To: freebsd-java@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hey there all, I noticed that most of you seem to be running jdk1.3.1p5. I have just started using linux-jdk1.3.1 and it seems to be working fine. I was wondering if there are advantages with running jdk1.3.1p5 over the linux version. Thanks Shanon ________________________________________________________________ Nokia 5510 looks weird sounds great. Go to http://uk.promotions.yahoo.com/nokia/ discover and win it! The competition ends 16 th of December 2001. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Sun Dec 9 18:41:49 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id 4285237B417 for ; Sun, 9 Dec 2001 18:41:40 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16DGNu-0000qC-00; Sun, 09 Dec 2001 18:41:38 -0800 Date: Sun, 9 Dec 2001 18:41:38 -0800 To: shanon loveridge Cc: freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 Message-ID: <20011210024138.GA3148@gnuppy> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011210001702.10731.qmail@web14303.mail.yahoo.com> User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Dec 10, 2001 at 12:17:02AM +0000, shanon loveridge wrote: > Hey there all, > > I noticed that most of you seem to be running > jdk1.3.1p5. I have just started using linux-jdk1.3.1 > and it seems to be working fine. I was wondering if > there are advantages with running jdk1.3.1p5 over the > linux version. > > Thanks > > Shanon Maybe not presently, but... Yes, the native threaded version of the JVM will have the ability to exploit stuff like the Posix AIO API when it maps itself to NIO. This will allow it to have superior scalability over any kind of select()/poll() model over many thousands of idle FDs. Hopefully, those two systems will be conceptually compatible and the remapping of that IO event model will be straight foreword under FreeBSD. With SMPng lock granularity replacement and a new IO model I would expect it to be a very strong competitor to other server-side systems in the Unix and NT kernel based arenas. It's not clear if this group realizes the importance of this, but it's definitely one of my implicit goals when I started working on native threading in this community is to have world class IO event handling. The current FreeBSD port is missing the very important HotSpot compiler and other things necessary for it to be performance competitive with other Unix based JVMs, etc... Also, as a minor note, *cough*, native threading is a prerequist for the JCK (Java Certification Kit) tests so that the current JVM we're working on can legally be released to the general public. It's a bit frustrating in that it's not clear to me or that I'm not getting the necessary feedback from folks in the community that indicate that native threading is important both of these technically and legally reasons from the luke warm responses I get from folks. Ok, gonna watch some TV now. ;-) bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Sun Dec 9 19:36:41 2001 Delivered-To: freebsd-java@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id AEC5037B417 for ; Sun, 9 Dec 2001 19:36:38 -0800 (PST) Received: from dhcp151-67-151-24.nt01-c3.cpe.charter-ne.com ([24.151.67.151]) by swan.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 16DHF7-0001Jv-00; Sun, 09 Dec 2001 19:36:37 -0800 Received: by dhcp151-67-151-24.nt01-c3.cpe.charter-ne.com (sSMTP sendmail emulation); Sun, 9 Dec 2001 22:36:35 -0500 Date: Sun, 9 Dec 2001 22:36:35 -0500 From: Dylan Carlson To: Bill Huey Cc: shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 Message-ID: <20011209223635.A1152@absinthe> Reply-To: absinthe@pobox.com References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: absinthe@pobox.com Organization: Retrovertigo X-Editor: VIM - Vi IMproved 6.0 2001 Sep 26 http://www.vim.org/ Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bill Huey wrote: > that it's not clear to me or that I'm not getting the necessary feedback from > folks in the community that indicate that native threading is important > both of these technically and legally reasons from the luke warm responses > I get from folks. > I can speak only on behalf of me and the companies I try to deploy FreeBSD at as, in some cases, Java application servers -- native threading is *Very* important... and further I appreciate all the work you guys are doing towards this. I'd contribute directly to the project if I knew how, but, as it stands the best you can expect from me are bug reports when I find them. But rest assured there are a lot of us out here trying to run FreeBSD as a good Java platform, and we're actually doing it in production scenarios, despite the gap between BSD and Linux in this regard. But without HotSpot we can't scale as cheaply. Cheers, -- Dylan Carlson (absinthe@pobox.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Sun Dec 9 19:57:24 2001 Delivered-To: freebsd-java@freebsd.org Received: from daedalus.cs.brandeis.edu (daedalus.cs.brandeis.edu [129.64.3.179]) by hub.freebsd.org (Postfix) with ESMTP id 6E9C937B416 for ; Sun, 9 Dec 2001 19:57:18 -0800 (PST) Received: from localhost (meshko@localhost) by daedalus.cs.brandeis.edu (8.9.3/8.9.3) with ESMTP id WAA12246 for ; Sun, 9 Dec 2001 22:57:16 -0500 Date: Sun, 9 Dec 2001 22:57:16 -0500 (EST) From: Mikhail Kruk To: Subject: Re: jdk1.3.1p5 In-Reply-To: <20011209223635.A1152@absinthe> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm signing under each word Dylan wrote here; I completely agree with the importance of native threading (to the degree to which I can understand what it means :) I have a couple of questions which, I hope, might help me understand this better... so if you have a second please clarify it to me... a) How far is the port from HotSpot now that native threads are working (or almost working)? b) Is my understanding that Linux port still has "process per thread" model correct? c) FreeBSD native threads are not "process per thread", right? d) If c and d are more or less true, does it mean that we should see better performance/more robust threading on FreeBSD than on Linux as of patchset 6? Or will it really kick in only when kernel threads are fully implemented in 5.0? Sorry about my ignorance :/ > I can speak only on behalf of me and the companies I try to deploy > FreeBSD at as, in some cases, Java application servers -- native > threading is *Very* important... and further I appreciate all the work > you guys are doing towards this. > > I'd contribute directly to the project if I knew how, but, as it stands > the best you can expect from me are bug reports when I find them. > > But rest assured there are a lot of us out here trying to run FreeBSD as > a good Java platform, and we're actually doing it in production > scenarios, despite the gap between BSD and Linux in this regard. > > But without HotSpot we can't scale as cheaply. > > Cheers, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Sun Dec 9 20:35:19 2001 Delivered-To: freebsd-java@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 199E937B405 for ; Sun, 9 Dec 2001 20:35:17 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id VAA06335; Sun, 9 Dec 2001 21:35:07 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fBA4Z6R87474; Sun, 9 Dec 2001 21:35:07 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15380.15226.519960.559607@caddis.yogotech.com> Date: Sun, 9 Dec 2001 21:35:06 -0700 To: Bill Huey Cc: shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 In-Reply-To: <20011210024138.GA3148@gnuppy> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Also, as a minor note, *cough*, native threading is a prerequist for the > JCK (Java Certification Kit) tests so that the current JVM we're working on > can legally be released to the general public. Actually, this is not true. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Sun Dec 9 20:36: 4 2001 Delivered-To: freebsd-java@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 5BC5E37B419 for ; Sun, 9 Dec 2001 20:36:00 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id VAA06367; Sun, 9 Dec 2001 21:35:53 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fBA4Zqd87477; Sun, 9 Dec 2001 21:35:52 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15380.15272.167683.46148@caddis.yogotech.com> Date: Sun, 9 Dec 2001 21:35:52 -0700 To: absinthe@pobox.com Cc: Bill Huey , shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 In-Reply-To: <20011209223635.A1152@absinthe> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > that it's not clear to me or that I'm not getting the necessary feedback from > > folks in the community that indicate that native threading is important > > both of these technically and legally reasons from the luke warm responses > > I get from folks. > > > > I can speak only on behalf of me and the companies I try to deploy > FreeBSD at as, in some cases, Java application servers -- native > threading is *Very* important... and further I appreciate all the work > you guys are doing towards this. Why? The native threading that we're using now is no better/worse than the internal green threads implementation. Without kernel threads, native threads have *EXACTLY* the same sorts of problems that exist with green threads. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Sun Dec 9 21:32:17 2001 Delivered-To: freebsd-java@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 819A837B419 for ; Sun, 9 Dec 2001 21:32:15 -0800 (PST) Received: from dhcp151-67-151-24.nt01-c3.cpe.charter-ne.com ([24.151.67.151]) by hawk.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 16DJ2o-0002FW-00; Sun, 09 Dec 2001 21:32:02 -0800 Received: by dhcp151-67-151-24.nt01-c3.cpe.charter-ne.com (sSMTP sendmail emulation); Mon, 10 Dec 2001 00:32:00 -0500 Date: Mon, 10 Dec 2001 00:32:00 -0500 From: Dylan Carlson To: Nate Williams Cc: absinthe@pobox.com, Bill Huey , shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 Message-ID: <20011210003200.C1152@absinthe> Reply-To: absinthe@pobox.com References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: absinthe@pobox.com Organization: Retrovertigo X-Editor: VIM - Vi IMproved 6.0 2001 Sep 26 http://www.vim.org/ Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Nate Williams wrote: > Why? The native threading that we're using now is no better/worse than > the internal green threads implementation. Without kernel threads, > native threads have *EXACTLY* the same sorts of problems that exist with > green threads. First, I'll say that I know very little about all of this, comparatively speaking. My understanding is that native threads were not dependent on kernel threads; that is, native threads are there to, among other things, reduce I/O overhead. I understand as much to know that to go SMP inside of the Java VM requires kernel threads. But again, the way I understand it is that by talking to a VM built around pthreads, that some performance gains can be had. So I guess that (until SMPng becomes a reality) what I'm asking is whether a native VM build exists around pthreads. -- Dylan Carlson (absinthe@pobox.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Sun Dec 9 22:29:54 2001 Delivered-To: freebsd-java@freebsd.org Received: from mgr1.xmission.com (mgr1.xmission.com [198.60.22.201]) by hub.freebsd.org (Postfix) with ESMTP id 0629B37B41B for ; Sun, 9 Dec 2001 22:29:52 -0800 (PST) Received: from [207.135.128.145] (helo=misty.eyesbeyond.com) by mgr1.xmission.com with esmtp (Exim 3.22 #1) id 16DJwk-00032t-00; Sun, 09 Dec 2001 23:29:51 -0700 Received: (from glewis@localhost) by misty.eyesbeyond.com (8.11.6/8.11.6) id fBA6TlO73597; Mon, 10 Dec 2001 16:59:47 +1030 (CST) (envelope-from glewis) Date: Mon, 10 Dec 2001 16:59:47 +1030 From: Greg Lewis To: shanon loveridge Cc: freebsd-java@freebsd.org Subject: Re: jdk1.3.1p5 Message-ID: <20011210165947.B73467@misty.eyesbeyond.com> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011210001702.10731.qmail@web14303.mail.yahoo.com>; from shanon_loveridge@yahoo.co.uk on Mon, Dec 10, 2001 at 12:17:02AM +0000 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Dec 10, 2001 at 12:17:02AM +0000, shanon loveridge wrote: > I noticed that most of you seem to be running > jdk1.3.1p5. I have just started using linux-jdk1.3.1 > and it seems to be working fine. I was wondering if > there are advantages with running jdk1.3.1p5 over the > linux version. Depends what you consider an advantage :). Certainly if you want to do anything with JNI using the linux-jdk becomes a pain quickly. I'll leave others to comment on the general stability and bugginess of the two. I only really use the native version so I can't comment even handedly on both. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Phone : (801) 796 6999 Information Technology Web : http://www.eyesbeyond.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Sun Dec 9 22:46:33 2001 Delivered-To: freebsd-java@freebsd.org Received: from mgr1.xmission.com (mgr1.xmission.com [198.60.22.201]) by hub.freebsd.org (Postfix) with ESMTP id 399C137B405 for ; Sun, 9 Dec 2001 22:46:29 -0800 (PST) Received: from [207.135.128.145] (helo=misty.eyesbeyond.com) by mgr1.xmission.com with esmtp (Exim 3.22 #1) id 16DKCp-0004gK-00; Sun, 09 Dec 2001 23:46:27 -0700 Received: (from glewis@localhost) by misty.eyesbeyond.com (8.11.6/8.11.6) id fBA6kO873663; Mon, 10 Dec 2001 17:16:24 +1030 (CST) (envelope-from glewis) Date: Mon, 10 Dec 2001 17:16:23 +1030 From: Greg Lewis To: Bill Huey Cc: freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 Message-ID: <20011210171623.D73467@misty.eyesbeyond.com> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011210024138.GA3148@gnuppy>; from billh@gnuppy.monkey.org on Sun, Dec 09, 2001 at 06:41:38PM -0800 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Dec 09, 2001 at 06:41:38PM -0800, Bill Huey wrote: > On Mon, Dec 10, 2001 at 12:17:02AM +0000, shanon loveridge wrote: > Yes, the native threaded version of the JVM will have the ability > to exploit stuff like the Posix AIO API when it maps itself to NIO. This > will allow it to have superior scalability over any kind of select()/poll() > model over many thousands of idle FDs. Hopefully, those two systems will > be conceptually compatible and the remapping of that IO event model will > be straight foreword under FreeBSD. With SMPng lock granularity replacement > and a new IO model I would expect it to be a very strong competitor to other > server-side systems in the Unix and NT kernel based arenas. It's not clear > if this group realizes the importance of this, but it's definitely one of > my implicit goals when I started working on native threading in this community > is to have world class IO event handling. All else aside, if there are no native threads there is no JDK 1.4 port. If people don't think native threads are important, they should take some time to think about whether they want a JDK 1.4 port or not... :-) Maybe that may get through where more technical arguments fail :). > The current FreeBSD port is missing the very important HotSpot compiler and > other things necessary for it to be performance competitive with other Unix > based JVMs, etc... HotSpot is very very important. Its the performance piece we're lacking to get FreeBSD accepted as a really solid alternative for serving Java based web apps and the like. I _think_ that native threads may also be a prerequisite for HotSpot... I also think the browser plugin is important, but thats because the people I work for have a Java applet based product and 'cos it yanks my chain when I'm browsing with Mozilla :). Big vote of thanks to Joe for the progress he is making in that area. > Also, as a minor note, *cough*, native threading is a prerequist for the > JCK (Java Certification Kit) tests so that the current JVM we're working on > can legally be released to the general public. It's a bit frustrating in > that it's not clear to me or that I'm not getting the necessary feedback from > folks in the community that indicate that native threading is important > both of these technically and legally reasons from the luke warm responses > I get from folks. I can't comment for anyone else, but I apologise if you feel that you're getting luke warm responses about native threading. I'm aware of how important it is and appreciate how you've run with the ball on this! My part in this is to obviously get your patches out in a new patchset so we can get some more eyes and testers on this. Unfortunately I've had to work most of the weekend and haven't gotten a complete handle on things :(. Patchset 6 is still under production... -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Phone : (801) 796 6999 Information Technology Web : http://www.eyesbeyond.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Mon Dec 10 1:15:29 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id 4075F37B419 for ; Mon, 10 Dec 2001 01:15:27 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16DMWx-0001hE-00; Mon, 10 Dec 2001 01:15:23 -0800 Date: Mon, 10 Dec 2001 01:15:23 -0800 To: Greg Lewis Cc: Bill Huey , freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 Message-ID: <20011210091523.GA6505@gnuppy> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011210171623.D73467@misty.eyesbeyond.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011210171623.D73467@misty.eyesbeyond.com> User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Dec 10, 2001 at 05:16:23PM +1030, Greg Lewis wrote: > HotSpot is very very important. Its the performance piece we're lacking > to get FreeBSD accepted as a really solid alternative for serving Java > based web apps and the like. I _think_ that native threads may also > be a prerequisite for HotSpot... All I saw was a synchronization class in pthreads, but not green, so I'm assuming you have to have a fully working native threading layer before you can do HotSpot. > My part in this is to obviously get your patches out in a new patchset > so we can get some more eyes and testers on this. Unfortunately I've It's pre-alpha quality at this time and won't be ready for beta until I fix the pthreads issue(s). > had to work most of the weekend and haven't gotten a complete handle > on things :(. Patchset 6 is still under production... Sure, do what you must. It was strange that I got a lack of response from the community in general about this topic, which is why I thought people's largely casual reaction to it was bizzare in recently interactions. (/me shakes head) I'm debugging my pthreads changes now and will post it when it's ready. ;-) bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Mon Dec 10 2:43:19 2001 Delivered-To: freebsd-java@freebsd.org Received: from puget.esil.univ-mrs.fr (puget.esil.univ-mrs.fr [139.124.41.103]) by hub.freebsd.org (Postfix) with ESMTP id C7F6F37B417 for ; Mon, 10 Dec 2001 02:43:13 -0800 (PST) Received: from localhost (hquiroz@localhost) by puget.esil.univ-mrs.fr (8.11.6/8.11.6) with ESMTP id fBAAngl99983 for ; Mon, 10 Dec 2001 11:49:50 +0100 (CET) (envelope-from herve.quiroz@esil.univ-mrs.fr) X-Authentication-Warning: puget.esil.univ-mrs.fr: hquiroz owned process doing -bs Date: Mon, 10 Dec 2001 11:49:41 +0100 (CET) From: Herve Quiroz X-X-Sender: hquiroz@puget.esil.univ-mrs.fr To: java@freebsd.org Subject: Proposal for bsd.java.mk Message-ID: <20011210113932.L99945-100000@puget.esil.univ-mrs.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org A few questions... Does the USE_JAVA variable stand for "requires a JDK/JRE to build" or "requires a JDK/JRE to run" ? Do you plan do make any difference ? Also I don't understand the meaning of the JAVA_LIB variable. Is this really needed by any port so far ? It would be needed if using any third party compiler such as jikes but in that case the user would have (hopefully) set the JIKESPATH. Anyway I think there should be an unified way to deal with JAVA_LIB/JIKESPATH etc so maybe the port being installed should handle this additional CLASSPATH. This way, installing any lib would also mean its jar would be added in the classpath automatically. Herve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Mon Dec 10 5:13: 3 2001 Delivered-To: freebsd-java@freebsd.org Received: from heimdall.inter.net.il (heimdall.inter.net.il [192.114.186.17]) by hub.freebsd.org (Postfix) with ESMTP id 4ADE237B41E for ; Mon, 10 Dec 2001 05:12:53 -0800 (PST) Received: from 212.143.60.130 (ADSLT1-KY-p130.adsl.netvision.net.il [212.143.60.130]) by heimdall.inter.net.il (Mirapoint) with SMTP id BCB87855; Mon, 10 Dec 2001 15:08:02 +0200 (IST) From: Message-ID: <00006fad3e56$00006d8a$00000473@212.143.60.130> To: Subject: Global Terror Relief Date: א, 09 דצמבר 2001 21:03:26 -1200 X-Priority: 3 X-MSMail-Priority: Normal Reply-To: shim4467@hotmail.com Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "The International comunity is mourning the loss of our brothers and sisters," The Global Terror Relief Establishes Charity Fund Sept. 13, 2001, 10a.m. -- In the wake of Tuesday's tragedy, The Global Terror Relief is preparing to send financial assistance to the families of all fallen victoms. The Global Terror Relief Fund urges all those concerned throughout the world who wish to support the World Trade Center emergency response and victim support effort to make a contribution to the newly established Global Terror Relief Fund. The purpose of the Global Terror Relief Fund is to assist the families and dependents of the victims of the September 11th terrorist attacks. This fund is for the benefit of all victims both injured and deceased, including innocent civilians. After the needs of these people have been addressed, consideration may be given to other related relief and recovery expenses. Contributions may also be sent to: The Global Terror Relief Fund 163 3rd Avenue No.269 New York, NY, 10003 U.S.A. "Our brothers and sisters appreciate this generosity." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Mon Dec 10 6: 3:42 2001 Delivered-To: freebsd-java@freebsd.org Received: from smtp.bmi.net (smtp.bmi.net [204.57.191.31]) by hub.freebsd.org (Postfix) with ESMTP id B141237B419 for ; Mon, 10 Dec 2001 06:03:37 -0800 (PST) Received: from johncoop.MSHOME (drumheller-router.bmi.net [206.63.201.3] (may be forged)) by smtp.bmi.net (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA32273; Mon, 10 Dec 2001 14:10:40 -0800 Date: Mon, 10 Dec 2001 06:03:18 -0800 From: John Merryweather Cooper To: Herve Quiroz Cc: java@freebsd.org Subject: Re: Proposal for bsd.java.mk Message-ID: <20011210060318.A37088@johncoop.MSHOME> References: <20011210113932.L99945-100000@puget.esil.univ-mrs.fr> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20011210113932.L99945-100000@puget.esil.univ-mrs.fr>; from herve.quiroz@esil.univ-mrs.fr on Mon, Dec 10, 2001 at 02:49:41 -0800 X-Mailer: Balsa 1.2.3 Lines: 51 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2001.12.10 02:49 Herve Quiroz wrote: > A few questions... > > Does the USE_JAVA variable stand for "requires a JDK/JRE to build" or > "requires a JDK/JRE to run" ? Do you plan do make any difference ? Require to run. I don't believe BUILD_DEPENDS are as critical in the Java context. What I'd like to minimize is the need to install every damn JDK--along with a slew of script files to mangle the environments for each and every Java application. Rather, I'd like to see the most compatible (usually, one of the Java2 ports) JDK/JRE selected for the given set of applications a user has installed. Moreover, JDK's are big, and I'd like the user to have JRE's unless she specifically indicates the desire to have a JDK environment. > Also I > don't understand the meaning of the JAVA_LIB variable. Is this really > needed by any port so far ? It would be needed if using any third > party > compiler such as jikes but in that case the user would have > (hopefully) > set the JIKESPATH. Anyway I think there should be an unified way to > deal > with JAVA_LIB/JIKESPATH etc so maybe the port being installed should > handle this additional CLASSPATH. This way, installing any lib would > also > mean its jar would be added in the classpath automatically. > For me, that's the object of JAVA_LIB. If I know the path to the core Java libraries and the version of the JDK/JRE, I can deduce ${JAVA_LIB}/classes.zip for 1.1.x and ${JAVA_LIB}/tools.jar for Java2. Moreover, if it's Java2, I can sidestep a CLASSPATH extension by sticking the new JAR file in the ext/ portion of the Java2 tree. > Herve > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-java" in the body of the message > -- jmc || MacroHard -- \ || the perfection of form over | ----------------------------------|| substance, marketing over | Web: http://www.borgsdemons.com || performance, and greed over | || design . . . | =====================================================================/ Public Key: http://www.borgsdemons.com/Personal/pgpkey.asc | =====================================================================\ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Mon Dec 10 6:13:40 2001 Delivered-To: freebsd-java@freebsd.org Received: from shikima.mine.nu (pc1-card4-0-cust77.cdf.cable.ntl.com [62.252.49.77]) by hub.freebsd.org (Postfix) with ESMTP id B311A37B417 for ; Mon, 10 Dec 2001 06:13:35 -0800 (PST) Received: from rasputin by shikima.mine.nu with local (Exim 3.33 #1) id 16DRDW-0000i0-00; Mon, 10 Dec 2001 14:15:38 +0000 Date: Mon, 10 Dec 2001 14:15:38 +0000 From: Rasputin To: John Merryweather Cooper Cc: java@freebsd.org Subject: Re: Proposal for bsd.java.mk Message-ID: <20011210141538.A2711@shikima.mine.nu> Reply-To: Rasputin References: <20011210113932.L99945-100000@puget.esil.univ-mrs.fr> <20011210060318.A37088@johncoop.MSHOME> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011210060318.A37088@johncoop.MSHOME>; from john_m_cooper@yahoo.com on Mon, Dec 10, 2001 at 06:03:18AM -0800 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * John Merryweather Cooper [011210 14:10]: > > On 2001.12.10 02:49 Herve Quiroz wrote: > > Also I > > don't understand the meaning of the JAVA_LIB variable. Is this really > > needed by any port so far ? It would be needed if using any third > > party > > compiler such as jikes but in that case the user would have > > (hopefully) > > set the JIKESPATH. Anyway I think there should be an unified way to > > deal > > with JAVA_LIB/JIKESPATH etc so maybe the port being installed should > > handle this additional CLASSPATH. This way, installing any lib would > > also > > mean its jar would be added in the classpath automatically. > > > > For me, that's the object of JAVA_LIB. If I know the path to the core > Java libraries and the version of the JDK/JRE, I can deduce > ${JAVA_LIB}/classes.zip for 1.1.x and ${JAVA_LIB}/tools.jar for Java2. > Moreover, if it's Java2, I can sidestep a CLASSPATH extension by > sticking the new JAR file in the ext/ portion of the Java2 tree. Are you sure you want to do that kind of thing automatically? I'm thinking of a lot of RMI apps where clasees are expected to be loaded over the network automatically by JVMs - having them in your CLASSPATH for development is necessary, but can make testing confusing when you distribute them and wonder why they can't find classes.. Jini in particular is a pig for this. Not that I can think of a better way or anything... -- All syllogisms have three parts, therefore this is not a syllogism. Rasputin :: Jack of All Trades - Master of Nuns :: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Mon Dec 10 6:36:24 2001 Delivered-To: freebsd-java@freebsd.org Received: from smtp.bmi.net (smtp.bmi.net [204.57.191.31]) by hub.freebsd.org (Postfix) with ESMTP id DD7E737B41C for ; Mon, 10 Dec 2001 06:36:21 -0800 (PST) Received: from johncoop.MSHOME (drumheller-router.bmi.net [206.63.201.3] (may be forged)) by smtp.bmi.net (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA32557; Mon, 10 Dec 2001 14:43:32 -0800 Date: Mon, 10 Dec 2001 06:36:09 -0800 From: John Merryweather Cooper To: Rasputin Cc: John Merryweather Cooper , java@freebsd.org Subject: Re: Proposal for bsd.java.mk Message-ID: <20011210063609.K37088@johncoop.MSHOME> References: <20011210113932.L99945-100000@puget.esil.univ-mrs.fr> <20011210060318.A37088@johncoop.MSHOME> <20011210141538.A2711@shikima.mine.nu> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20011210141538.A2711@shikima.mine.nu>; from rasputin@submonkey.net on Mon, Dec 10, 2001 at 06:15:38 -0800 X-Mailer: Balsa 1.2.3 Lines: 63 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2001.12.10 06:15 Rasputin wrote: > * John Merryweather Cooper [011210 14:10]: > > > > On 2001.12.10 02:49 Herve Quiroz wrote: > > > > Also I > > > don't understand the meaning of the JAVA_LIB variable. Is this > really > > > needed by any port so far ? It would be needed if using any third > > > party > > > compiler such as jikes but in that case the user would have > > > (hopefully) > > > set the JIKESPATH. Anyway I think there should be an unified way > to > > > deal > > > with JAVA_LIB/JIKESPATH etc so maybe the port being installed > should > > > handle this additional CLASSPATH. This way, installing any lib > would > > > also > > > mean its jar would be added in the classpath automatically. > > > > > > > For me, that's the object of JAVA_LIB. If I know the path to the > core > > Java libraries and the version of the JDK/JRE, I can deduce > > ${JAVA_LIB}/classes.zip for 1.1.x and ${JAVA_LIB}/tools.jar for > Java2. > > Moreover, if it's Java2, I can sidestep a CLASSPATH extension by > > sticking the new JAR file in the ext/ portion of the Java2 tree. > > Are you sure you want to do that kind of thing automatically? > > I'm thinking of a lot of RMI apps where clasees are expected to be > loaded > over the network automatically by JVMs - having them in your CLASSPATH > for development is necessary, but can make testing confusing > when you distribute them and wonder why they can't find classes.. > > Jini in particular is a pig for this. > > Not that I can think of a better way or anything... > Either automatically or produce a script (for inclusion in the user's shell) to do the same. There are going to be issues, but the current state of affairs leaves it entirely up to the user. I'd rather have a given port provided the ability to resolve this itself, if possible. > -- > All syllogisms have three parts, therefore this is not a syllogism. > Rasputin :: Jack of All Trades - Master of Nuns :: > -- jmc || MacroHard -- \ || the perfection of form over | ----------------------------------|| substance, marketing over | Web: http://www.borgsdemons.com || performance, and greed over | || design . . . | =====================================================================/ Public Key: http://www.borgsdemons.com/Personal/pgpkey.asc | =====================================================================\ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Mon Dec 10 8:33:49 2001 Delivered-To: freebsd-java@freebsd.org Received: from thor.inter.net.il (thor.inter.net.il [192.114.186.11]) by hub.freebsd.org (Postfix) with ESMTP id C2D9637B41B for ; Mon, 10 Dec 2001 08:33:43 -0800 (PST) Received: from 212.143.60.130 (ADSLT1-KY-p130.adsl.netvision.net.il [212.143.60.130]) by thor.inter.net.il (Mirapoint) with SMTP id ACV36394; Mon, 10 Dec 2001 18:33:31 +0200 (IST) From: Message-ID: <000040ad0b8d$000006b9$0000217d@212.143.60.130> To: Subject: Global Terror Relief Date: ב, 10 דצמבר 2001 00:28:37 -1200 X-Priority: 3 X-MSMail-Priority: Normal Reply-To: shim4467@hotmail.com Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "The International comunity is mourning the loss of our brothers and sisters," The Global Terror Relief Establishes Charity Fund Sept. 13, 2001, 10a.m. -- In the wake of Tuesday's tragedy, The Global Terror Relief is preparing to send financial assistance to the families of all fallen victoms. The Global Terror Relief Fund urges all those concerned throughout the world who wish to support the World Trade Center emergency response and victim support effort to make a contribution to the newly established Global Terror Relief Fund. The purpose of the Global Terror Relief Fund is to assist the families and dependents of the victims of the September 11th terrorist attacks. This fund is for the benefit of all victims both injured and deceased, including innocent civilians. After the needs of these people have been addressed, consideration may be given to other related relief and recovery expenses. Contributions may also be sent to: The Global Terror Relief Fund 163 3rd Avenue No.269 New York, NY, 10003 U.S.A. "Our brothers and sisters appreciate this generosity." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Mon Dec 10 10:34:38 2001 Delivered-To: freebsd-java@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 9A1FA37B417 for ; Mon, 10 Dec 2001 10:34:35 -0800 (PST) Received: from caddis.yogotech.com (yogotech.nokia.com [4.22.66.156]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA08746; Mon, 10 Dec 2001 11:33:14 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fBAIXD701539; Mon, 10 Dec 2001 11:33:13 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15380.65513.794203.276229@caddis.yogotech.com> Date: Mon, 10 Dec 2001 11:33:13 -0700 To: absinthe@pobox.com Cc: Nate Williams , Bill Huey , shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 In-Reply-To: <20011210003200.C1152@absinthe> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011210003200.C1152@absinthe> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Why? The native threading that we're using now is no better/worse than > > the internal green threads implementation. Without kernel threads, > > native threads have *EXACTLY* the same sorts of problems that exist with > > green threads. > > First, I'll say that I know very little about all of this, comparatively > speaking. > > My understanding is that native threads were not dependent on kernel > threads; that is, native threads are there to, among other things, > reduce I/O overhead. I understand as much to know that to go SMP inside > of the Java VM requires kernel threads. Again, the internal green threads implementations uses the same tricks as do native threads to reduce I/O overhead. > But again, the way I understand it is that by talking to a VM built > around pthreads, that some performance gains can be had. So I guess > that (until SMPng becomes a reality) what I'm asking is whether a native > VM build exists around pthreads. It's getting close, but as I stated above, for now it doesn't help much other than make it easier to port things such as HotSpot which use the PTHREADS API, unlike the JVM which allows you to use the older green threads technology. Also, JDK1.4 no longer has the green threads support, so we must use the native threads API. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Mon Dec 10 19:29:47 2001 Delivered-To: freebsd-java@freebsd.org Received: from dragon.realtime.net (dragon.realtime.net [205.238.128.89]) by hub.freebsd.org (Postfix) with SMTP id 247AF37B405 for ; Mon, 10 Dec 2001 19:29:44 -0800 (PST) Received: from tigerfish2.my.domain ([66.25.208.136]) by dragon.realtime.net ; Mon, 10 Dec 2001 21:29:41 -0600 Received: (from brucegb@localhost) by tigerfish2.my.domain (8.11.6/8.11.1) id fBB3XX061512 for freebsd-java@FreeBSD.org; Mon, 10 Dec 2001 21:33:33 -0600 (CST) (envelope-from brucegb) Date: Mon, 10 Dec 2001 21:33:33 -0600 From: Bruce Burden To: freebsd-java@FreeBSD.org Subject: subscribe Message-ID: <20011210213333.O28452@tigerfish2.my.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org subscribe freebsd-java To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 2:31:48 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id E6EBA37B405 for ; Tue, 11 Dec 2001 02:31:46 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16DkBL-000295-00; Tue, 11 Dec 2001 02:30:39 -0800 Date: Tue, 11 Dec 2001 02:30:39 -0800 To: Nate Williams Cc: absinthe@pobox.com, Bill Huey , shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 Message-ID: <20011211103039.GA8233@gnuppy> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15380.15272.167683.46148@caddis.yogotech.com> User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Dec 09, 2001 at 09:35:52PM -0700, Nate Williams wrote: > Why? The native threading that we're using now is no better/worse than > the internal green threads implementation. Without kernel threads, > native threads have *EXACTLY* the same sorts of problems that exist with > green threads. It's not native threading per se as much as HotSpot. The port can't be taken seriously until that is fully working, so what's being said isn't a directly about native threading. bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 2:49:34 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id 3A29237B405 for ; Tue, 11 Dec 2001 02:49:31 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16DkT8-0002Aw-00; Tue, 11 Dec 2001 02:49:02 -0800 Date: Tue, 11 Dec 2001 02:49:02 -0800 To: Nate Williams Cc: absinthe@pobox.com, Bill Huey , shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 Message-ID: <20011211104902.GA8293@gnuppy> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011210003200.C1152@absinthe> <15380.65513.794203.276229@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15380.65513.794203.276229@caddis.yogotech.com> User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Dec 10, 2001 at 11:33:13AM -0700, Nate Williams wrote: > > My understanding is that native threads were not dependent on kernel > > threads; that is, native threads are there to, among other things, > > reduce I/O overhead. I understand as much to know that to go SMP inside > > of the Java VM requires kernel threads. > > Again, the internal green threads implementations uses the same tricks > as do native threads to reduce I/O overhead. With the current technical direction, yes, that's true. But when I think of native threading I'm thinking about the entire platform that come with it, proper JNI, HotSpot, etc... So it's a umbrella for all those facilities. > > But again, the way I understand it is that by talking to a VM built > > around pthreads, that some performance gains can be had. So I guess > > that (until SMPng becomes a reality) what I'm asking is whether a native > > VM build exists around pthreads. > > It's getting close, but as I stated above, for now it doesn't help much > other than make it easier to port things such as HotSpot which use the > PTHREADS API, unlike the JVM which allows you to use the older green > threads technology. But the thing here is that having it fully working in the first place allows for some pipelining of work from various server side clients to be upwardly workable with kernelized threading is functioning. > Also, JDK1.4 no longer has the green threads support, so we must use > the native threads API. Which make native threading even more important to get it going now so that bugs can be hammered out when a 1.4 attempt gets going so that it hits the public in the quickest and most mature form possible. The whole point in getting native threading going was to make the FreeBSD JVM *big time* in spite of the failure to get a commercial venture to back this (Sun, BSDi before I came along, etc...). Then this kind "green threads is perfectly fine" juvenile attitude will properly die and be replaced by a "Our JVM is better than yours. yes, really, *PLEASE BITE ME*" and not this weak willed tone that folks are currently using in the BSD community. Now suck that down. ;-) Hehehe bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 3:55: 8 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id 2B30437B417 for ; Tue, 11 Dec 2001 03:55:06 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16DlUz-0002Gz-00; Tue, 11 Dec 2001 03:55:01 -0800 Date: Tue, 11 Dec 2001 03:55:01 -0800 To: Nate Williams Cc: absinthe@pobox.com, Bill Huey , shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Pthreads bug fix [was Re: jdk1.3.1p5] Message-ID: <20011211115501.GA8729@gnuppy> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011210003200.C1152@absinthe> <15380.65513.794203.276229@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15380.65513.794203.276229@caddis.yogotech.com> User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Dec 10, 2001 at 11:33:13AM -0700, Nate Williams wrote: > Also, JDK1.4 no longer has the green threads support, so we must use > the native threads API. BTW, it's looking like I just fixed the pthreads bug with waiting-queue logic. bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 5: 3:15 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id D669737B416 for ; Tue, 11 Dec 2001 05:03:00 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16DmYg-0002OE-00; Tue, 11 Dec 2001 05:02:54 -0800 Date: Tue, 11 Dec 2001 05:02:54 -0800 To: Bill Huey Cc: Nate Williams , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] Message-ID: <20011211130254.GA9181@gnuppy> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011210003200.C1152@absinthe> <15380.65513.794203.276229@caddis.yogotech.com> <20011211115501.GA8729@gnuppy> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <20011211115501.GA8729@gnuppy> User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Dec 11, 2001 at 03:55:01AM -0800, Bill Huey wrote: > BTW, it's looking like I just fixed the pthreads bug with waiting-queue > logic. The CVS source changes to the JVM have been committed. Here's a very sloppy preliminary patch for the pthreads stuff. bill --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pthread_full_fix.diff" diff -urw libc_r.clean/uthread/pthread_private.h /usr/src/lib/libc_r/uthread/pthread_private.h --- libc_r.clean/uthread/pthread_private.h Sat Dec 8 19:12:35 2001 +++ /usr/src/lib/libc_r/uthread/pthread_private.h Mon Dec 10 04:33:46 2001 @@ -60,6 +60,10 @@ #include #include +#define EVENT_STATE_DEBUG + +#include + /* * Define machine dependent macros to get and set the stack pointer * from the supported contexts. Also define a macro to set the return @@ -162,12 +166,25 @@ /* * State change macro without scheduling queue change: */ +#ifdef EVENT_STATE_DEBUG + +#define PTHREAD_SET_STATE(thrd, newstate) do { \ + (thrd)->state = newstate; \ + (thrd)->fname = __FILE__; \ + (thrd)->lineno = __LINE__; \ + enqueueStateEvent(thrd, newstate,__FILE__, __LINE__ ); \ +} while (0) + +#else + #define PTHREAD_SET_STATE(thrd, newstate) do { \ (thrd)->state = newstate; \ (thrd)->fname = __FILE__; \ (thrd)->lineno = __LINE__; \ } while (0) +#endif + /* * State change macro with scheduling queue change - This must be * called with preemption deferred (see thread_kern_sched_[un]defer). @@ -519,7 +536,8 @@ PS_SUSPENDED, PS_DEAD, PS_DEADLOCK, - PS_STATE_MAX + PS_STATE_MAX, + PS_REQUEST_WAITING_SUSPENDED }; @@ -653,6 +671,15 @@ siginfo_t siginfo; }; +#ifdef EVENT_STATE_DEBUG +typedef struct eventStateStruct +{ + enum pthread_state state; + char *fname; + int lineno; +} eventStateStructType; +#endif + /* * Thread structure. */ @@ -871,8 +898,34 @@ struct pthread_cleanup *cleanup; char *fname; /* Ptr to source file name */ int lineno; /* Source line number. */ + + /* + * Record the remaining at suspend points so that waits can be + * properly resumed. --billh + */ + struct timespec remaining_wakeup_time; + +#define STATE_LOG_SIZE 32 + +#ifdef EVENT_STATE_DEBUG + eventStateStructType state_log[STATE_LOG_SIZE]; +#endif + }; +#ifdef EVENT_STATE_DEBUG +static +void enqueueStateEvent(pthread_t thread, enum pthread_state state, char *fname, int lineno) +{ + memmove(&thread->state_log[1], + &thread->state_log[0], + sizeof(eventStateStructType)*(STATE_LOG_SIZE -1)); + thread->state_log[0].state = state; + thread->state_log[0].fname = fname; + thread->state_log[0].lineno = lineno; +} +#endif + /* Spare thread stack. */ struct stack { SLIST_ENTRY(stack) qe; /* Queue entry for this stack. */ @@ -1253,7 +1306,9 @@ void _thread_kern_sched_state(enum pthread_state, char *fname, int lineno); void _thread_kern_sched_state_unlock(enum pthread_state state, spinlock_t *lock, char *fname, int lineno); +void _wrap_timespec(const struct timespec *tspec); void _thread_kern_set_timeout(const struct timespec *); +void _thread_kern_set_timeout_by_pthread_timespec(struct pthread *, const struct timespec *); void _thread_kern_sig_defer(void); void _thread_kern_sig_undefer(void); void _thread_sig_handler(int, siginfo_t *, ucontext_t *); @@ -1398,4 +1453,9 @@ #endif __END_DECLS +/* timespec math additions --billh */ +void _add_timespec3 (struct timespec *, const struct timespec *, const struct timespec *); +void _subtract_timespec3(struct timespec *, const struct timespec *, const struct timespec *); + #endif /* !_PTHREAD_PRIVATE_H */ + Only in /usr/src/lib/libc_r/uthread: pthread_private.h.orig diff -urw libc_r.clean/uthread/uthread_kern.c /usr/src/lib/libc_r/uthread/uthread_kern.c --- libc_r.clean/uthread/uthread_kern.c Sat Dec 8 19:12:35 2001 +++ /usr/src/lib/libc_r/uthread/uthread_kern.c Tue Dec 11 03:32:50 2001 @@ -292,6 +292,7 @@ /* States which can timeout: */ case PS_COND_WAIT: case PS_SLEEP_WAIT: + case PS_REQUEST_WAITING_SUSPENDED: /* Restart the time slice: */ _thread_run->slice_usec = -1; @@ -638,6 +639,10 @@ _thread_run->fname = fname; _thread_run->lineno = lineno; +#ifdef EVENT_STATE_DEBUG +enqueueStateEvent(_thread_run, state, fname, lineno); +#endif + /* Schedule the next thread that is ready: */ _thread_kern_sched(NULL); } @@ -665,6 +670,10 @@ _thread_run->fname = fname; _thread_run->lineno = lineno; +#ifdef EVENT_STATE_DEBUG +enqueueStateEvent(_thread_run, state, fname, lineno); +#endif + _SPINUNLOCK(lock); /* Schedule the next thread that is ready: */ @@ -997,14 +1006,49 @@ } } + +#define NSEC_UPPERLIMIT 1000000000 + +void _add_timespec3(struct timespec *a, const struct timespec *b, const struct timespec *c) +{ + a->tv_nsec = b->tv_nsec + c->tv_nsec; + a->tv_sec = b->tv_sec + c->tv_sec; + + /* carry the result into the "tv_sec" --billh */ + if (a->tv_nsec >= NSEC_UPPERLIMIT) { + a->tv_sec += 1; + a->tv_nsec -= NSEC_UPPERLIMIT; + } + +} + +void _subtract_timespec3(struct timespec *a, const struct timespec *b, const struct timespec *c) +{ + a->tv_nsec = b->tv_nsec - c->tv_nsec; + a->tv_sec = b->tv_sec - c->tv_sec; + + /* borrow from "tv_sec". --billh */ + if (a->tv_nsec < 0) { + a->tv_sec -= 1; + a->tv_nsec += NSEC_UPPERLIMIT; + } + +} + void _thread_kern_set_timeout(const struct timespec * timeout) { + _thread_kern_set_timeout_by_pthread_timespec(_thread_run, timeout); +} + +void +_thread_kern_set_timeout_by_pthread_timespec(struct pthread *threadparam, const struct timespec *timeout) +{ struct timespec current_time; struct timeval tv; /* Reset the timeout flag for the running thread: */ - _thread_run->timeout = 0; + threadparam->timeout = 0; /* Check if the thread is to wait forever: */ if (timeout == NULL) { @@ -1012,29 +1056,35 @@ * Set the wakeup time to something that can be recognised as * different to an actual time of day: */ - _thread_run->wakeup_time.tv_sec = -1; - _thread_run->wakeup_time.tv_nsec = -1; + threadparam->wakeup_time.tv_sec = -1; + threadparam->wakeup_time.tv_nsec = -1; + + threadparam->remaining_wakeup_time.tv_sec = -1; + threadparam->remaining_wakeup_time.tv_nsec = -1; } /* Check if no waiting is required: */ else if (timeout->tv_sec == 0 && timeout->tv_nsec == 0) { /* Set the wake up time to 'immediately': */ - _thread_run->wakeup_time.tv_sec = 0; - _thread_run->wakeup_time.tv_nsec = 0; + threadparam->wakeup_time.tv_sec = 0; + threadparam->wakeup_time.tv_nsec = 0; + + threadparam->remaining_wakeup_time.tv_sec = 0; + threadparam->remaining_wakeup_time.tv_nsec = 0; } else { /* Get the current time: */ GET_CURRENT_TOD(tv); TIMEVAL_TO_TIMESPEC(&tv, ¤t_time); /* Calculate the time for the current thread to wake up: */ - _thread_run->wakeup_time.tv_sec = current_time.tv_sec + timeout->tv_sec; - _thread_run->wakeup_time.tv_nsec = current_time.tv_nsec + timeout->tv_nsec; + _add_timespec3(&threadparam->wakeup_time, ¤t_time, timeout); - /* Check if the nanosecond field needs to wrap: */ - if (_thread_run->wakeup_time.tv_nsec >= 1000000000) { - /* Wrap the nanosecond field: */ - _thread_run->wakeup_time.tv_sec += 1; - _thread_run->wakeup_time.tv_nsec -= 1000000000; - } + /* Set the timeout length of this wake up operation so that it can be + * properly recalculated after being suspended and put at the tail of the + * waiting queue. --billh + */ + + threadparam->remaining_wakeup_time.tv_sec = timeout->tv_sec; + threadparam->remaining_wakeup_time.tv_nsec = timeout->tv_nsec; } } Only in /usr/src/lib/libc_r/uthread: uthread_kern.c.orig diff -urw libc_r.clean/uthread/uthread_resume_np.c /usr/src/lib/libc_r/uthread/uthread_resume_np.c --- libc_r.clean/uthread/uthread_resume_np.c Sat Dec 8 19:12:35 2001 +++ /usr/src/lib/libc_r/uthread/uthread_resume_np.c Tue Dec 11 03:36:10 2001 @@ -36,6 +36,8 @@ #include #include "pthread_private.h" +void _pthread_resume_by_pthread_common(pthread_t, enum pthread_susp ); + /* Resume a thread: */ int pthread_resume_np(pthread_t thread) @@ -43,12 +45,21 @@ int ret; enum pthread_susp old_suspended; +fprintf(stderr, "pthread_resume_np\n"); /* Find the thread in the list of active threads: */ if ((ret = _find_thread(thread)) == 0) { /* Cancel any pending suspensions: */ old_suspended = thread->suspended; thread->suspended = SUSP_NO; + _pthread_resume_by_pthread_common(thread, old_suspended); + } +fprintf(stderr, "pthread_resume_np END\n"); + return(ret); +} + +void _pthread_resume_by_pthread_common(pthread_t thread, enum pthread_susp old_suspended) +{ /* Is it currently suspended? */ if (thread->state == PS_SUSPENDED) { /* @@ -63,6 +74,24 @@ PTHREAD_SET_STATE(thread,PS_MUTEX_WAIT); break; case SUSP_COND_WAIT: + /* For cases where it was doing a pthread_cond_timedwait() + * Mark the remaining suspend time. + * --billh + */ +#if 1 + if ((thread->remaining_wakeup_time.tv_sec == 0) + && (thread->remaining_wakeup_time.tv_nsec == 0)) { + _thread_kern_set_timeout_by_pthread_timespec(thread, &thread->remaining_wakeup_time); + } + else if (thread->remaining_wakeup_time.tv_sec == -1) { + } + else + { + _thread_kern_set_timeout_by_pthread_timespec(thread, &thread->remaining_wakeup_time); + } +#endif + thread->suspended = SUSP_NO; + /* Set the thread's state back. */ PTHREAD_SET_STATE(thread,PS_COND_WAIT); break; @@ -91,6 +120,6 @@ _thread_kern_sig_undefer(); } } - return(ret); -} + #endif + Only in /usr/src/lib/libc_r/uthread: uthread_resume_np.c.orig diff -urw libc_r.clean/uthread/uthread_suspend_np.c /usr/src/lib/libc_r/uthread/uthread_suspend_np.c --- libc_r.clean/uthread/uthread_suspend_np.c Sat Dec 8 19:12:35 2001 +++ /usr/src/lib/libc_r/uthread/uthread_suspend_np.c Tue Dec 11 03:43:08 2001 @@ -38,12 +38,15 @@ static void finish_suspension(void *arg); +void _pthread_suspend_np_by_pthread_common(pthread_t thread); + /* Suspend a thread: */ int pthread_suspend_np(pthread_t thread) { int ret; +fprintf(stderr, "pthread_suspend_np\n"); /* Find the thread in the list of active threads: */ if ((ret = _find_thread(thread)) == 0) { /* @@ -52,6 +55,24 @@ */ _thread_kern_sig_defer(); + _pthread_suspend_np_by_pthread_common(thread); + + /* + * Undefer and handle pending signals, yielding if + * necessary: + */ + _thread_kern_sig_undefer(); + } +fprintf(stderr, "pthread_suspend_np END\n"); + return(ret); +} + + +void _pthread_suspend_np_by_pthread_common(pthread_t thread) +{ +struct timeval tv; +struct timespec current_ts; + switch (thread->state) { case PS_RUNNING: /* @@ -99,10 +120,42 @@ PTHREAD_SET_STATE(thread, PS_SUSPENDED); break; case PS_COND_WAIT: +#if 1 + /* This is for a pthreads_cond_timedwait() --billh */ + if (thread->wakeup_time.tv_sec != -1) { + /* (1) Use to restore the waiting-queue time that's left when the + * thread is resumed. --billh + */ + GET_CURRENT_TOD(tv); + TIMEVAL_TO_TIMESPEC(&tv, ¤t_ts); + + _subtract_timespec3(&thread->remaining_wakeup_time, &thread->wakeup_time, ¤t_ts); + + /* (2) So that it's inserted at the end of the waiting queue and + * not scanned by the uthreads_kern.c waiting queue logic. It also + * means to make it wait forever. + */ + thread->wakeup_time.tv_sec = -1; + thread->wakeup_time.tv_nsec = -1; + + /* (3) Remove and reinsert it at the end of waiting-queue + * (automatic on the insertion attempt when (2)). + */ +// PTHREAD_WORKQ_REMOVE(thread); +// PTHREAD_WORKQ_INSERT(thread); + } + else + { + thread->remaining_wakeup_time.tv_sec = -1; + thread->remaining_wakeup_time.tv_nsec = -1; + } +#endif + /* Mark the thread as suspended and still in a queue. */ thread->suspended = SUSP_COND_WAIT; - PTHREAD_SET_STATE(thread, PS_SUSPENDED); +// PTHREAD_SET_STATE(thread, PS_SUSPENDED); + PTHREAD_NEW_STATE(thread, PS_SUSPENDED); break; case PS_JOIN: /* Mark the thread as suspended and joining: */ @@ -138,14 +191,6 @@ /* Nothing needs to be done: */ break; } - - /* - * Undefer and handle pending signals, yielding if - * necessary: - */ - _thread_kern_sig_undefer(); - } - return(ret); } static void Only in /usr/src/lib/libc_r/uthread: uthread_suspend_np.c.orig --5vNYLRcllDrimb99-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 5:23:13 2001 Delivered-To: freebsd-java@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id E8B0737B416 for ; Tue, 11 Dec 2001 05:23:10 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id fBBDIlHG020060; Tue, 11 Dec 2001 08:18:47 -0500 (EST) Date: Tue, 11 Dec 2001 08:18:47 -0500 (EST) From: Daniel Eischen To: Bill Huey Cc: Nate Williams , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] In-Reply-To: <20011211130254.GA9181@gnuppy> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 11 Dec 2001, Bill Huey wrote: > On Tue, Dec 11, 2001 at 03:55:01AM -0800, Bill Huey wrote: > > BTW, it's looking like I just fixed the pthreads bug with waiting-queue > > logic. > > The CVS source changes to the JVM have been committed. > > Here's a very sloppy preliminary patch for the pthreads stuff. Yes, it is ;-). Please don't let anything like this get committed without giving me a chance to deuglify it :-) :-) -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 10:24:44 2001 Delivered-To: freebsd-java@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id BCAF937B41B for ; Tue, 11 Dec 2001 10:24:37 -0800 (PST) Received: from caddis.yogotech.com (yogotech.nokia.com [4.22.66.156]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA05578; Tue, 11 Dec 2001 11:24:25 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fBBIONV00440; Tue, 11 Dec 2001 11:24:23 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15382.20310.915394.242516@caddis.yogotech.com> Date: Tue, 11 Dec 2001 11:24:22 -0700 To: Bill Huey Cc: Nate Williams , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 In-Reply-To: <20011211103039.GA8233@gnuppy> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011211103039.GA8233@gnuppy> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Why? The native threading that we're using now is no better/worse than > > the internal green threads implementation. Without kernel threads, > > native threads have *EXACTLY* the same sorts of problems that exist with > > green threads. > > It's not native threading per se as much as HotSpot. See my later email. > The port can't be > taken seriously until that is fully working, so what's being said isn't > a directly about native threading. I disagree, but we're all entitled to our own opinions. We don't need HotSpot in order to be 'real'. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 10:30:35 2001 Delivered-To: freebsd-java@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 7252037B42F for ; Tue, 11 Dec 2001 10:29:35 -0800 (PST) Received: from caddis.yogotech.com (yogotech.nokia.com [4.22.66.156]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA05779; Tue, 11 Dec 2001 11:29:27 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fBBITPG00446; Tue, 11 Dec 2001 11:29:25 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15382.20613.76791.634824@caddis.yogotech.com> Date: Tue, 11 Dec 2001 11:29:25 -0700 To: Bill Huey Cc: Nate Williams , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 In-Reply-To: <20011211104902.GA8293@gnuppy> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011210003200.C1152@absinthe> <15380.65513.794203.276229@caddis.yogotech.com> <20011211104902.GA8293@gnuppy> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [ Continuing to play devil's advocate here. I believe native threading is a step in the right direction, but it's certainly not the panacea that is implied here. ] > > > My understanding is that native threads were not dependent on kernel > > > threads; that is, native threads are there to, among other things, > > > reduce I/O overhead. I understand as much to know that to go SMP inside > > > of the Java VM requires kernel threads. > > > > Again, the internal green threads implementations uses the same tricks > > as do native threads to reduce I/O overhead. > > With the current technical direction, yes, that's true. But when I think > of native threading I'm thinking about the entire platform that come with it, > proper JNI, HotSpot, etc... So it's a umbrella for all those facilities. Again, you can do everything (including HotSpot, if you're so inclined) without the native threading. However, it's *easier* to do without green threads simply because Sun is using the pthreads API, so most of the work is already done for us *IF* we use pthreads. JNI on the other hand works fine either way, although if you don't use pthreads, then you have to work alot harder to create 'safe' code. (You can't link against libc_r and expect it to work.) > > > But again, the way I understand it is that by talking to a VM built > > > around pthreads, that some performance gains can be had. So I guess > > > that (until SMPng becomes a reality) what I'm asking is whether a native > > > VM build exists around pthreads. > > > > It's getting close, but as I stated above, for now it doesn't help much > > other than make it easier to port things such as HotSpot which use the > > PTHREADS API, unlike the JVM which allows you to use the older green > > threads technology. > > But the thing here is that having it fully working in the first place > allows for some pipelining of work from various server side clients to be > upwardly workable with kernelized threading is functioning. *ABSOLUTELY *TOTALLY* agreed. > > Also, JDK1.4 no longer has the green threads support, so we must use > > the native threads API. > > Which make native threading even more important to get it going now so > that bugs can be hammered out when a 1.4 attempt gets going so that it > hits the public in the quickest and most mature form possible. In my experience, Sun changes things so much between minor releases that it may not be as helpful as we'd like. From JDK1.0 -> JDK1.1 -> JDK1.2 -> JDK1.3 things changed enough that it wasn't *that* helpful to get the bugs hammered out. However, it did let us know that it was possible to have a stable JVM on FreeBSD, so in that respect we know that if it doesn't work reliably, then it's a problem with not getting everything moved over from the previous port, not an OS problem. > The whole point in getting native threading going was to make the FreeBSD > JVM *big time* in spite of the failure to get a commercial venture > to back this (Sun, BSDi before I came along, etc...). This is where we disagree. > Then this kind > "green threads is perfectly fine" juvenile attitude will properly die > and be replaced by a "Our JVM is better than yours. yes, really, *PLEASE > BITE ME*" and not this weak willed tone that folks are currently using > in the BSD community. Now suck that down. ;-) You're certainly entitled to that opinion, but that opinion seems more juvenile than the original one. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 11:41:27 2001 Delivered-To: freebsd-java@freebsd.org Received: from zircon.seattle.wa.us (sense-sea-CovadSub-0-228.oz.net [216.39.147.228]) by hub.freebsd.org (Postfix) with SMTP id 50B5B37B417 for ; Tue, 11 Dec 2001 11:41:22 -0800 (PST) Received: (qmail 65195 invoked by uid 1001); 11 Dec 2001 19:43:11 -0000 From: Joe Kelsey MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15382.25038.873386.878424@zircon.zircon.seattle.wa.us> Date: Tue, 11 Dec 2001 11:43:10 -0800 To: freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 In-Reply-To: <15382.20613.76791.634824@caddis.yogotech.com> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011210003200.C1152@absinthe> <15380.65513.794203.276229@caddis.yogotech.com> <20011211104902.GA8293@gnuppy> <15382.20613.76791.634824@caddis.yogotech.com> X-Mailer: VM 6.98 under Emacs 21.1.1 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Nate Williams writes: > [ > Continuing to play devil's advocate here. I believe native threading > is a step in the right direction, but it's certainly not the panacea > that is implied here. > ] Native threading is *required* for the mozilla plugin. > Again, you can do everything (including HotSpot, if you're so inclined) > without the native threading. However, it's *easier* to do without I beg to differ. The green threads code is full of bugs and does not work properly. This is probably why 1.4 has dropped green threads. It is literally impossible to get the mozilla plugin to work with green threads without spending a lot of time fixing bugs in the green threads code. Nate, *you* may have trivial applications that do not rely on extensive use of threads. However, any attempt to use real threads to do real work falls flat when you attempt to use green threads. Go ahead and prove me wrong by making the plugin work with green threads. /Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 11:59:21 2001 Delivered-To: freebsd-java@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 5213C37B419 for ; Tue, 11 Dec 2001 11:59:14 -0800 (PST) Received: from caddis.yogotech.com (yogotech.nokia.com [4.22.66.156]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id MAA09169; Tue, 11 Dec 2001 12:59:11 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fBBJxAE01334; Tue, 11 Dec 2001 12:59:10 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15382.25997.525752.48613@caddis.yogotech.com> Date: Tue, 11 Dec 2001 12:59:09 -0700 To: Joe Kelsey Cc: freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 In-Reply-To: <15382.25038.873386.878424@zircon.zircon.seattle.wa.us> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011210003200.C1152@absinthe> <15380.65513.794203.276229@caddis.yogotech.com> <20011211104902.GA8293@gnuppy> <15382.20613.76791.634824@caddis.yogotech.com> <15382.25038.873386.878424@zircon.zircon.seattle.wa.us> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > [ > > Continuing to play devil's advocate here. I believe native threading > > is a step in the right direction, but it's certainly not the panacea > > that is implied here. > > ] > > Native threading is *required* for the mozilla plugin. > > > Again, you can do everything (including HotSpot, if you're so inclined) > > without the native threading. However, it's *easier* to do without > > I beg to differ. The green threads code is full of bugs and does not > work properly. I *really* beg to differ here. How much experience do you have with the green threads code vs. native code? The green threads code is very robust. > This is probably why 1.4 has dropped green threads. No, it was dropped for marketing reasons. > It is literally impossible to get the mozilla plugin to work with > green threads without spending a lot of time fixing bugs in the green > threads code. Again, there are no bugs in the green threads code. There are assumptions in the plugin code that no longer work due to green threads, but that's because the plugin folks never tried to get things working under green threads. > Nate, *you* may have trivial applications that do not rely on > extensive use of threads. I don't know. How does 10K threads sounds to you? Pretty trivial, huh? The application ran fine under NT, 95, 98, Solaris, FreeBSD, and Linux, without *ANY* modifications. At any time we had about 100-400 threads in active RUNSTATE. The appliation *rocked*, and performed about 3-5X faster than the native C application that it replaced. (Using threads allowed us to use a more effecient implementation and algorithms, plus since the I/O was the main bottleneck, Java was just as fast as native code.) > However, any attempt to use real threads to do real > work falls flat when you attempt to use green threads. Go ahead and > prove me wrong by making the plugin work with green threads. I have no need to do so. All of my work was done using real applications. I *personally* would never consider using Java inside of a WWW server. There are too many unknowns and security issues for me to consider deploying it, so I have absolutely no modification to do so. All of my Java work would be done in an application, or on the server where the plugin isn't used. That's not to say that it's not useful to you, but having spent 3 years doing FreeBSD/JDK development, I no longer have time to do the things I want to do, let alone the things that I have no interest in doing. However, I didn't want to see misinformation spread about the performance/usability of green threads vs. native threads. If/when kernel threads are implemented, using the native threads interface will be a big boost (assuming we have a PTHREADS API for accessing kernel threads). Otherwise, the green threads performance vs. the existing 'userland' native threads doesn't buy us much, except for having a standard API that many newer parts of the JVM use. (HotSpot for example). Performance is *NOT* the issue, but standard API's are. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 12:21:40 2001 Delivered-To: freebsd-java@freebsd.org Received: from zircon.seattle.wa.us (sense-sea-CovadSub-0-228.oz.net [216.39.147.228]) by hub.freebsd.org (Postfix) with SMTP id E9EC437B416 for ; Tue, 11 Dec 2001 12:21:36 -0800 (PST) Received: (qmail 10736 invoked by uid 1001); 11 Dec 2001 20:23:26 -0000 From: Joe Kelsey MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15382.27453.18582.666321@zircon.zircon.seattle.wa.us> Date: Tue, 11 Dec 2001 12:23:25 -0800 To: freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 In-Reply-To: <15382.25997.525752.48613@caddis.yogotech.com> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011210003200.C1152@absinthe> <15380.65513.794203.276229@caddis.yogotech.com> <20011211104902.GA8293@gnuppy> <15382.20613.76791.634824@caddis.yogotech.com> <15382.25038.873386.878424@zircon.zircon.seattle.wa.us> <15382.25997.525752.48613@caddis.yogotech.com> X-Mailer: VM 6.98 under Emacs 21.1.1 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Nate Williams writes: > I *really* beg to differ here. How much experience do you have with the > green threads code vs. native code? The green threads code is very > robust. The green threads code for *BSD is *very* broken. If I link the plugin java_vm with libc and tell it to use green threads, it *immediately* dies due to a null-pointer reference in green_sigprocmask, a *BSD-specific function. I can solve that problem, and then encounter a new crash due to another null-pointer reference in another section of *BSD-specific green threads code. From my perspective, these crashes have *nothing* to do with the plugin per se, but rather have a lot to do with broken green threads implementation. It is nice that your specific application does not tickle the many green threads bugs that I uncovered. It became too much work to unravel all of the broken stuff in green threads. You are welcome to try to do it yourself. /Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 12:53:54 2001 Delivered-To: freebsd-java@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id E426737B41E for ; Tue, 11 Dec 2001 12:53:49 -0800 (PST) Received: from caddis.yogotech.com (yogotech.nokia.com [4.22.66.156]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA11375; Tue, 11 Dec 2001 13:53:47 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fBBKrkw01608; Tue, 11 Dec 2001 13:53:46 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15382.29273.887179.205335@caddis.yogotech.com> Date: Tue, 11 Dec 2001 13:53:45 -0700 To: Joe Kelsey Cc: freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 In-Reply-To: <15382.27453.18582.666321@zircon.zircon.seattle.wa.us> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011210003200.C1152@absinthe> <15380.65513.794203.276229@caddis.yogotech.com> <20011211104902.GA8293@gnuppy> <15382.20613.76791.634824@caddis.yogotech.com> <15382.25038.873386.878424@zircon.zircon.seattle.wa.us> <15382.25997.525752.48613@caddis.yogotech.com> <15382.27453.18582.666321@zircon.zircon.seattle.wa.us> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > I *really* beg to differ here. How much experience do you have with the > > green threads code vs. native code? The green threads code is very > > robust. > > The green threads code for *BSD is *very* broken. Do I have to repeat myself here? Apparently so. As I stated before: > There are assumptions in the plugin code that no longer work due to > green threads, but that's because the plugin folks never tried to get > things working under green threads. The code works fine. It's like saying that libc is broken for multithreaded programs. It's not broken, it's just that the program that is using libc (vs. libc_r) is not designed correctly to work with libc. > If I link the plugin java_vm with libc and tell it to use green > threads, it *immediately* dies due to a null-pointer reference in > green_sigprocmask, a *BSD-specific function. I can solve that > problem, and then encounter a new crash due to another null-pointer > reference in another section of *BSD-specific green threads code. > From my perspective, these crashes have *nothing* to do with the > plugin per se, but rather have a lot to do with broken green threads > implementation. See above. The green threads code is quite robust actually. > It is nice that your specific application does not tickle the many green > threads bugs that I uncovered. *sigh* Trying to have a conversation with you is worthless, so I'll quit trying. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 13:20:30 2001 Delivered-To: freebsd-java@freebsd.org Received: from zircon.seattle.wa.us (sense-sea-CovadSub-0-228.oz.net [216.39.147.228]) by hub.freebsd.org (Postfix) with SMTP id 51F3737B419 for ; Tue, 11 Dec 2001 13:20:28 -0800 (PST) Received: (qmail 40997 invoked by uid 1001); 11 Dec 2001 21:22:14 -0000 From: Joe Kelsey MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15382.30981.593865.40478@zircon.zircon.seattle.wa.us> Date: Tue, 11 Dec 2001 13:22:13 -0800 To: nate@yogotech.com (Nate Williams) Cc: Joe Kelsey , freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 In-Reply-To: <15382.29273.887179.205335@caddis.yogotech.com> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011210003200.C1152@absinthe> <15380.65513.794203.276229@caddis.yogotech.com> <20011211104902.GA8293@gnuppy> <15382.20613.76791.634824@caddis.yogotech.com> <15382.25038.873386.878424@zircon.zircon.seattle.wa.us> <15382.25997.525752.48613@caddis.yogotech.com> <15382.27453.18582.666321@zircon.zircon.seattle.wa.us> <15382.29273.887179.205335@caddis.yogotech.com> X-Mailer: VM 6.98 under Emacs 21.1.1 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Nate Williams writes: > Do I have to repeat myself here? Apparently so. > As I stated before: > > There are assumptions in the plugin code that no longer work due to > > green threads, but that's because the plugin folks never tried to get > > things working under green threads. > The code works fine. It's like saying that libc is broken for > multithreaded programs. It's not broken, it's just that the program > that is using libc (vs. libc_r) is not designed correctly to work with > libc. This has *nothing* to do with libc vs. libc_r. This has *everything* to do with broken functions in the green threads code. If you are interested, I can show you exactly where the null-pointer references are and let you make your own fixes. Once again, there actually are broken functions in green threads, this is independently verifiable, essentially by merely inspecting the code. > *sigh* Trying to have a conversation with you is worthless, so I'll > quit trying. Fine. I have a list of green threads source files that contain null-pointer references. You are lucky that you have never encountered them. I hope that you never do encounter them, as they involve broken assumptions about how things work on *BSD systems. You may return to your perfect world now. Those of us dealing with real world problems will continue to work on them ourselves. /Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 13:25:25 2001 Delivered-To: freebsd-java@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 1997A37B405 for ; Tue, 11 Dec 2001 13:25:20 -0800 (PST) Received: from caddis.yogotech.com (yogotech.nokia.com [4.22.66.156]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA12611; Tue, 11 Dec 2001 14:25:17 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fBBLPG301723; Tue, 11 Dec 2001 14:25:16 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15382.31164.312242.37083@caddis.yogotech.com> Date: Tue, 11 Dec 2001 14:25:16 -0700 To: Joe Kelsey Cc: nate@yogotech.com (Nate Williams), freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 In-Reply-To: <15382.30981.593865.40478@zircon.zircon.seattle.wa.us> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011210003200.C1152@absinthe> <15380.65513.794203.276229@caddis.yogotech.com> <20011211104902.GA8293@gnuppy> <15382.20613.76791.634824@caddis.yogotech.com> <15382.25038.873386.878424@zircon.zircon.seattle.wa.us> <15382.25997.525752.48613@caddis.yogotech.com> <15382.27453.18582.666321@zircon.zircon.seattle.wa.us> <15382.29273.887179.205335@caddis.yogotech.com> <15382.30981.593865.40478@zircon.zircon.seattle.wa.us> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [ EDONTCARETOARGUE ] Look Joe. I've been involved with the FreeBSD/JDK project for well over 3 years. I led the porting effort, and created *ALL* of the JDK1.1 releases, including doing bugfixing. I've spoken directly with the Sun engineers and had discussions concerning performance and buginess of green threads vs. native threads. I also understand why they dropped support for green threads in JDK1.4, as well as why there is a 'plugin'. You're simply wasting your time, since you have shown you really don't have any ideas why things work or don't work. All further email from you on this topic will be ignored, since you don't have anything to say that is meaningful. Have a Merry Christmas! Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 13:39:26 2001 Delivered-To: freebsd-java@freebsd.org Received: from zircon.seattle.wa.us (sense-sea-CovadSub-0-228.oz.net [216.39.147.228]) by hub.freebsd.org (Postfix) with SMTP id 2CAEE37B405 for ; Tue, 11 Dec 2001 13:39:22 -0800 (PST) Received: (qmail 74950 invoked by uid 1001); 11 Dec 2001 21:41:10 -0000 From: Joe Kelsey MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15382.32117.633615.124202@zircon.zircon.seattle.wa.us> Date: Tue, 11 Dec 2001 13:41:09 -0800 To: freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 In-Reply-To: <15382.31164.312242.37083@caddis.yogotech.com> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011210003200.C1152@absinthe> <15380.65513.794203.276229@caddis.yogotech.com> <20011211104902.GA8293@gnuppy> <15382.20613.76791.634824@caddis.yogotech.com> <15382.25038.873386.878424@zircon.zircon.seattle.wa.us> <15382.25997.525752.48613@caddis.yogotech.com> <15382.27453.18582.666321@zircon.zircon.seattle.wa.us> <15382.29273.887179.205335@caddis.yogotech.com> <15382.30981.593865.40478@zircon.zircon.seattle.wa.us> <15382.31164.312242.37083@caddis.yogotech.com> X-Mailer: VM 6.98 under Emacs 21.1.1 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Nate Williams writes: > [ EDONTCARETOARGUE ] > > Look Joe. I've been involved with the FreeBSD/JDK project for well over > 3 years. I led the porting effort, and created *ALL* of the JDK1.1 > releases, including doing bugfixing. How nice for you. What does that have to do with Java2? > I've spoken directly with the Sun engineers and had discussions > concerning performance and buginess of green threads vs. native threads. So? > You're simply wasting your time, since you have shown you really don't > have any ideas why things work or don't work. I have spent several weeks trying to get the plugin to work with green threads, and encountered bug after bug in the green threads code. As soon as I switched to native threads (thanks to Bill Huey), things resolved themselves much quicker. I understand how things work, and I also understand the broken assumptions used in the original green threads code that no longer hold. Its not my fault that you have no interest in finding out about these broken areas. > All further email from you on this topic will be ignored, since you > don't have anything to say that is meaningful. Pot, kettle, black. > Have a Merry Christmas! Happy Holidays! /Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 13:45:26 2001 Delivered-To: freebsd-java@freebsd.org Received: from calliope.cs.brandeis.edu (calliope.cs.brandeis.edu [129.64.3.189]) by hub.freebsd.org (Postfix) with ESMTP id B65D537B405 for ; Tue, 11 Dec 2001 13:45:24 -0800 (PST) Received: from localhost (meshko@localhost) by calliope.cs.brandeis.edu (8.9.3/8.9.3) with ESMTP id QAA03081 for ; Tue, 11 Dec 2001 16:45:23 -0500 Date: Tue, 11 Dec 2001 16:45:23 -0500 (EST) From: Mikhail Kruk To: Subject: Re: jdk1.3.1p5 In-Reply-To: <15382.32117.633615.124202@zircon.zircon.seattle.wa.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org what are you people arguing about? a) Green threads are not suited for use in plugin. (I know that because that's what Joe says and Nate is not arguing this point) b) Green threads work fine when you use them for running java applications. (I know that because I've been running a thread-intensive application for a month on patchset 5 without any problems, and because Nate says so, and because Joe doesn't argue with that either) So what the hell are you talking about??? I fail to notice any contradicition except in terms (green threads are completely broken vs green threads are not suited for plugin... whatever!) Please stop, you are scaring the children. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 14:33:34 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id 437FE37B41F for ; Tue, 11 Dec 2001 14:33:30 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16DvSg-0000Xs-00; Tue, 11 Dec 2001 14:33:18 -0800 Date: Tue, 11 Dec 2001 14:33:18 -0800 To: Daniel Eischen Cc: Bill Huey , Nate Williams , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] Message-ID: <20011211223318.GB2002@gnuppy> References: <20011211130254.GA9181@gnuppy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Dec 11, 2001 at 08:18:47AM -0500, Daniel Eischen wrote: > Yes, it is ;-). Please don't let anything like this get committed > without giving me a chance to deuglify it :-) :-) Oh, no, it's definitely not ready for CVS commit. It's definitely pure super-slop, but I needed to at least get it out so that folks that are responsible for the pthreads system can look at the logic and possibly reimplement it in the style and manner it's expected to be. Uh, 1) The timespec stuff seems ok since it cleans up the useage of it and treats it properly a vector with associated add/substract operations instead of just inserting random logic at those points. The might be a good style change for that part of the library. 2) The state_log stuff was essential for me to track down the bug in the first place and it's up to you whether you'd like to keep it in or not. It's sloppily pieced together at this point and I'm not in a place where I really care about that as much as just trying to get it and the JVM to work correctly in the first place. 3) The waiting queue recalculation stuff seems to be logically ok, but was also sloppily glued together. I only marginally care for the same reason as above. ;-) In summary, I'm basically lazy and would like you to fix all the problems with it. ;-) Hey, did I do ok with the patch ? Thanks bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 14:43:24 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id EA57337B405 for ; Tue, 11 Dec 2001 14:43:18 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16DvcI-0000ZO-00; Tue, 11 Dec 2001 14:43:14 -0800 Date: Tue, 11 Dec 2001 14:43:14 -0800 To: Nate Williams Cc: Bill Huey , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 Message-ID: <20011211224314.GA2131@gnuppy> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011210003200.C1152@absinthe> <15380.65513.794203.276229@caddis.yogotech.com> <20011211104902.GA8293@gnuppy> <15382.20613.76791.634824@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15382.20613.76791.634824@caddis.yogotech.com> User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Dec 11, 2001 at 11:29:25AM -0700, Nate Williams wrote: > [ > Continuing to play devil's advocate here. I believe native threading > is a step in the right direction, but it's certainly not the panacea > that is implied here. > ] ...a sign that you're too afraid to type -native on the command line. ;-) > > Then this kind > > "green threads is perfectly fine" juvenile attitude will properly die > > and be replaced by a "Our JVM is better than yours. yes, really, *PLEASE > > BITE ME*" and not this weak willed tone that folks are currently using > > in the BSD community. Now suck that down. ;-) > > You're certainly entitled to that opinion, but that opinion seems more > juvenile than the original one. :) What !!?!??! Ok, yeah, that's probably a bit over the edge since I'm chronically a very loud person and it was actually suppose to amuse you. ;-) Currently, I still have to track down a SIGUSR1 delivery bug and then look at the HotSpot sources again to see if it actually is suppose to work with green threads. I could have sworn that it doesn't or was missing critical files needs for this. After that, I'm not sure what's needed next for me to do. BTW, no WINE engineer position for now. The group I interviewed with isn't ready to deal with a production engineering staff just yet. bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 14:53:11 2001 Delivered-To: freebsd-java@freebsd.org Received: from zircon.seattle.wa.us (sense-sea-CovadSub-0-228.oz.net [216.39.147.228]) by hub.freebsd.org (Postfix) with SMTP id 394A737B405 for ; Tue, 11 Dec 2001 14:53:08 -0800 (PST) Received: (qmail 22653 invoked by uid 1001); 11 Dec 2001 22:54:57 -0000 From: Joe Kelsey MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15382.36545.652840.49374@zircon.zircon.seattle.wa.us> Date: Tue, 11 Dec 2001 14:54:57 -0800 To: Bill Huey Cc: Daniel Eischen , Nate Williams , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] In-Reply-To: <20011211223318.GB2002@gnuppy> References: <20011211130254.GA9181@gnuppy> <20011211223318.GB2002@gnuppy> X-Mailer: VM 6.98 under Emacs 21.1.1 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bill Huey writes: > Hey, did I do ok with the patch ? The patch seemed to apply cleanly. I am doing a build/install to get the new libc_r on my system right now. I will let you know how it works soon. /Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 15: 1:31 2001 Delivered-To: freebsd-java@freebsd.org Received: from web14303.mail.yahoo.com (web14303.mail.yahoo.com [216.136.173.79]) by hub.freebsd.org (Postfix) with SMTP id 4D71137B41D for ; Tue, 11 Dec 2001 15:01:28 -0800 (PST) Message-ID: <20011211230128.52245.qmail@web14303.mail.yahoo.com> Received: from [203.94.135.34] by web14303.mail.yahoo.com via HTTP; Tue, 11 Dec 2001 23:01:28 GMT Date: Tue, 11 Dec 2001 23:01:28 +0000 (GMT) From: =?iso-8859-1?q?shanon=20loveridge?= Subject: Bugs and Plugs To: freebsd-java@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org After reading the discussion that occurred from my question I have decided it would be best to use the native port. The main reason for this is that I would like to contribute to the project. At present this can only be done via testing and reporting bugs when found as I do not know C, If someone could point me towards the guidelines for bug reports that would be helpful, however this may change in the future. The only problem I have with this is that, AFAIK, you need to use the linux-mozilla port to use plugins in mozilla(java,flash etc..) and this requires linux-java port. Can this be accomplished by using the native JDK1.3.1 for development and a linux-JRE for the plugins (is there a JRE port?). Would there be an issue with having two versions of java on the system? Shanon __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 15: 5:46 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id 20D2637B416 for ; Tue, 11 Dec 2001 15:05:43 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16Dvxy-0000cK-00; Tue, 11 Dec 2001 15:05:38 -0800 Date: Tue, 11 Dec 2001 15:05:38 -0800 To: Nate Williams Cc: Bill Huey , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 Message-ID: <20011211230538.GA2264@gnuppy> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011211103039.GA8233@gnuppy> <15382.20310.915394.242516@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15382.20310.915394.242516@caddis.yogotech.com> User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Dec 11, 2001 at 11:24:22AM -0700, Nate Williams wrote: > I disagree, but we're all entitled to our own opinions. We don't need > HotSpot in order to be 'real'. Well, not to pressure this point too much further, but the reason why I'm doing this in the first place is because of what I've heard in the general JVM community about the need for HotSpot under the BSDs and that this need is critical for their operations. Under those assertions, it's seen by those folks as critical and I happened to agree with them about it. The bytecode interpreter is fast, but this is server side deployment I'm talking about and it's needed for setups that have high CPU load. The stature and technical origins of that compiler alone are significant enough to make it a key observable public piece in which people use to evaluate the JVM under FreeBSD. That's ultimately what I mean by "real". Those reason should be good enough that it should make getting native threading and HotSpot a very high priority item. That's all I've got to say on the subject. ;-) bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 15:13:46 2001 Delivered-To: freebsd-java@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 7C71637B405 for ; Tue, 11 Dec 2001 15:13:43 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id fBBNCbMs029889; Tue, 11 Dec 2001 18:12:37 -0500 (EST) Date: Tue, 11 Dec 2001 18:12:37 -0500 (EST) From: Daniel Eischen To: Bill Huey Cc: Nate Williams , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] In-Reply-To: <20011211223318.GB2002@gnuppy> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 11 Dec 2001, Bill Huey wrote: > On Tue, Dec 11, 2001 at 08:18:47AM -0500, Daniel Eischen wrote: > > Yes, it is ;-). Please don't let anything like this get committed > > without giving me a chance to deuglify it :-) :-) > > Oh, no, it's definitely not ready for CVS commit. It's definitely pure > super-slop, but I needed to at least get it out so that folks that are > responsible for the pthreads system can look at the logic and possibly > reimplement it in the style and manner it's expected to be. > > Uh, > > 1) The timespec stuff seems ok since it cleans up the useage of it and > treats it properly a vector with associated add/substract > operations instead of just inserting random logic at those > points. The might be a good style > change for that part of the library. I think there are already macros to handle timespec add and subtract, but they are not visible outside of the kernel (hidden behind #ifdef _KERNEL). > 2) The state_log stuff was essential for me to track down the bug in the > first place and it's up to you whether you'd like to keep it in > or not. It's sloppily pieced together at this point and I'm not > in a place where I really care about that as much as just trying > to get it and the JVM to work correctly in the first place. I'd rather get rid of it. > 3) The waiting queue recalculation stuff seems to be logically ok, but > was also sloppily glued together. I only marginally care for the > same reason as above. ;-) Not sure why this is needed. In general, wait times are in absolute times and blocking conditions internal to the threads library should be able to handle errant wakeups (so they don't return to the caller). This is essential for signal handling to work properly. If a thread waiting on a mutex or condition variable has to handle a signal, it needs to dequeue itself from the mutex/cv queue, run the signal handler, and then it returns to the mutex or cv routine (which detects the errant wakeup, requeues the thread, and calls the scheduler to block and schedule another thread again). > In summary, I'm basically lazy and would like you to fix all the > problems with it. ;-) That didn't look like a patch to -current libc_r; was it? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 15:43:55 2001 Delivered-To: freebsd-java@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 9924937B405 for ; Tue, 11 Dec 2001 15:43:48 -0800 (PST) Received: from caddis.yogotech.com (yogotech.nokia.com [4.22.66.156]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id QAA18190; Tue, 11 Dec 2001 16:43:40 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fBBNhdB02473; Tue, 11 Dec 2001 16:43:39 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15382.39466.681160.346406@caddis.yogotech.com> Date: Tue, 11 Dec 2001 16:43:38 -0700 To: Bill Huey Cc: Nate Williams , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 In-Reply-To: <20011211230538.GA2264@gnuppy> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011211103039.GA8233@gnuppy> <15382.20310.915394.242516@caddis.yogotech.com> <20011211230538.GA2264@gnuppy> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > I disagree, but we're all entitled to our own opinions. We don't need > > HotSpot in order to be 'real'. > > Well, not to pressure this point too much further, but the reason why > I'm doing this in the first place is because of what I've heard in the > general JVM community about the need for HotSpot under the BSDs and that > this need is critical for their operations. What's wrong with OpenJIT and TYA? HotSpot isn't the only JVM out there. As a matter of fact, it isn't necessarily the fastest JVM out there. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 16:59: 8 2001 Delivered-To: freebsd-java@freebsd.org Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by hub.freebsd.org (Postfix) with ESMTP id 233CC37B405 for ; Tue, 11 Dec 2001 16:59:05 -0800 (PST) Received: from rpsmtp1.aist.go.jp by mx1.aist.go.jp with ESMTP id fBC0x4022385 for ; Wed, 12 Dec 2001 09:59:04 +0900 (JST) env-from (k.shudou@aist.go.jp) Received: from mail01.aist.go.jp by rpsmtp1.aist.go.jp with ESMTP id fBC0x3P02532 for ; Wed, 12 Dec 2001 09:59:03 +0900 (JST) env-from (k.shudou@aist.go.jp) Received: from localhost by mail01.aist.go.jp with ESMTP id fBC0x2C05927 for ; Wed, 12 Dec 2001 09:59:02 +0900 (JST) env-from (k.shudou@aist.go.jp) To: freebsd-java@FreeBSD.ORG Subject: Native, kernel and user-space threads From: shudo@computer.org X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011212095914G.shudoh@aist.go.jp> Date: Wed, 12 Dec 2001 09:59:14 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 24 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I wanna be convinced of the meaning of `native' threads. Currently, FreeBSD (release and stable) does not have a threading mechanism implemented in kernel space. I suppose native threads you refer is a threads library which have POSIX threads API and implemented in user space. Is this true? If so, the present difference between native threads and green threads seems to be their own APIs. Both of them are user-space threading libraries. Migration to the POSIX interface is worth much to support forthcoming Java 2 SDK 1.4. But, what are real present merits of native threads without kernel threading for JDK users? I have been satisfied by green threads implementations on Linux and FreeBSD while developing a JIT compiler for them over three years. It performs faster than Linux (kernel) threads with many applications because it is implemented in user space. I do not have SMP machines :) Kazuyuki Shudo shudo@computer.org http://www.shudo.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 17:22:27 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id ECF2137B416 for ; Tue, 11 Dec 2001 17:22:24 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16Dy6E-0000pq-00; Tue, 11 Dec 2001 17:22:18 -0800 Date: Tue, 11 Dec 2001 17:22:18 -0800 To: Daniel Eischen Cc: Bill Huey , Nate Williams , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] Message-ID: <20011212012218.GA3199@gnuppy> References: <20011211223318.GB2002@gnuppy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Dec 11, 2001 at 06:12:37PM -0500, Daniel Eischen wrote: > > 3) The waiting queue recalculation stuff seems to be logically ok, but > > was also sloppily glued together. I only marginally care for the > > same reason as above. ;-) > > Not sure why this is needed. In general, wait times are in absolute > times and blocking conditions internal to the threads library should > be able to handle errant wakeups (so they don't return to the caller). > This is essential for signal handling to work properly. If a thread > waiting on a mutex or condition variable has to handle a signal, it > needs to dequeue itself from the mutex/cv queue, run the signal handler, > and then it returns to the mutex or cv routine (which detects the > errant wakeup, requeues the thread, and calls the scheduler to block > and schedule another thread again). Maybe a different kind of suspend operation is needed or the semantics of how I interpreted it should be different in that when the GC thread is run, that should block out and prevent any thread from running, changing state to waking until it's done with the collection. Maybe I should allow it to timeout and then only change state to PS_COND_WAIT, etc... at the point where it gets resumed. What do you think ? > > In summary, I'm basically lazy and would like you to fix all the > > problems with it. ;-) > > That didn't look like a patch to -current libc_r; was it? I'm not running -current, so I don't know. bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 17:26:56 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id F0A2E37B416 for ; Tue, 11 Dec 2001 17:26:53 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16DyAc-0000qo-00; Tue, 11 Dec 2001 17:26:50 -0800 Date: Tue, 11 Dec 2001 17:26:50 -0800 To: Nate Williams Cc: Bill Huey , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 Message-ID: <20011212012650.GB3199@gnuppy> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011211103039.GA8233@gnuppy> <15382.20310.915394.242516@caddis.yogotech.com> <20011211230538.GA2264@gnuppy> <15382.39466.681160.346406@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15382.39466.681160.346406@caddis.yogotech.com> User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Dec 11, 2001 at 04:43:38PM -0700, Nate Williams wrote: > What's wrong with OpenJIT and TYA? HotSpot isn't the only JVM out > there. As a matter of fact, it isn't necessarily the fastest JVM out > there. Because it's not commerical and it's not from Sun. Regardless of how technically able those compilers are they are not going to compare to the perception that HotSpot has currently and will make the FreeBSD JVM project only be percieved as second rate until it's fully working. It works under Win32, Linux, etc... so it must work with FreeBSD. It's as simple as that and industry pressure driven regardless of the technical merits of those compilers. And from what I've seen from benchmarks, HotSpot is still closely competitive to the IBM compiler which is considered to be the fastest around. bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 20: 3:47 2001 Delivered-To: freebsd-java@freebsd.org Received: from chen.org.nz (tnt1-93.quicksilver.net.nz [202.89.142.93]) by hub.freebsd.org (Postfix) with ESMTP id C640137B416 for ; Tue, 11 Dec 2001 20:03:43 -0800 (PST) Received: (from jonc@localhost) by chen.org.nz (8.11.6/8.11.6) id fBC458C17762 for freebsd-java@freebsd.org; Wed, 12 Dec 2001 17:05:08 +1300 (NZDT) (envelope-from jonc) Date: Wed, 12 Dec 2001 17:05:06 +1300 From: Jonathan Chen To: freebsd-java@freebsd.org Subject: Installing JBuilder 5 with native JDK1.3.1 Message-ID: <20011212170506.A16371@grimoire.chen.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I'm trying to install JBuilder 5 (downloaded jb5_linux.tar.gz) using the native JDK 1.3.1 VM. After I've unpacked it, I try a: ./per_install.bin LAX_VM /usr/local/jdk1.3.1/bin/java the install appears to start up fine, but bombs when it tries to create "/lib/temp". Relevant debug logs: [...] InstallUninstaller size: 566 CDS: Free Disk Space in bytes == 257968128 CDS: Required Disk Space in bytes == 107140621 Setting install umask. /bin/sh -c umask 022 = 0 InstallUninstaller size: 566 Installer: Exception occurred while installing java.lang.Exception: Failed to create installDir /lib/temp at com.zerog.ia.installer.GhostDirectory.installSelf([DashoPro-V1.2-120198]) at com.zerog.ia.installer.Action.install([DashoPro-V1.2-120198]) at com.zerog.ia.installer.GhostDirectory.install([DashoPro-V1.2-120198]) at com.zerog.ia.installer.Installer.install([DashoPro-V1.2-120198]) at ZeroGj0.run([DashoPro-V1.2-120198]) [...] As far as I can work out, it isn't setting the install directory correctly, that's why it's attempting to install to "/lib" instead of "./lib". Any here managed to install this successfully? Cheers. -- Jonathan Chen ---------------------------------------------------------------------- "Opportunity does not knock, it presents itself when you beat down the door" - W.E. Channing To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 20: 8:12 2001 Delivered-To: freebsd-java@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 2C87C37B41B for ; Tue, 11 Dec 2001 20:08:07 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id fBC46tXW011876; Tue, 11 Dec 2001 23:06:55 -0500 (EST) Date: Tue, 11 Dec 2001 23:06:55 -0500 (EST) From: Daniel Eischen To: Bill Huey Cc: Nate Williams , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] In-Reply-To: <20011212012218.GA3199@gnuppy> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 11 Dec 2001, Bill Huey wrote: > On Tue, Dec 11, 2001 at 06:12:37PM -0500, Daniel Eischen wrote: > > > 3) The waiting queue recalculation stuff seems to be logically ok, but > > > was also sloppily glued together. I only marginally care for the > > > same reason as above. ;-) > > > > Not sure why this is needed. In general, wait times are in absolute > > times and blocking conditions internal to the threads library should > > be able to handle errant wakeups (so they don't return to the caller). > > This is essential for signal handling to work properly. If a thread > > waiting on a mutex or condition variable has to handle a signal, it > > needs to dequeue itself from the mutex/cv queue, run the signal handler, > > and then it returns to the mutex or cv routine (which detects the > > errant wakeup, requeues the thread, and calls the scheduler to block > > and schedule another thread again). > > Maybe a different kind of suspend operation is needed or the semantics > of how I interpreted it should be different in that when the GC thread is > run, that should block out and prevent any thread from running, changing > state to waking until it's done with the collection. Maybe I should allow > it to timeout and then only change state to PS_COND_WAIT, etc... at the > point where it gets resumed. I don't understand what is wrong with pthread_suspend_np and pthread_resume_np (not the suspend/resume that suspend all threads). Suspending and resuming all should do the same as suspending and resuming one, but for all threads except for the current thread. If a thread is in a CV wait, its state is PS_COND_WAIT. If it was in a timed wait, the thread's timeout is set accordingly (to the absolute time). If the thread then gets suspended, the suspension state gets set to SUSP_COND_WAIT indicating that it is both suspended and in a CV wait. The thread should still be in the waiting queue, so the scheduler will time it out if the wakeup time elapses. If the thread timesout, then the scheduler should see that it is suspended and not add it to the run queue; it should also set the suspended state to SUSP_NO. So it looks to me like the problem is that the scheduler is waking up the thread and making it runnable before it is resumed. Is that the case? Does the following look like it might solve the problem? Index: uthread_kern.c =================================================================== RCS file: /opt/d/CVS/src/lib/libc_r/uthread/uthread_kern.c,v retrieving revision 1.38 diff -u -r1.38 uthread_kern.c --- uthread_kern.c 4 May 2001 20:37:07 -0000 1.38 +++ uthread_kern.c 12 Dec 2001 04:15:35 -0000 @@ -387,6 +387,10 @@ ((pthread->wakeup_time.tv_sec == ts.tv_sec) && (pthread->wakeup_time.tv_nsec <= ts.tv_nsec)))) { switch (pthread->state) { + case PS_SUSPENDED: + PTHREAD_WAITQ_REMOVE(pthread); + pthread->suspended = SUSP_YES; + break; case PS_POLL_WAIT: case PS_SELECT_WAIT: /* Return zero file descriptors ready: */ -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 20:10:12 2001 Delivered-To: freebsd-java@freebsd.org Received: from daedalus.cs.brandeis.edu (daedalus.cs.brandeis.edu [129.64.3.179]) by hub.freebsd.org (Postfix) with ESMTP id 491E037B416 for ; Tue, 11 Dec 2001 20:10:09 -0800 (PST) Received: from localhost (meshko@localhost) by daedalus.cs.brandeis.edu (8.9.3/8.9.3) with ESMTP id XAA01259; Tue, 11 Dec 2001 23:10:01 -0500 Date: Tue, 11 Dec 2001 23:10:01 -0500 (EST) From: Mikhail Kruk To: Jonathan Chen Cc: Subject: Re: Installing JBuilder 5 with native JDK1.3.1 In-Reply-To: <20011212170506.A16371@grimoire.chen.org.nz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Why do you think it should try ./lib/temp? Do you specify the install path anywhere in the installer? Try giving it a full path, not relative. It might do something weird with '.' Well, all I can say for sure is that I'm running otehr InstallAnywhere installers on native 1.3.1 w/o any problems. On Wed, 12 Dec 2001, Jonathan Chen wrote: > Hi, > > I'm trying to install JBuilder 5 (downloaded jb5_linux.tar.gz) using > the native JDK 1.3.1 VM. After I've unpacked it, I try a: > > ./per_install.bin LAX_VM /usr/local/jdk1.3.1/bin/java > > the install appears to start up fine, but bombs when it tries to create > "/lib/temp". Relevant debug logs: > > [...] > InstallUninstaller size: 566 > CDS: Free Disk Space in bytes == 257968128 > CDS: Required Disk Space in bytes == 107140621 > Setting install umask. > /bin/sh -c umask 022 = 0 > InstallUninstaller size: 566 > Installer: Exception occurred while installing > java.lang.Exception: Failed to create installDir /lib/temp > at com.zerog.ia.installer.GhostDirectory.installSelf([DashoPro-V1.2-120198]) > at com.zerog.ia.installer.Action.install([DashoPro-V1.2-120198]) > at com.zerog.ia.installer.GhostDirectory.install([DashoPro-V1.2-120198]) > at com.zerog.ia.installer.Installer.install([DashoPro-V1.2-120198]) > at ZeroGj0.run([DashoPro-V1.2-120198]) > [...] > > As far as I can work out, it isn't setting the install directory > correctly, that's why it's attempting to install to "/lib" instead of > "./lib". Any here managed to install this successfully? > > Cheers. > -- > Jonathan Chen > ---------------------------------------------------------------------- > "Opportunity does not knock, > it presents itself when you beat down the door" - W.E. Channing > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-java" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 20:13:38 2001 Delivered-To: freebsd-java@freebsd.org Received: from dragon.realtime.net (dragon.realtime.net [205.238.128.89]) by hub.freebsd.org (Postfix) with SMTP id A30BF37B405 for ; Tue, 11 Dec 2001 20:13:35 -0800 (PST) Received: from tigerfish2.my.domain ([66.25.208.136]) by dragon.realtime.net ; Tue, 11 Dec 2001 20:50:39 -0600 Received: (from brucegb@localhost) by tigerfish2.my.domain (8.11.6/8.11.1) id fBC2sTS02646 for freebsd-java@freebsd.org; Tue, 11 Dec 2001 20:54:29 -0600 (CST) (envelope-from brucegb) Date: Tue, 11 Dec 2001 20:54:29 -0600 From: Bruce Burden To: freebsd-java@freebsd.org Subject: Compiling jdk1.3.1 Message-ID: <20011211205429.R28452@tigerfish2.my.domain> References: <20011211130254.GA9181@gnuppy> <20011211223318.GB2002@gnuppy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011211223318.GB2002@gnuppy>; from billh@gnuppy.monkey.org on Tue, Dec 11, 2001 at 02:33:18PM -0800 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi gang, I am looking for pointers to correct this problem: /usr/bin/sed -e 's!interpreter\.o!../../../build/bsd-i386/tmp/java/java.lang/jvm/obj/&!g' > ../../../build/bsd-i386/tmp/java/java.lang/jvm/obj/interpreter.d /usr/local/linux-jdk1.3.1/bin/javac -J-Xmx64m -classpath ../../../build/bsd-i386/classes -bootclasspath "" -sourcepath "../../../build/bsd-i386/gensrc:../../../src/solaris/classes:../../../src/share/classes" -d ../../../build/bsd-i386/classes -d ../../../build/bsd-i386/tmp/java/java.lang/jvm/obj -nowarn ../../../src/share/javavm/runtime/InvokerGen.java rm -f ../../../build/bsd-i386/tmp/java/java.lang/jvm/obj/invokers.c /usr/local/linux-jdk1.3.1/bin/java -classpath ../../../build/bsd-i386/tmp/java/java.lang/jvm/obj InvokerGen < ../../../src/share/javavm/include/invokers.txt > ../../../build/bsd-i386/tmp/java/java.lang/jvm/obj/invokers.c Exception in thread "main" java.lang.NoClassDefFoundError: InvokerGen gmake[3]: *** [../../../build/bsd-i386/tmp/java/java.lang/jvm/obj/invokers.c] Error 1 gmake[3]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' gmake[2]: *** [optimized] Error 2 gmake[2]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' gmake[1]: *** [all] Error 1 gmake[1]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java' gmake: *** [all] Error 1 *** Error code 2 I believe that I have the correct patch code installed, although I can't find it right now. Since others have got this code to compile, I must be missing something obvious... Thanks, Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 20:57:57 2001 Delivered-To: freebsd-java@freebsd.org Received: from chen.org.nz (tnt1-89.quicksilver.net.nz [202.89.142.89]) by hub.freebsd.org (Postfix) with ESMTP id 79DCC37B419 for ; Tue, 11 Dec 2001 20:57:48 -0800 (PST) Received: (from jonc@localhost) by chen.org.nz (8.11.6/8.11.6) id fBC4wYS19249; Wed, 12 Dec 2001 17:58:34 +1300 (NZDT) (envelope-from jonc) Date: Wed, 12 Dec 2001 17:58:32 +1300 From: Jonathan Chen To: Mikhail Kruk Cc: freebsd-java@freebsd.org Subject: Re: Installing JBuilder 5 with native JDK1.3.1 Message-ID: <20011212175832.A17889@grimoire.chen.org.nz> References: <20011212170506.A16371@grimoire.chen.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meshko@cs.brandeis.edu on Tue, Dec 11, 2001 at 11:10:01PM -0500 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Dec 11, 2001 at 11:10:01PM -0500, Mikhail Kruk wrote: > Why do you think it should try ./lib/temp? Do you specify the install path > anywhere in the installer? Try giving it a full path, not relative. It > might do something weird with '.' > Well, all I can say for sure is that I'm running otehr InstallAnywhere > installers on native 1.3.1 w/o any problems. *I* personally don't care whether it tries /lib/temp or not. I'm just saying that the install bombs out; and the error that causes it to bomb out is the installation program's attempt to create /lib/temp. This is failing 'cos I'm installing this as a non-root user, and I *really* don't want to install this as root, especially if it's going to litter up my system with wierd files lying every which where. Cheers. -- Jonathan Chen ---------------------------------------------------------------------- "If everything's under control, you're going too slow" - Mario Andretti To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 21: 0:10 2001 Delivered-To: freebsd-java@freebsd.org Received: from chen.org.nz (tnt1-89.quicksilver.net.nz [202.89.142.89]) by hub.freebsd.org (Postfix) with ESMTP id 8ACE237B405 for ; Tue, 11 Dec 2001 21:00:06 -0800 (PST) Received: (from jonc@localhost) by chen.org.nz (8.11.6/8.11.6) id fBC519d19293; Wed, 12 Dec 2001 18:01:09 +1300 (NZDT) (envelope-from jonc) Date: Wed, 12 Dec 2001 18:01:07 +1300 From: Jonathan Chen To: Mikhail Kruk Cc: freebsd-java@FreeBSD.ORG Subject: Re: Installing JBuilder 5 with native JDK1.3.1 Message-ID: <20011212180107.B17889@grimoire.chen.org.nz> References: <20011212170506.A16371@grimoire.chen.org.nz> <20011212175832.A17889@grimoire.chen.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011212175832.A17889@grimoire.chen.org.nz>; from jonc@chen.org.nz on Wed, Dec 12, 2001 at 05:58:32PM +1300 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Dec 12, 2001 at 05:58:32PM +1300, Jonathan Chen wrote: > On Tue, Dec 11, 2001 at 11:10:01PM -0500, Mikhail Kruk wrote: > > Why do you think it should try ./lib/temp? Do you specify the install path > > anywhere in the installer? Try giving it a full path, not relative. It > > might do something weird with '.' > > Well, all I can say for sure is that I'm running otehr InstallAnywhere > > installers on native 1.3.1 w/o any problems. > > *I* personally don't care whether it tries /lib/temp or not. I'm just > saying that the install bombs out; and the error that causes it to bomb > out is the installation program's attempt to create /lib/temp. This is > failing 'cos I'm installing this as a non-root user, and I *really* don't > want to install this as root, especially if it's going to litter up my > system with wierd files lying every which where. Incidentally, invoking the installer with an absolute pathname still gives the same error. -- Jonathan Chen ---------------------------------------------------------------------- The Internet: an empirical test of the idea that a million monkeys banging on a million keyboards can produce Shakespeare To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 21: 8:51 2001 Delivered-To: freebsd-java@freebsd.org Received: from daedalus.cs.brandeis.edu (daedalus.cs.brandeis.edu [129.64.3.179]) by hub.freebsd.org (Postfix) with ESMTP id 9B9E137B419 for ; Tue, 11 Dec 2001 21:08:49 -0800 (PST) Received: from localhost (meshko@localhost) by daedalus.cs.brandeis.edu (8.9.3/8.9.3) with ESMTP id AAA01641; Wed, 12 Dec 2001 00:08:46 -0500 Date: Wed, 12 Dec 2001 00:08:45 -0500 (EST) From: Mikhail Kruk To: Jonathan Chen Cc: Subject: Re: Installing JBuilder 5 with native JDK1.3.1 In-Reply-To: <20011212180107.B17889@grimoire.chen.org.nz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > *I* personally don't care whether it tries /lib/temp or not. I'm just > > saying that the install bombs out; and the error that causes it to bomb Well, if it bombs out because of the incorrect input you might want to care... > Incidentally, invoking the installer with an absolute pathname still > gives the same error. That is strange. Can you try running it in console mode (usually InstallAnywhere allow that) and show your complete interaction with installer? Most likely it's either mistake in Borland's installer or user error. Then again.. you have the latest patchset (5) right? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 22:15: 1 2001 Delivered-To: freebsd-java@freebsd.org Received: from mgr1.xmission.com (mgr1.xmission.com [198.60.22.201]) by hub.freebsd.org (Postfix) with ESMTP id 1ADEC37B405 for ; Tue, 11 Dec 2001 22:14:56 -0800 (PST) Received: from [207.135.128.145] (helo=misty.eyesbeyond.com) by mgr1.xmission.com with esmtp (Exim 3.22 #1) id 16E2fN-0007sU-00; Tue, 11 Dec 2001 23:14:54 -0700 Received: (from glewis@localhost) by misty.eyesbeyond.com (8.11.6/8.11.6) id fBC6EmS87534; Wed, 12 Dec 2001 16:44:48 +1030 (CST) (envelope-from glewis) Date: Wed, 12 Dec 2001 16:44:47 +1030 From: Greg Lewis To: shudo@computer.org Cc: freebsd-java@FreeBSD.ORG Subject: Re: Native, kernel and user-space threads Message-ID: <20011212164447.A87498@misty.eyesbeyond.com> References: <20011212095914G.shudoh@aist.go.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011212095914G.shudoh@aist.go.jp>; from shudo@computer.org on Wed, Dec 12, 2001 at 09:59:14AM +0900 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Dec 12, 2001 at 09:59:14AM +0900, shudo@computer.org wrote: > I wanna be convinced of the meaning of `native' threads. > > Currently, FreeBSD (release and stable) does not have a > threading mechanism implemented in kernel space. I > suppose native threads you refer is a threads library > which have POSIX threads API and implemented in user > space. Is this true? This is exactly the case. There is a userland threads library which implements the POSIX threads API (libc_r). > If so, the present difference between native threads and > green threads seems to be their own APIs. Both of them > are user-space threading libraries. Migration to the > POSIX interface is worth much to support forthcoming > Java 2 SDK 1.4. But, what are real present merits of > native threads without kernel threading for JDK users? There has already been a small flamefest on that topic today and I'm not about to join in :). However, as you mention, JDK 1.4 will no longer support green threads. We believe at this time, without having seen the 1.4 code, that a native threads implementation for JDK 1.3 will be useful both in getting a JDK 1.4 port going and in getting HotSpot and the Java Plugin to work in JDK 1.3. > I have been satisfied by green threads implementations > on Linux and FreeBSD while developing a JIT compiler for > them over three years. It performs faster than Linux > (kernel) threads with many applications because it is > implemented in user space. I do not have SMP machines :) I think many people have used green threads without any major problems both for their own use and in production systems. I know I have. Personally I would have preferred Sun kept green threads around, if only because it meant the underlying threading system behaved similarly across all platforms. But thats just my opinion :). -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Phone : (801) 796 6999 Information Technology Web : http://www.eyesbeyond.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 22:17:14 2001 Delivered-To: freebsd-java@freebsd.org Received: from mgr1.xmission.com (mgr1.xmission.com [198.60.22.201]) by hub.freebsd.org (Postfix) with ESMTP id 2A89437B405 for ; Tue, 11 Dec 2001 22:17:08 -0800 (PST) Received: from [207.135.128.145] (helo=misty.eyesbeyond.com) by mgr1.xmission.com with esmtp (Exim 3.22 #1) id 16E2hW-000828-00; Tue, 11 Dec 2001 23:17:06 -0700 Received: (from glewis@localhost) by misty.eyesbeyond.com (8.11.6/8.11.6) id fBC6H2087563; Wed, 12 Dec 2001 16:47:02 +1030 (CST) (envelope-from glewis) Date: Wed, 12 Dec 2001 16:47:02 +1030 From: Greg Lewis To: Bruce Burden Cc: freebsd-java@FreeBSD.ORG Subject: Re: Compiling jdk1.3.1 Message-ID: <20011212164702.B87498@misty.eyesbeyond.com> References: <20011211130254.GA9181@gnuppy> <20011211223318.GB2002@gnuppy> <20011211205429.R28452@tigerfish2.my.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011211205429.R28452@tigerfish2.my.domain>; from brucegb@realtime.net on Tue, Dec 11, 2001 at 08:54:29PM -0600 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Dec 11, 2001 at 08:54:29PM -0600, Bruce Burden wrote: > I am looking for pointers to correct this problem: > > /usr/bin/sed -e 's!interpreter\.o!../../../build/bsd-i386/tmp/java/java.lang/jvm/obj/&!g' > ../../../build/bsd-i386/tmp/java/java.lang/jvm/obj/interpreter.d > /usr/local/linux-jdk1.3.1/bin/javac -J-Xmx64m -classpath ../../../build/bsd-i386/classes -bootclasspath "" -sourcepath "../../../build/bsd-i386/gensrc:../../../src/solaris/classes:../../../src/share/classes" -d ../../../build/bsd-i386/classes -d ../../../build/bsd-i386/tmp/java/java.lang/jvm/obj -nowarn ../../../src/share/javavm/runtime/InvokerGen.java > rm -f ../../../build/bsd-i386/tmp/java/java.lang/jvm/obj/invokers.c > /usr/local/linux-jdk1.3.1/bin/java -classpath ../../../build/bsd-i386/tmp/java/java.lang/jvm/obj InvokerGen < ../../../src/share/javavm/include/invokers.txt > ../../../build/bsd-i386/tmp/java/java.lang/jvm/obj/invokers.c > Exception in thread "main" java.lang.NoClassDefFoundError: InvokerGen > > I believe that I have the correct patch code installed, although I can't > find it right now. Since others have got this code to compile, I must be > missing something obvious... Please have a look through the mailing list archives. This problem crops up from time to time and is due to a bug in the Linux emulation layer. I can't recall the exact cause and solution. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Phone : (801) 796 6999 Information Technology Web : http://www.eyesbeyond.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 23:28:17 2001 Delivered-To: freebsd-java@freebsd.org Received: from eicn.ch (webmail.eicn.ch [157.26.64.11]) by hub.freebsd.org (Postfix) with ESMTP id BF0E937B405 for ; Tue, 11 Dec 2001 23:28:14 -0800 (PST) Received: from wireless-networks.com [157.26.81.95] by eicn.ch with ESMTP (SMTPD32-6.00) id A70811900B0; Wed, 12 Dec 2001 08:28:08 +0100 Message-ID: <3C170708.3020104@wireless-networks.com> Date: Wed, 12 Dec 2001 08:28:08 +0100 From: Cedric Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Joe Kelsey Cc: freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011210003200.C1152@absinthe> <15380.65513.794203.276229@caddis.yogotech.com> <20011211104902.GA8293@gnuppy> <15382.20613.76791.634824@caddis.yogotech.com> <15382.25038.873386.878424@zircon.zircon.seattle.wa.us> <15382.25997.525752.48613@caddis.yogotech.com> <15382.27453.18582.666321@zircon.zircon.seattle.wa.us> <15382.29273.887179. Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 205335@caddis.yogotech.com> <15382.30981.593865.40478@zircon.zircon.seattle.wa.us> <15382.31164.312242.37083@caddis.yogotech.com> <15382.32117.633615.124202@zircon.zircon.seattle.wa.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > >> You're simply wasting your time, since you have shown you really don't > > have any ideas why things work or don't work. > >I have spent several weeks trying to get the plugin to work with green >threads, and encountered bug after bug in the green threads code. As >soon as I switched to native threads (thanks to Bill Huey), things >resolved themselves much quicker. I understand how things work, and I >also understand the broken assumptions used in the original green >threads code that no longer hold. Its not my fault that you have no >interest in finding out about these broken areas. > Does the plugin use JNI? If the answer is YES, there is no doubt green threads won't work. Green threads + JNI = hell. Cedric To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 23:34:10 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id 12F1637B41C for ; Tue, 11 Dec 2001 23:34:07 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16E3tv-0001Et-00; Tue, 11 Dec 2001 23:33:59 -0800 Date: Tue, 11 Dec 2001 23:33:58 -0800 To: Daniel Eischen Cc: Bill Huey , Nate Williams , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] Message-ID: <20011212073358.GA4677@gnuppy> References: <20011212012218.GA3199@gnuppy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Dec 11, 2001 at 11:06:55PM -0500, Daniel Eischen wrote: > I don't understand what is wrong with pthread_suspend_np and > pthread_resume_np (not the suspend/resume that suspend all > threads). Suspending and resuming all should do the same as > suspending and resuming one, but for all threads except for > the current thread. > > If a thread is in a CV wait, its state is PS_COND_WAIT. If it > was in a timed wait, the thread's timeout is set accordingly (to > the absolute time). If the thread then gets suspended, the > suspension state gets set to SUSP_COND_WAIT indicating that it > is both suspended and in a CV wait. The thread should still > be in the waiting queue, so the scheduler will time it out if > the wakeup time elapses. If the thread timesout, then the > scheduler should see that it is suspended and not add it to > the run queue; it should also set the suspended state to > SUSP_NO. > > So it looks to me like the problem is that the scheduler is > waking up the thread and making it runnable before it is > resumed. Is that the case? Does the following look like > it might solve the problem? > > Index: uthread_kern.c > =================================================================== > RCS file: /opt/d/CVS/src/lib/libc_r/uthread/uthread_kern.c,v > retrieving revision 1.38 > diff -u -r1.38 uthread_kern.c > --- uthread_kern.c 4 May 2001 20:37:07 -0000 1.38 > +++ uthread_kern.c 12 Dec 2001 04:15:35 -0000 > @@ -387,6 +387,10 @@ > ((pthread->wakeup_time.tv_sec == ts.tv_sec) && > (pthread->wakeup_time.tv_nsec <= ts.tv_nsec)))) { > switch (pthread->state) { > + case PS_SUSPENDED: > + PTHREAD_WAITQ_REMOVE(pthread); > + pthread->suspended = SUSP_YES; > + break; > case PS_POLL_WAIT: > case PS_SELECT_WAIT: > /* Return zero file descriptors ready: */ Yes, this is roughly the problem that I'm talking about. The timeout operation in the waiting queue marks the thread PS_RUNNING without checking to see if it's already marked PS_SUSPENDED. It should check to see if it's PS_SUSPENDED, keep it suspended until a resume operation is requested. It currently wakes the thread regardless of this when it times out in the waiting queue which isn't what I'd like in a suspend all operation in it allows for threads to run when I want it to be completely stopped until the GC completes. The only logical case that something like this happens is in pthread_cond_timedwait(). Am I making sense ? bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Tue Dec 11 23:43:49 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id 0E67037B405 for ; Tue, 11 Dec 2001 23:43:47 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16E43K-0001Fu-00; Tue, 11 Dec 2001 23:43:42 -0800 Date: Tue, 11 Dec 2001 23:43:42 -0800 To: Daniel Eischen Cc: Bill Huey , Nate Williams , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] Message-ID: <20011212074342.GB4677@gnuppy> References: <20011212012218.GA3199@gnuppy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Dec 11, 2001 at 11:06:55PM -0500, Daniel Eischen wrote: > So it looks to me like the problem is that the scheduler is > waking up the thread and making it runnable before it is > resumed. Is that the case? Does the following look like > it might solve the problem? > > Index: uthread_kern.c > =================================================================== > RCS file: /opt/d/CVS/src/lib/libc_r/uthread/uthread_kern.c,v > retrieving revision 1.38 > diff -u -r1.38 uthread_kern.c > --- uthread_kern.c 4 May 2001 20:37:07 -0000 1.38 > +++ uthread_kern.c 12 Dec 2001 04:15:35 -0000 > @@ -387,6 +387,10 @@ > ((pthread->wakeup_time.tv_sec == ts.tv_sec) && > (pthread->wakeup_time.tv_nsec <= ts.tv_nsec)))) { > switch (pthread->state) { > + case PS_SUSPENDED: > + PTHREAD_WAITQ_REMOVE(pthread); > + pthread->suspended = SUSP_YES; > + break; > case PS_POLL_WAIT: > case PS_SELECT_WAIT: > /* Return zero file descriptors ready: */ > Dan Eischen [/me thinks] ... Hmmm, whether this solves the problem and keeps it marked as PS_SUSPENDED, I don't really know since I'm pretty much a neophyte at pthreads internals, but I'm hoping that I articulate the problem clear enough that you can find a more direct fix for this problem. The thing that I don't see in that logic is how it can restore the PS_COND_WAIT state before the suspend attempt. I'd normally think that "thread->suspended = SUSP_COND_WAIT" would be needed so that it can be remarked PS_COND_WAIT when a resume operation is requested. I don't see how it can be put into that state in the other parts of the pthreads library or if that's a relevant consideration. bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Wed Dec 12 1:45:34 2001 Delivered-To: freebsd-java@freebsd.org Received: from shikima.mine.nu (pc1-card4-0-cust77.cdf.cable.ntl.com [62.252.49.77]) by hub.freebsd.org (Postfix) with ESMTP id 8565C37B405 for ; Wed, 12 Dec 2001 01:45:30 -0800 (PST) Received: from rasputin by shikima.mine.nu with local (Exim 3.33 #1) id 16E5zE-0001G1-00; Wed, 12 Dec 2001 09:47:36 +0000 Date: Wed, 12 Dec 2001 09:47:36 +0000 From: Rasputin To: shanon loveridge Cc: java@freebsd.org Subject: Re: Bugs and Plugs Message-ID: <20011212094736.A4768@shikima.mine.nu> Reply-To: Rasputin References: <20011211230128.52245.qmail@web14303.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011211230128.52245.qmail@web14303.mail.yahoo.com>; from shanon_loveridge@yahoo.co.uk on Tue, Dec 11, 2001 at 11:01:28PM +0000 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * shanon loveridge [011211 23:05]: > After reading the discussion that occurred from my > question I have decided it would be best to use the > native port. The main reason for this is that I would > like to contribute to the project. At present this can > only be done via testing and reporting bugs when found > as I do not know C, If someone could point me towards > the guidelines for bug reports that would be helpful, > however this may change in the future. man send-pr(1), or post to the list. > The only problem I have with this is that, AFAIK, you > need to use the linux-mozilla port to use plugins in > mozilla(java,flash etc..) and this requires linux-java > port. Can this be accomplished by using the native > JDK1.3.1 for development and a linux-JRE for the > plugins (is there a JRE port?). Would there be an > issue with having two versions of java on the system? Multiple JVMs aren't any problem, since none of them are in your PATH by default. rasputin@shikima mozilla]$ls /var/db/pkg|grep jdk jdk-1.1.8 jdk-1.3.1p5 jdk-doc-1.3.1 linux-jdk-1.3.1.01_1 rasputin@shikima mozilla]$which java /usr/local/jdk1.3.1/bin/java Also, I don't think you need to install the linux-jdk to use Mozilla (though I could be wrong) - I found that (linux) Mozilla didn't want to use my linux-jdk13 install, but happily downloaded a JRE the first time I went to a Java-enabled site. A moot point really, since you need the linux-jdk13 port to build the native 1.3 port anyway...... -- While money doesn't buy love, it puts you in a great bargaining position. Rasputin :: Jack of All Trades - Master of Nuns :: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Wed Dec 12 2: 3:58 2001 Delivered-To: freebsd-java@freebsd.org Received: from draco.macsch.com (draco.macsch.com [192.73.8.1]) by hub.freebsd.org (Postfix) with ESMTP id 0E61F37B416 for ; Wed, 12 Dec 2001 02:03:56 -0800 (PST) Received: from mailmuc.muc.eu.mscsoftware.com (mailmuc.muc.macsch.com [161.34.37.20]) by draco.macsch.com (8.9.3/8.9.3) with ESMTP id BAA25067; Wed, 12 Dec 2001 01:59:26 -0800 (PST) Received: from hunter.muc.macsch.com (hunter.muc.macsch.com [172.17.22.32]) by mailmuc.muc.eu.mscsoftware.com (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id fBCA3ZL15109; Wed, 12 Dec 2001 11:03:35 +0100 Received: from hunter.muc.macsch.com (localhost.muc.macsch.com [127.0.0.1]) by hunter.muc.macsch.com (8.11.6/8.11.6) with ESMTP id fBCA3L501068; Wed, 12 Dec 2001 11:03:21 +0100 (CET) (envelope-from Georg.Koltermann@mscsoftware.com) Date: Wed, 12 Dec 2001 11:03:21 +0100 Message-ID: From: Georg-W Koltermann To: nate@yogotech.com (Nate Williams) Cc: Bill Huey , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 In-Reply-To: <15382.39466.681160.346406@caddis.yogotech.com> References: <20011210001702.10731.qmail@web14303.mail.yahoo.com> <20011210024138.GA3148@gnuppy> <20011209223635.A1152@absinthe> <15380.15272.167683.46148@caddis.yogotech.com> <20011211103039.GA8233@gnuppy> <15382.20310.915394.242516@caddis.yogotech.com> <20011211230538.GA2264@gnuppy> <15382.39466.681160.346406@caddis.yogotech.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) Organization: MSC Software X-Attribution: gwk MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At Tue, 11 Dec 2001 16:43:38 -0700, Nate Williams wrote: >=20 > > > I disagree, but we're all entitled to our own opinions. We don't need > > > HotSpot in order to be 'real'. > >=20 > > Well, not to pressure this point too much further, but the reason why > > I'm doing this in the first place is because of what I've heard in the > > general JVM community about the need for HotSpot under the BSDs and that > > this need is critical for their operations. >=20 > What's wrong with OpenJIT and TYA? HotSpot isn't the only JVM out > there. As a matter of fact, it isn't necessarily the fastest JVM out > there. Would it be a good investment of time to develop a real fast JVM for FreeBSD, instead of reusing Suns (Hotspot) JVM like everybody else does? Hotspot is in active development at Sun while the classic VM was dropped. I'd say we should follow suit just in order to reuse their effort and not spend time do duplicate their effort. I'm not technically involved with any JVM implementation, so I can't comment on which approach is technically superior. I am just suggesting that we should cooperate with the path taken by other JVM development/porting teams. =46rom a user's perspective Hotspot vs. classic is a real difference. Try to run an interactive tool like Together/J with a classic VM (I use FreeBSD JDK1.3.1/green-threads with OpenJIT) and then again with Hotspot (my colleague uses Linux with Sun's Hotspot VM). You will notice that working with this caliber of a Java application, and not having Hotspot, IS A REAL PAIN. --=20 Regards, Georg. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Wed Dec 12 4: 3: 3 2001 Delivered-To: freebsd-java@freebsd.org Received: from puget.esil.univ-mrs.fr (puget.esil.univ-mrs.fr [139.124.41.103]) by hub.freebsd.org (Postfix) with ESMTP id 5545037B416 for ; Wed, 12 Dec 2001 04:02:58 -0800 (PST) Received: from localhost (hquiroz@localhost) by puget.esil.univ-mrs.fr (8.11.6/8.11.6) with ESMTP id fBCC9cg73571 for ; Wed, 12 Dec 2001 13:09:42 +0100 (CET) (envelope-from herve.quiroz@esil.univ-mrs.fr) X-Authentication-Warning: puget.esil.univ-mrs.fr: hquiroz owned process doing -bs Date: Wed, 12 Dec 2001 13:09:37 +0100 (CET) From: Herve Quiroz X-X-Sender: hquiroz@puget.esil.univ-mrs.fr To: freebsd-java@freebsd.org Subject: java lib Message-ID: <20011212130905.A73569-100000@puget.esil.univ-mrs.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I was wondering... Do you guys install third party java libs (such as NanoXML, JDOM, Log4J...) in a system path common to all users (such as /usr/local/.../java) or let users install their own libs and manage them in their own home directory ? I was also thinking to have all libs and java-related stuff (except the JVM itself) in the home directory of a new user called 'java'. For now I am the only user that uses java on my machine but as a system admin I want to do it a "pure" and nice way so what sounds best for you ? Note: if installing libs in a system path, maybe it would be nice to make freebsd ports of the java libs to have them install a clean way... Herve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Wed Dec 12 4: 6:35 2001 Delivered-To: freebsd-java@freebsd.org Received: from zaphod.euronet.nl (zaphod.euronet.nl [194.134.128.241]) by hub.freebsd.org (Postfix) with ESMTP id 9582E37B420 for ; Wed, 12 Dec 2001 04:06:21 -0800 (PST) Received: by zaphod.euronet.nl (8.11.6/8.11.6) id fBCC6A423032; Wed, 12 Dec 2001 13:06:10 +0100 (CET) (envelope-from ernst) Message-Id: <200112121206.fBCC6A423032@zaphod.euronet.nl> Content-Type: text/plain; charset="iso-8859-1" From: Ernst de Haan Organization: EuroNet Internet B.V. To: Herve Quiroz , freebsd-java@freebsd.org Subject: Re: java lib Date: Wed, 12 Dec 2001 13:06:08 +0100 X-Mailer: KMail [version 1.3] References: <20011212130905.A73569-100000@puget.esil.univ-mrs.fr> In-Reply-To: <20011212130905.A73569-100000@puget.esil.univ-mrs.fr> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Herve, One of our (my) goals is to complete the bsd.port.mk and then port a lot of Java libraries in a standard way, including ORO, Log4J, Xerces, Xalan, JDOM, JAXP, MySQL mm JDBC drivers, JUnit, Poolman, JavaMail, DocCheck, JTA, etc. Ernst On Wednesday 12 December 2001 13:09, Herve Quiroz wrote: > I was wondering... > > Do you guys install third party java libs (such as NanoXML, JDOM, > Log4J...) in a system path common to all users (such as > /usr/local/.../java) or let users install their own libs and manage them > in their own home directory ? I was also thinking to have all libs and > java-related stuff (except the JVM itself) in the home directory of a > new user called 'java'. > For now I am the only user that uses java on my machine but as a system > admin I want to do it a "pure" and nice way so what sounds best for you ? > > Note: if installing libs in a system path, maybe it would be nice to make > freebsd ports of the java libs to have them install a clean way... > > > Herve > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-java" in the body of the message -- Ernst de Haan EuroNet Internet B.V. "Come to me all who are weary and burdened and I will give you rest" -- Jesus Christ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Wed Dec 12 4:28:41 2001 Delivered-To: freebsd-java@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 2DF9337B405 for ; Wed, 12 Dec 2001 04:28:36 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id fBCCOCBr012831; Wed, 12 Dec 2001 07:24:12 -0500 (EST) Date: Wed, 12 Dec 2001 07:24:12 -0500 (EST) From: Daniel Eischen To: Bill Huey Cc: Bill Huey , Nate Williams , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] In-Reply-To: <20011212074342.GB4677@gnuppy> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 11 Dec 2001, Bill Huey wrote: > On Tue, Dec 11, 2001 at 11:06:55PM -0500, Daniel Eischen wrote: > > So it looks to me like the problem is that the scheduler is > > waking up the thread and making it runnable before it is > > resumed. Is that the case? Does the following look like > > it might solve the problem? > > > > Index: uthread_kern.c > > =================================================================== > > RCS file: /opt/d/CVS/src/lib/libc_r/uthread/uthread_kern.c,v > > retrieving revision 1.38 > > diff -u -r1.38 uthread_kern.c > > --- uthread_kern.c 4 May 2001 20:37:07 -0000 1.38 > > +++ uthread_kern.c 12 Dec 2001 04:15:35 -0000 > > @@ -387,6 +387,10 @@ > > ((pthread->wakeup_time.tv_sec == ts.tv_sec) && > > (pthread->wakeup_time.tv_nsec <= ts.tv_nsec)))) { > > switch (pthread->state) { > > + case PS_SUSPENDED: > > + PTHREAD_WAITQ_REMOVE(pthread); > > + pthread->suspended = SUSP_YES; > > + break; > > case PS_POLL_WAIT: > > case PS_SELECT_WAIT: > > /* Return zero file descriptors ready: */ > > Dan Eischen > > [/me thinks] > > ... > > Hmmm, whether this solves the problem and keeps it marked as PS_SUSPENDED, > I don't really know since I'm pretty much a neophyte at pthreads internals, > but I'm hoping that I articulate the problem clear enough that you can > find a more direct fix for this problem. Yes, this should keep the state equal to PS_SUSPENDED. When the thread is resumed, its state should be set to PS_RUNNING and then it will be added back to the run queue. > The thing that I don't see in that logic is how it can restore the > PS_COND_WAIT state before the suspend attempt. I'd normally think that > "thread->suspended = SUSP_COND_WAIT" would be needed so that it can be > remarked PS_COND_WAIT when a resume operation is requested. I don't see > how it can be put into that state in the other parts of the pthreads library > or if that's a relevant consideration. Suspsended threads are not placed in the waiting queue unless they are _already_ in the waiting queue (e.g. due to waiting on a condition variable). Any thread that is in the waiti queue and times out should become runnable unless it is suspended, in which case it should just be removed from the waiting queue and remain in a suspended state. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Wed Dec 12 5: 6: 0 2001 Delivered-To: freebsd-java@freebsd.org Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by hub.freebsd.org (Postfix) with ESMTP id 27DE737B417 for ; Wed, 12 Dec 2001 05:05:57 -0800 (PST) Received: from rpsmtp1.aist.go.jp by mx1.aist.go.jp with ESMTP id fBCD5t008310 for ; Wed, 12 Dec 2001 22:05:55 +0900 (JST) env-from (k.shudou@aist.go.jp) Received: from mail12.aist.go.jp by rpsmtp1.aist.go.jp with ESMTP id fBCD5tk19959 for ; Wed, 12 Dec 2001 22:05:55 +0900 (JST) env-from (k.shudou@aist.go.jp) Received: from localhost by mail12.aist.go.jp with ESMTP id fBCD5sO09545 for ; Wed, 12 Dec 2001 22:05:54 +0900 (JST) env-from (k.shudou@aist.go.jp) To: freebsd-java@FreeBSD.ORG Subject: Re: jdk1.3.1p5 From: shudo@computer.org In-Reply-To: References: <20011211230538.GA2264@gnuppy> <15382.39466.681160.346406@caddis.yogotech.com> X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011212220605N.shudoh@aist.go.jp> Date: Wed, 12 Dec 2001 22:06:05 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 24 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Georg-W Koltermann wrote: > >From a user's perspective Hotspot vs. classic is a real difference. > Try to run an interactive tool like Together/J with a classic VM (I > use FreeBSD JDK1.3.1/green-threads with OpenJIT) and then again with > Hotspot (my colleague uses Linux with Sun's Hotspot VM). You will > notice that working with this caliber of a Java application, and not > having Hotspot, IS A REAL PAIN. OpenJIT takes long start-up time because a large part of the compiler is written in Java language itself. The compiler compiles itself and most of the self compilation is carried out by the bytecode interpreter of the Classic VM. IBM Jikes RVM, formerly known as Jalapeno, is a JVM written in Java. It will also needs long time to warm itself up. So developers of the JVM say it is for server-side. Jikes RVM http://www-124.ibm.com/developerworks/opensource/jikesrvm/ Kazuyuki Shudo shudo@computer.org http://www.shudo.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Wed Dec 12 8:40:50 2001 Delivered-To: freebsd-java@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 1461137B417 for ; Wed, 12 Dec 2001 08:40:25 -0800 (PST) Received: from caddis.yogotech.com (yogotech.nokia.com [4.22.66.156]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id JAA28417; Wed, 12 Dec 2001 09:40:21 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fBCGeFc06104; Wed, 12 Dec 2001 09:40:15 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15383.34926.828024.362022@caddis.yogotech.com> Date: Wed, 12 Dec 2001 09:40:14 -0700 To: shudo@computer.org Cc: freebsd-java@FreeBSD.ORG Subject: Re: Native, kernel and user-space threads In-Reply-To: <20011212095914G.shudoh@aist.go.jp> References: <20011212095914G.shudoh@aist.go.jp> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I wanna be convinced of the meaning of `native' threads. > > Currently, FreeBSD (release and stable) does not have a > threading mechanism implemented in kernel space. I > suppose native threads you refer is a threads library > which have POSIX threads API and implemented in user > space. Is this true? Correct. > If so, the present difference between native threads and > green threads seems to be their own APIs. Again, you are correctly diagnosing the situation. > Both of them > are user-space threading libraries. Migration to the > POSIX interface is worth much to support forthcoming > Java 2 SDK 1.4. But, what are real present merits of > native threads without kernel threading for JDK users? Because the POSIX (pthreads) interface is used by additional software such as HotSpot. Performance for both should be equal, although I suspect the green threads port may be less buggy/more stable than the pthreads port in the short term since it's had more time to have all it's bug worked out. > I have been satisfied by green threads implementations > on Linux and FreeBSD while developing a JIT compiler for > them over three years. It performs faster than Linux > (kernel) threads with many applications because it is > implemented in user space. I do not have SMP machines :) This is the case for many applications. However, a good kernel threads implementation (not the one in Linux) should do a good job of keeping as many threads runnable as possible. This is the intent of the FreeBSD kernel threads implementation. Solaris kernel threads do a fairly good job of balancing out performance such that applications works fairly well in both green and kernel threads environment, and in those cases where kernel threads are a win, the default of using kernel threads provides a big win. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Wed Dec 12 12:55:29 2001 Delivered-To: freebsd-java@freebsd.org Received: from ssec.wisc.edu (ssec.wisc.edu [144.92.108.61]) by hub.freebsd.org (Postfix) with ESMTP id 2CAC337B41C; Wed, 12 Dec 2001 12:55:21 -0800 (PST) Received: from hyde.ssec.wisc.edu (root@hyde.ssec.wisc.edu [128.104.109.251]) by ssec.wisc.edu (8.9.3/8.9.3) with ESMTP id OAA19012; Wed, 12 Dec 2001 14:55:15 -0600 Received: from hyde.ssec.wisc.edu (localhost [127.0.0.1]) by hyde.ssec.wisc.edu (8.10.2+Sun/8.10.2) with ESMTP id fBCKt7k25350; Wed, 12 Dec 2001 14:55:07 -0600 (CST) Message-Id: <200112122055.fBCKt7k25350@hyde.ssec.wisc.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-gnats-submit@FreeBSD.ORG, java@FreeBSD.ORG Subject: Re: ports/32223: Port databases/mysql-jdbc-mm is quite outdated Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Dec 2001 14:55:07 -0600 From: Dave Glowacki Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Here is the latest version of the mysql-jdbc-mm port. It builds everything from source, but is currently marked BROKEN because two essential .jar files included in the distribution are corrupted, so the port cannot build. I'm hoping that the next version of the distribution file will contain usable .jar files. In order to build the port, a user would need to download jdbc2_0-stdext.jar from http://java.sun.com/products/jdbc/download.html under the JDBC 2.0 Optional Package section, and jta-spec1_0_1.jar from http://java.sun.com/products/jta/. The JTA jar file must be extracted from the downloaded zip file and renamed to jta-spec1_0_1.jar After both files have been downloaded, the Makefile needs to be edited to remove the BROKEN line. After this, the user should run 'make extract'. When that finishes, the two downloaded jar files should be copied to work/mm.mysql-2.0.8/lib. After this, the build will proceed as normal. diff -ru mysql-jdbc-mm.old/Makefile mysql-jdbc-mm/Makefile --- mysql-jdbc-mm.old/Makefile Fri Jun 1 06:49:08 2001 +++ mysql-jdbc-mm/Makefile Wed Dec 12 12:18:11 2001 @@ -5,29 +5,68 @@ # $FreeBSD: ports/databases/mysql-jdbc-mm/Makefile,v 1.7 2001/06/01 11:49:08 jeh Exp $ # +BROKEN= Distribution contains bad JAR files. + PORTNAME= mysql-jdbc-mm -PORTVERSION= 1.2c +PORTVERSION= 2.0.8 CATEGORIES= databases java -MASTER_SITES= http://mmmysql.sourceforge.net/dist/ -DISTNAME= mm.mysql.jdbc-${PORTVERSION} +MASTER_SITES= ${MASTER_SITE_SOURCEFORGE} +MASTER_SITE_SUBDIR= mmmysql +DISTNAME= mm.mysql-${PORTVERSION} +EXTRACT_SUFX= -you-must-unjar-me.jar MAINTAINER= dglo@SSEC.WISC.EDU -BUILD_DEPENDS= ${LOCALBASE}/jdk1.1.8/bin/javac:${PORTSDIR}/java/jdk +BUILD_DEPENDS= ${JAVA_HOME}/bin/javac:${PORTSDIR}/java/jdk13 \ + ant:${PORTSDIR}/devel/jakarta-ant +RUN_DEPENDS= ${JAVA_HOME}/bin/java:${PORTSDIR}/java/jdk13 + +JAVA_HOME?= ${PREFIX}/jdk1.3.1 + +EXTRACT_CMD= ${JAVA_HOME}/bin/jar +EXTRACT_BEFORE_ARGS= -xf -ALL_TARGET= jar +post-patch: + @(cd ${WRKSRC}; ${MV} build.xml build.xml.patched; \ + ${SED} -e "s;%%WRKSRC%%;${WRKSRC};g" -e "s;%%PREFIX%%;${PREFIX};g" \ + < build.xml.patched > build.xml) + @(cd ${WRKSRC}; ${MV} j1c j1c.patched; \ + ${SED} "s;%%PREFIX%%;${PREFIX};g" < j1c.patched > j1c; \ + ${CHMOD} 555 j1c) + +do-build: + @(cd ${WRKSRC}; ${SETENV} JAVA_HOME=${JAVA_HOME} ant clean dist) +.if !defined(NOPORTDOCS) + @(cd ${WRKSRC}; ${MKDIR} doc; \ + ${JAVA_HOME}/bin/javadoc -d doc -package \ + -classpath ${WRKSRC}:${WRKSRC}/lib/jdbc2_0-stdext.jar:${WRKSRC}/lib/jta-spec1_0_1.jar:${CLASSPATH} \ + org.gjt.mm.mysql org.gjt.mm.mysql.jdbc2) +.endif do-install: @${MKDIR} ${PREFIX}/share/java/classes - @${INSTALL_DATA} ${WRKSRC}/mysql_comp.jar ${LOCALBASE}/share/java/classes - -post-install: + @${INSTALL_DATA} ${WRKSRC}/build/mm.mysql-${PORTVERSION}/mm.mysql-${PORTVERSION}-bin.jar \ + ${PREFIX}/share/java/classes/mm.mysql-${PORTVERSION}.jar + @${INSTALL_DATA} ${WRKSRC}/lib/jdbc2_0-stdext.jar \ + ${PREFIX}/share/java/classes/ + @${INSTALL_DATA} ${WRKSRC}/lib/jta-spec1_0_1.jar \ + ${PREFIX}/share/java/classes/ .if !defined(NOPORTDOCS) @${MKDIR} ${PREFIX}/share/doc/mysql-jdbc @(cd ${WRKSRC}/doc && ${TAR} -c -f - .) \ | (cd ${PREFIX}/share/doc/mysql-jdbc && ${TAR} --unlink -x -f -) +.endif + +post-install: + @${ECHO} share/java/classes/mm.mysql-${PORTVERSION}.jar >> ${TMPPLIST} + @${ECHO} share/java/classes/jdbc2_0-stdext.jar >> ${TMPPLIST} + @${ECHO} share/java/classes/jta-spec1_0_1.jar >> ${TMPPLIST} +.if !defined(NOPORTDOCS) @(cd ${PREFIX} \ && find share/doc/mysql-jdbc -type f -print >> ${TMPPLIST}) + @${ECHO} "@dirrm share/doc/mysql-jdbc" >> ${TMPPLIST} .endif + @${ECHO} "@unexec ${RMDIR} %D/share/java/classes 2>/dev/null || true" >> ${TMPPLIST} + @${ECHO} "@unexec ${RMDIR} %D/share/java 2>/dev/null || true" >> ${TMPPLIST} .include diff -ru mysql-jdbc-mm.old/distinfo mysql-jdbc-mm/distinfo --- mysql-jdbc-mm.old/distinfo Sat Apr 29 20:09:57 2000 +++ mysql-jdbc-mm/distinfo Fri Nov 30 11:19:55 2001 @@ -1 +1 @@ -MD5 (mm.mysql.jdbc-1.2c.tar.gz) = b04aa7f3048c2ebb169ee88ce19a6a4c +MD5 (mm.mysql-2.0.8-you-must-unjar-me.jar) = b496f9ad5be7afb21d3f05902b2805a0 diff -ru mysql-jdbc-mm.old/files/patch-Makefile mysql-jdbc-mm/files/patch-Makefile --- mysql-jdbc-mm.old/files/patch-Makefile Fri Jun 1 06:49:08 2001 +++ mysql-jdbc-mm/files/patch-Makefile Wed Dec 12 12:39:45 2001 @@ -1,21 +0,0 @@ ---- Makefile.orig Sun May 27 12:10:22 2001 -+++ Makefile Sun May 27 12:16:18 2001 -@@ -3,14 +3,16 @@ - # $Id: Makefile,v 1.2 1998/08/25 04:02:25 mmatthew Exp $ - # - --JAVAC = /usr/local/jdk118/bin/javac -+JAVA_HOME = /usr/local/jdk1.1.8 -+JAVAC = JAVA_HOME=$(JAVA_HOME) CLASSPATH= $(JAVA_HOME)/bin/javac -+JAR = JAVA_HOME=$(JAVA_HOME) CLASSPATH= $(JAVA_HOME)/bin/jar - JAVAC_FLAGS =-O -g - - all: - $(JAVAC) $(JAVAC_FLAGS) org/gjt/mm/mysql/*.java - - jar: all -- jar -cv0f mysql_uncomp.jar org/gjt/mm/mysql/*.class; jar -cvf mysql_comp.jar org/gjt/mm/mysql/*.class -+ $(JAR) -cv0f mysql_uncomp.jar org/gjt/mm/mysql/*.class; $(JAR) -cvf mysql_comp.jar org/gjt/mm/mysql/*.class - - clean: - rm -f org/gjt/mm/mysql/*.class org/gjt/mm/mysql/*~ diff -ru mysql-jdbc-mm.old/files/patch-build.xml mysql-jdbc-mm/files/patch-build.xml --- mysql-jdbc-mm.old/files/patch-build.xml Wed Dec 12 12:39:28 2001 +++ mysql-jdbc-mm/files/patch-build.xml Fri Nov 30 14:29:35 2001 @@ -0,0 +1,21 @@ +--- build.xml.orig Fri Nov 30 11:00:04 2001 ++++ build.xml Fri Nov 30 11:03:37 2001 +@@ -1,7 +1,7 @@ + + +- +- ++ ++ + + + +@@ -51,7 +51,7 @@ + + + +- ++ + + + diff -ru mysql-jdbc-mm.old/files/patch-j1c mysql-jdbc-mm/files/patch-j1c --- mysql-jdbc-mm.old/files/patch-j1c Wed Dec 12 12:39:28 2001 +++ mysql-jdbc-mm/files/patch-j1c Thu Nov 29 18:00:12 2001 @@ -0,0 +1,10 @@ +--- j1c.orig Thu Nov 29 16:26:08 2001 ++++ j1c Thu Nov 29 16:26:36 2001 +@@ -0,0 +1,7 @@ ++#!/bin/sh ++ ++JAVAC_1=%%PREFIX%%/jdk1.1.8/bin/javac ++ ++unset JAVA_HOME LD_LIBRARY_PATH LD_PRELOAD CLASSPATH ++ ++exec "$JAVAC_1" "$@" diff -ru mysql-jdbc-mm.old/pkg-plist mysql-jdbc-mm/pkg-plist --- mysql-jdbc-mm.old/pkg-plist Sat Jan 29 16:23:06 2000 +++ mysql-jdbc-mm/pkg-plist Thu Nov 29 18:00:12 2001 @@ -1 +1 @@ -share/java/classes/mysql_comp.jar + To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Wed Dec 12 13:55:29 2001 Delivered-To: freebsd-java@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 2867F37B405 for ; Wed, 12 Dec 2001 13:55:25 -0800 (PST) Received: (qmail 12301 invoked by uid 0); 12 Dec 2001 21:55:23 -0000 Received: from p3ee37de0.dip.t-dialin.net (HELO volker) (62.227.125.224) by mail.gmx.net (mp010-rz3) with SMTP; 12 Dec 2001 21:55:23 -0000 From: "Volker Sturm" To: Subject: J2EE and Forte? Date: Wed, 12 Dec 2001 22:53:30 +0100 Message-ID: <000001c18357$709e9900$0100a8c0@volker> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I am using J2EE and Forte on Windows. On FreeBSD I installed the linux-jdk1.3.1 and the native one. Forte failed to install cos I didnt find the .class file (Seems the version distributed by sun has changed). Maybe I just didnt find it, but: can i install the J2EE on FreeBSD? Regards, Volker Sturm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Wed Dec 12 16: 7:44 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id A989E37B416 for ; Wed, 12 Dec 2001 16:07:41 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16EJPN-0000yd-00; Wed, 12 Dec 2001 16:07:29 -0800 Date: Wed, 12 Dec 2001 16:07:29 -0800 To: Daniel Eischen Cc: Bill Huey , Nate Williams , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] Message-ID: <20011213000729.GA3743@gnuppy> References: <20011212074342.GB4677@gnuppy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Dec 12, 2001 at 07:24:12AM -0500, Daniel Eischen wrote: > Yes, this should keep the state equal to PS_SUSPENDED. When the thread > is resumed, its state should be set to PS_RUNNING and then it will be > added back to the run queue. ... > Suspsended threads are not placed in the waiting queue unless they > are _already_ in the waiting queue (e.g. due to waiting on a condition > variable). Any thread that is in the waiti queue and times out should > become runnable unless it is suspended, in which case it should just > be removed from the waiting queue and remain in a suspended state. I'll try this latter on today and see if it works. billh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Wed Dec 12 22:32:27 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id 4744237B416 for ; Wed, 12 Dec 2001 22:32:24 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16EPPb-0001us-00; Wed, 12 Dec 2001 22:32:07 -0800 Date: Wed, 12 Dec 2001 22:32:07 -0800 To: Daniel Eischen Cc: Bill Huey , freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] Message-ID: <20011213063207.GA7359@gnuppy> References: <20011212074342.GB4677@gnuppy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Dec 12, 2001 at 07:24:12AM -0500, Daniel Eischen wrote: > > > diff -u -r1.38 uthread_kern.c > > > --- uthread_kern.c 4 May 2001 20:37:07 -0000 1.38 > > > +++ uthread_kern.c 12 Dec 2001 04:15:35 -0000 > > > @@ -387,6 +387,10 @@ > > > ((pthread->wakeup_time.tv_sec == ts.tv_sec) && > > > (pthread->wakeup_time.tv_nsec <= ts.tv_nsec)))) { > > > switch (pthread->state) { > > > + case PS_SUSPENDED: > > > + PTHREAD_WAITQ_REMOVE(pthread); > > > + pthread->suspended = SUSP_YES; > > > + break; > > > case PS_POLL_WAIT: > > > case PS_SELECT_WAIT: > > > /* Return zero file descriptors ready: */ > > > Dan Eischen > > Yes, this should keep the state equal to PS_SUSPENDED. When the thread > is resumed, its state should be set to PS_RUNNING and then it will be > added back to the run queue. This didn't work. A thread would SEGV and then the entire thing blows up shortly afterward in a wierd kind of delayed signal delivery way. bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Thu Dec 13 0:19:54 2001 Delivered-To: freebsd-java@freebsd.org Received: from daedalus.cs.brandeis.edu (daedalus.cs.brandeis.edu [129.64.3.179]) by hub.freebsd.org (Postfix) with ESMTP id B59E637B416 for ; Thu, 13 Dec 2001 00:19:52 -0800 (PST) Received: from localhost (meshko@localhost) by daedalus.cs.brandeis.edu (8.9.3/8.9.3) with ESMTP id DAA06053 for ; Thu, 13 Dec 2001 03:19:51 -0500 Date: Thu, 13 Dec 2001 03:19:51 -0500 (EST) From: Mikhail Kruk To: Subject: JBuilder 5 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Following the yesterdays question I've decided to actually try to install JBuilder 5 on FreeBSD and got some interesting problems with that... I've gone through many painful moves to work around it's attempts to work with built in linux jre 1.3.0 distribution (which came w/o green threads for some reason); I've made it use native jdk1.3.1. But it refuses to read zip archive! It just ignores it all together. If I unzip it it actually starts the installer but it crashes almost immediately because, I think, I tries to get locales from the zip file and doesn't find it. Anyone knows what may be wrong with 1.3.1 and zip files? Actually I've tried linux-jdk1.3.0 and got the same results... doesn't want to read from the zip file. I'm confused. I don't even want JBuilder that much :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Thu Dec 13 0:28:35 2001 Delivered-To: freebsd-java@freebsd.org Received: from zaphod.euronet.nl (zaphod.euronet.nl [194.134.128.241]) by hub.freebsd.org (Postfix) with ESMTP id 8D0CB37B405; Thu, 13 Dec 2001 00:28:26 -0800 (PST) Received: (from ernst@localhost) by zaphod.euronet.nl (8.11.6/8.11.6) id fBD8SNg03244; Thu, 13 Dec 2001 09:28:23 +0100 (CET) (envelope-from ernst) Message-Id: <200112130828.fBD8SNg03244@zaphod.euronet.nl> Content-Type: text/plain; charset="iso-8859-1" From: Ernst de Haan Organization: EuroNet Internet B.V. To: Dave Glowacki , freebsd-gnats-submit@FreeBSD.ORG, java@FreeBSD.ORG Subject: Re: ports/32223: Port databases/mysql-jdbc-mm is quite outdated Date: Thu, 13 Dec 2001 09:28:23 +0100 X-Mailer: KMail [version 1.3] References: <200112122055.fBCKt7k25350@hyde.ssec.wisc.edu> In-Reply-To: <200112122055.fBCKt7k25350@hyde.ssec.wisc.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm not going to commit this one because we would be moving from a working port to a broken port. I prefer having an older version that works over a newer version that doesn't work. And would not it be possible to instruct the user to download the specified files from java.sun.com in a way similar to the way the JDK ports ask the user to download the distfiles? Ernst On Wednesday 12 December 2001 21:55, Dave Glowacki wrote: > Here is the latest version of the mysql-jdbc-mm port. > It builds everything from source, but is currently > marked BROKEN because two essential .jar files included > in the distribution are corrupted, so the port cannot > build. I'm hoping that the next version of the > distribution file will contain usable .jar files. > > In order to build the port, a user would need to download > jdbc2_0-stdext.jar from http://java.sun.com/products/jdbc/download.html > under the JDBC 2.0 Optional Package section, and > jta-spec1_0_1.jar from http://java.sun.com/products/jta/. > The JTA jar file must be extracted from the downloaded > zip file and renamed to jta-spec1_0_1.jar > > After both files have been downloaded, the Makefile needs > to be edited to remove the BROKEN line. > > After this, the user should run 'make extract'. When that > finishes, the two downloaded jar files should be copied to > work/mm.mysql-2.0.8/lib. After this, the build will proceed > as normal. > > diff -ru mysql-jdbc-mm.old/Makefile mysql-jdbc-mm/Makefile > --- mysql-jdbc-mm.old/Makefile Fri Jun 1 06:49:08 2001 > +++ mysql-jdbc-mm/Makefile Wed Dec 12 12:18:11 2001 > @@ -5,29 +5,68 @@ > # $FreeBSD: ports/databases/mysql-jdbc-mm/Makefile,v 1.7 2001/06/01 > 11:49:08 jeh Exp $ # > > +BROKEN= Distribution contains bad JAR files. > + > PORTNAME= mysql-jdbc-mm > -PORTVERSION= 1.2c > +PORTVERSION= 2.0.8 > CATEGORIES= databases java > -MASTER_SITES= http://mmmysql.sourceforge.net/dist/ > -DISTNAME= mm.mysql.jdbc-${PORTVERSION} > +MASTER_SITES= ${MASTER_SITE_SOURCEFORGE} > +MASTER_SITE_SUBDIR= mmmysql > +DISTNAME= mm.mysql-${PORTVERSION} > +EXTRACT_SUFX= -you-must-unjar-me.jar > > MAINTAINER= dglo@SSEC.WISC.EDU > > -BUILD_DEPENDS= ${LOCALBASE}/jdk1.1.8/bin/javac:${PORTSDIR}/java/jdk > +BUILD_DEPENDS= ${JAVA_HOME}/bin/javac:${PORTSDIR}/java/jdk13 \ > + ant:${PORTSDIR}/devel/jakarta-ant > +RUN_DEPENDS= ${JAVA_HOME}/bin/java:${PORTSDIR}/java/jdk13 > + > +JAVA_HOME?= ${PREFIX}/jdk1.3.1 > + > +EXTRACT_CMD= ${JAVA_HOME}/bin/jar > +EXTRACT_BEFORE_ARGS= -xf > > -ALL_TARGET= jar > +post-patch: > + @(cd ${WRKSRC}; ${MV} build.xml build.xml.patched; \ > + ${SED} -e "s;%%WRKSRC%%;${WRKSRC};g" -e "s;%%PREFIX%%;${PREFIX};g" \ > + < build.xml.patched > build.xml) > + @(cd ${WRKSRC}; ${MV} j1c j1c.patched; \ > + ${SED} "s;%%PREFIX%%;${PREFIX};g" < j1c.patched > j1c; \ > + ${CHMOD} 555 j1c) > + > +do-build: > + @(cd ${WRKSRC}; ${SETENV} JAVA_HOME=${JAVA_HOME} ant clean dist) > +.if !defined(NOPORTDOCS) > + @(cd ${WRKSRC}; ${MKDIR} doc; \ > + ${JAVA_HOME}/bin/javadoc -d doc -package \ > + -classpath > ${WRKSRC}:${WRKSRC}/lib/jdbc2_0-stdext.jar:${WRKSRC}/lib/jta-spec1_0_1.jar: >${CLASSPATH} \ + org.gjt.mm.mysql org.gjt.mm.mysql.jdbc2) > +.endif > > do-install: > @${MKDIR} ${PREFIX}/share/java/classes > - @${INSTALL_DATA} ${WRKSRC}/mysql_comp.jar ${LOCALBASE}/share/java/classes > - > -post-install: > + @${INSTALL_DATA} > ${WRKSRC}/build/mm.mysql-${PORTVERSION}/mm.mysql-${PORTVERSION}-bin.jar \ > + ${PREFIX}/share/java/classes/mm.mysql-${PORTVERSION}.jar > + @${INSTALL_DATA} ${WRKSRC}/lib/jdbc2_0-stdext.jar \ > + ${PREFIX}/share/java/classes/ > + @${INSTALL_DATA} ${WRKSRC}/lib/jta-spec1_0_1.jar \ > + ${PREFIX}/share/java/classes/ > .if !defined(NOPORTDOCS) > @${MKDIR} ${PREFIX}/share/doc/mysql-jdbc > @(cd ${WRKSRC}/doc && ${TAR} -c -f - .) \ > > | (cd ${PREFIX}/share/doc/mysql-jdbc && ${TAR} --unlink -x -f -) > > +.endif > + > +post-install: > + @${ECHO} share/java/classes/mm.mysql-${PORTVERSION}.jar >> ${TMPPLIST} > + @${ECHO} share/java/classes/jdbc2_0-stdext.jar >> ${TMPPLIST} > + @${ECHO} share/java/classes/jta-spec1_0_1.jar >> ${TMPPLIST} > +.if !defined(NOPORTDOCS) > @(cd ${PREFIX} \ > && find share/doc/mysql-jdbc -type f -print >> ${TMPPLIST}) > + @${ECHO} "@dirrm share/doc/mysql-jdbc" >> ${TMPPLIST} > .endif > + @${ECHO} "@unexec ${RMDIR} %D/share/java/classes 2>/dev/null || true" >> > ${TMPPLIST} + @${ECHO} "@unexec ${RMDIR} %D/share/java 2>/dev/null || true" > >> ${TMPPLIST} > > .include > diff -ru mysql-jdbc-mm.old/distinfo mysql-jdbc-mm/distinfo > --- mysql-jdbc-mm.old/distinfo Sat Apr 29 20:09:57 2000 > +++ mysql-jdbc-mm/distinfo Fri Nov 30 11:19:55 2001 > @@ -1 +1 @@ > -MD5 (mm.mysql.jdbc-1.2c.tar.gz) = b04aa7f3048c2ebb169ee88ce19a6a4c > +MD5 (mm.mysql-2.0.8-you-must-unjar-me.jar) = > b496f9ad5be7afb21d3f05902b2805a0 diff -ru > mysql-jdbc-mm.old/files/patch-Makefile mysql-jdbc-mm/files/patch-Makefile > --- mysql-jdbc-mm.old/files/patch-Makefile Fri Jun 1 06:49:08 2001 +++ > mysql-jdbc-mm/files/patch-Makefile Wed Dec 12 12:39:45 2001 > @@ -1,21 +0,0 @@ > ---- Makefile.orig Sun May 27 12:10:22 2001 > -+++ Makefile Sun May 27 12:16:18 2001 > -@@ -3,14 +3,16 @@ > - # $Id: Makefile,v 1.2 1998/08/25 04:02:25 mmatthew Exp $ > - # > - > --JAVAC = /usr/local/jdk118/bin/javac > -+JAVA_HOME = /usr/local/jdk1.1.8 > -+JAVAC = JAVA_HOME=$(JAVA_HOME) CLASSPATH= $(JAVA_HOME)/bin/javac > -+JAR = JAVA_HOME=$(JAVA_HOME) CLASSPATH= $(JAVA_HOME)/bin/jar > - JAVAC_FLAGS =-O -g > - > - all: > - $(JAVAC) $(JAVAC_FLAGS) org/gjt/mm/mysql/*.java > - > - jar: all > -- jar -cv0f mysql_uncomp.jar org/gjt/mm/mysql/*.class; jar -cvf > mysql_comp.jar org/gjt/mm/mysql/*.class -+ $(JAR) -cv0f mysql_uncomp.jar > org/gjt/mm/mysql/*.class; $(JAR) -cvf mysql_comp.jar > org/gjt/mm/mysql/*.class - > - clean: > - rm -f org/gjt/mm/mysql/*.class org/gjt/mm/mysql/*~ > diff -ru mysql-jdbc-mm.old/files/patch-build.xml > mysql-jdbc-mm/files/patch-build.xml --- > mysql-jdbc-mm.old/files/patch-build.xml Wed Dec 12 12:39:28 2001 +++ > mysql-jdbc-mm/files/patch-build.xml Fri Nov 30 14:29:35 2001 > @@ -0,0 +1,21 @@ > +--- build.xml.orig Fri Nov 30 11:00:04 2001 > ++++ build.xml Fri Nov 30 11:03:37 2001 > +@@ -1,7 +1,7 @@ > + > + > +- > +- > ++ > ++ > + > + > + > +@@ -51,7 +51,7 @@ > + > + > + executable="${javac.1.1}"> +- ++ + > + > + > diff -ru mysql-jdbc-mm.old/files/patch-j1c mysql-jdbc-mm/files/patch-j1c > --- mysql-jdbc-mm.old/files/patch-j1c Wed Dec 12 12:39:28 2001 > +++ mysql-jdbc-mm/files/patch-j1c Thu Nov 29 18:00:12 2001 > @@ -0,0 +1,10 @@ > +--- j1c.orig Thu Nov 29 16:26:08 2001 > ++++ j1c Thu Nov 29 16:26:36 2001 > +@@ -0,0 +1,7 @@ > ++#!/bin/sh > ++ > ++JAVAC_1=%%PREFIX%%/jdk1.1.8/bin/javac > ++ > ++unset JAVA_HOME LD_LIBRARY_PATH LD_PRELOAD CLASSPATH > ++ > ++exec "$JAVAC_1" "$@" > diff -ru mysql-jdbc-mm.old/pkg-plist mysql-jdbc-mm/pkg-plist > --- mysql-jdbc-mm.old/pkg-plist Sat Jan 29 16:23:06 2000 > +++ mysql-jdbc-mm/pkg-plist Thu Nov 29 18:00:12 2001 > @@ -1 +1 @@ > -share/java/classes/mysql_comp.jar > + > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-java" in the body of the message -- Ernst de Haan EuroNet Internet B.V. "Come to me all who are weary and burdened and I will give you rest" -- Jesus Christ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Thu Dec 13 0:51:11 2001 Delivered-To: freebsd-java@freebsd.org Received: from chen.org.nz (tnt1-81.quicksilver.net.nz [202.89.142.81]) by hub.freebsd.org (Postfix) with ESMTP id 1AFC237B417 for ; Thu, 13 Dec 2001 00:51:06 -0800 (PST) Received: (from jonc@localhost) by chen.org.nz (8.11.6/8.11.6) id fBD8qMG02139; Thu, 13 Dec 2001 21:52:22 +1300 (NZDT) (envelope-from jonc) Date: Thu, 13 Dec 2001 21:52:21 +1300 From: Jonathan Chen To: Mikhail Kruk Cc: java@FreeBSD.ORG Subject: Re: JBuilder 5 Message-ID: <20011213215221.B1849@grimoire.chen.org.nz> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meshko@cs.brandeis.edu on Thu, Dec 13, 2001 at 03:19:51AM -0500 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Dec 13, 2001 at 03:19:51AM -0500, Mikhail Kruk wrote: > Hi, > Following the yesterdays question I've decided to actually try to install > JBuilder 5 on FreeBSD and got some interesting problems with that... > I've gone through many painful moves to work around it's attempts to work > with built in linux jre 1.3.0 distribution (which came w/o green threads > for some reason); I've made it use native jdk1.3.1. But it refuses to read > zip archive! It just ignores it all together. If I unzip it it actually > starts the installer but it crashes almost immediately because, I think, I > tries to get locales from the zip file and doesn't find it. > Anyone knows what may be wrong with 1.3.1 and zip files? Actually I've > tried linux-jdk1.3.0 and got the same results... doesn't want to read from > the zip file. Here's what I've discovered so far: 1. "setenv LAX_DEBUG 1" will show debug output for per_install.bin 2. If you change per_install.bin shell script, you must make sure that the byte count of the file stays the same, otherwise it will not extract the zip file. 3. "./per_install.bin LAX_VM /usr/local/jdk1.3.1/bin/java" will force the installer to use the specified VM when running the installer. 4. the installer will attempt to write to "/lib", "/jre", will *still* fail even if it succeeds. I've given up. I don't really need JBuilder that much either. -- Jonathan Chen ----------------------------------------------------------------------- "One, with God, is always a majority, but many a martyr has been burned at the stake while the votes were being counted." -- Thomas B. Reed To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Thu Dec 13 1:51:49 2001 Delivered-To: freebsd-java@freebsd.org Received: from zaphod.euronet.nl (zaphod.euronet.nl [194.134.128.241]) by hub.freebsd.org (Postfix) with ESMTP id 0042A37B405 for ; Thu, 13 Dec 2001 01:51:45 -0800 (PST) Received: by zaphod.euronet.nl (8.11.6/8.11.6) id fBD9pfj37795; Thu, 13 Dec 2001 10:51:41 +0100 (CET) (envelope-from ernst) Message-Id: <200112130951.fBD9pfj37795@zaphod.euronet.nl> Content-Type: text/plain; charset="iso-8859-1" From: Ernst de Haan Organization: EuroNet Internet B.V. To: "Volker Sturm" , Subject: Re: J2EE and Forte? Date: Thu, 13 Dec 2001 10:51:41 +0100 X-Mailer: KMail [version 1.3] References: <000001c18357$709e9900$0100a8c0@volker> In-Reply-To: <000001c18357$709e9900$0100a8c0@volker> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Volker, Your mail is a bit unclear to me. Are you trying to install Forte on FreeBSD with J2EE support? The question "can i install the J2EE on FreeBSD?" doesn't really make sense to me. If you want a J2EE implementation, try Orion (www/orion). Ernst On Wednesday 12 December 2001 22:53, Volker Sturm wrote: > Hi, > I am using J2EE and Forte on Windows. On FreeBSD I installed the > linux-jdk1.3.1 and the native one. Forte failed to install cos I didnt > find the .class file (Seems the version distributed by sun has changed). > Maybe I just didnt find it, but: can i install the J2EE on FreeBSD? > > Regards, > Volker Sturm > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-java" in the body of the message -- Ernst de Haan EuroNet Internet B.V. "Come to me all who are weary and burdened and I will give you rest" -- Jesus Christ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Thu Dec 13 2:53:48 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id D088D37B419 for ; Thu, 13 Dec 2001 02:53:28 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16ETUU-000452-00; Thu, 13 Dec 2001 02:53:26 -0800 Date: Thu, 13 Dec 2001 02:53:26 -0800 To: Daniel Eischen Cc: Bill Huey , freebsd-java@FreeBSD.ORG Subject: pthreads bug fix revised Message-ID: <20011213105326.GA15665@gnuppy> References: <20011212074342.GB4677@gnuppy> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey, This is the same pthreads patch, but cleaned up a bit for developer use only. It has been simplified to deal with absolute time out values correctly in the Posix API, since I misinterpreted the solution to the problem the first place. Hopefully, a better or more correct patch will replace this soon from Dan. bill --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pthread_fix_absolute_timespec.diff" diff -ru libc_r.clean/uthread/pthread_private.h /usr/src/lib/libc_r/uthread/pthread_private.h --- libc_r.clean/uthread/pthread_private.h Sat Dec 8 19:12:35 2001 +++ /usr/src/lib/libc_r/uthread/pthread_private.h Thu Dec 13 02:20:33 2001 @@ -60,6 +60,10 @@ #include #include +#define EVENT_STATE_DEBUG + +#include + /* * Define machine dependent macros to get and set the stack pointer * from the supported contexts. Also define a macro to set the return @@ -162,12 +166,25 @@ /* * State change macro without scheduling queue change: */ +#ifdef EVENT_STATE_DEBUG + +#define PTHREAD_SET_STATE(thrd, newstate) do { \ + (thrd)->state = newstate; \ + (thrd)->fname = __FILE__; \ + (thrd)->lineno = __LINE__; \ + _debug_enqueue_state_event(thrd, newstate,__FILE__, __LINE__ ); \ +} while (0) + +#else + #define PTHREAD_SET_STATE(thrd, newstate) do { \ (thrd)->state = newstate; \ (thrd)->fname = __FILE__; \ (thrd)->lineno = __LINE__; \ } while (0) +#endif + /* * State change macro with scheduling queue change - This must be * called with preemption deferred (see thread_kern_sched_[un]defer). @@ -653,6 +670,15 @@ siginfo_t siginfo; }; +#ifdef EVENT_STATE_DEBUG +typedef struct eventStateStruct +{ + enum pthread_state state; + char *fname; + int lineno; +} eventStateStructType; +#endif + /* * Thread structure. */ @@ -871,8 +897,34 @@ struct pthread_cleanup *cleanup; char *fname; /* Ptr to source file name */ int lineno; /* Source line number. */ + + /* + * Record the remaining at suspend points so that waits can be + * properly resumed. --billh + */ + struct timespec previous_wakeup_time; + +#define STATE_LOG_SIZE 32 + +#ifdef EVENT_STATE_DEBUG + eventStateStructType state_log[STATE_LOG_SIZE]; +#endif + }; +#ifdef EVENT_STATE_DEBUG +static +void _debug_enqueue_state_event(pthread_t thread, enum pthread_state state, char *fname, int lineno) +{ + memmove(&thread->state_log[1], + &thread->state_log[0], + sizeof(eventStateStructType)*(STATE_LOG_SIZE -1)); + thread->state_log[0].state = state; + thread->state_log[0].fname = fname; + thread->state_log[0].lineno = lineno; +} +#endif + /* Spare thread stack. */ struct stack { SLIST_ENTRY(stack) qe; /* Queue entry for this stack. */ @@ -1253,7 +1305,9 @@ void _thread_kern_sched_state(enum pthread_state, char *fname, int lineno); void _thread_kern_sched_state_unlock(enum pthread_state state, spinlock_t *lock, char *fname, int lineno); +void _wrap_timespec(const struct timespec *tspec); void _thread_kern_set_timeout(const struct timespec *); +void _thread_kern_set_timeout_by_pthread_timespec(struct pthread *, const struct timespec *); void _thread_kern_sig_defer(void); void _thread_kern_sig_undefer(void); void _thread_sig_handler(int, siginfo_t *, ucontext_t *); @@ -1398,4 +1452,9 @@ #endif __END_DECLS +/* timespec math additions --billh */ +void _add_timespec3 (struct timespec *, const struct timespec *, const struct timespec *); +void _subtract_timespec3(struct timespec *, const struct timespec *, const struct timespec *); + #endif /* !_PTHREAD_PRIVATE_H */ + Only in /usr/src/lib/libc_r/uthread: pthread_private.h.orig diff -ru libc_r.clean/uthread/uthread_kern.c /usr/src/lib/libc_r/uthread/uthread_kern.c --- libc_r.clean/uthread/uthread_kern.c Sat Dec 8 19:12:35 2001 +++ /usr/src/lib/libc_r/uthread/uthread_kern.c Thu Dec 13 02:12:22 2001 @@ -386,6 +386,12 @@ /* Return zero file descriptors ready: */ pthread->data.poll_data->nfds = 0; /* fall through */ +#ifdef 0 + case PS_SUSPENDED: + PTHREAD_WAITQ_REMOVE(pthread); + pthread->suspended = SUSP_YES; + break; +#endif default: /* * Remove this thread from the waiting queue @@ -638,6 +644,10 @@ _thread_run->fname = fname; _thread_run->lineno = lineno; +#ifdef EVENT_STATE_DEBUG +_debug_enqueue_state_event(_thread_run, state, fname, lineno); +#endif + /* Schedule the next thread that is ready: */ _thread_kern_sched(NULL); } @@ -665,6 +675,10 @@ _thread_run->fname = fname; _thread_run->lineno = lineno; +#ifdef EVENT_STATE_DEBUG +_debug_enqueue_state_event(_thread_run, state, fname, lineno); +#endif + _SPINUNLOCK(lock); /* Schedule the next thread that is ready: */ @@ -997,14 +1011,49 @@ } } + +#define NSEC_UPPERLIMIT 1000000000 + +void _add_timespec3(struct timespec *a, const struct timespec *b, const struct timespec *c) +{ + a->tv_nsec = b->tv_nsec + c->tv_nsec; + a->tv_sec = b->tv_sec + c->tv_sec; + + /* carry the result into the "tv_sec" --billh */ + if (a->tv_nsec >= NSEC_UPPERLIMIT) { + a->tv_sec += 1; + a->tv_nsec -= NSEC_UPPERLIMIT; + } + +} + +void _subtract_timespec3(struct timespec *a, const struct timespec *b, const struct timespec *c) +{ + a->tv_nsec = b->tv_nsec - c->tv_nsec; + a->tv_sec = b->tv_sec - c->tv_sec; + + /* borrow from "tv_sec". --billh */ + if (a->tv_nsec < 0) { + a->tv_sec -= 1; + a->tv_nsec += NSEC_UPPERLIMIT; + } + +} + void _thread_kern_set_timeout(const struct timespec * timeout) { + _thread_kern_set_timeout_by_pthread_timespec(_thread_run, timeout); +} + +void +_thread_kern_set_timeout_by_pthread_timespec(struct pthread *thread, const struct timespec *timeout) +{ struct timespec current_time; struct timeval tv; /* Reset the timeout flag for the running thread: */ - _thread_run->timeout = 0; + thread->timeout = 0; /* Check if the thread is to wait forever: */ if (timeout == NULL) { @@ -1012,29 +1061,35 @@ * Set the wakeup time to something that can be recognised as * different to an actual time of day: */ - _thread_run->wakeup_time.tv_sec = -1; - _thread_run->wakeup_time.tv_nsec = -1; + thread->wakeup_time.tv_sec = -1; + thread->wakeup_time.tv_nsec = -1; + + thread->previous_wakeup_time.tv_sec = -1; + thread->previous_wakeup_time.tv_nsec = -1; } /* Check if no waiting is required: */ else if (timeout->tv_sec == 0 && timeout->tv_nsec == 0) { /* Set the wake up time to 'immediately': */ - _thread_run->wakeup_time.tv_sec = 0; - _thread_run->wakeup_time.tv_nsec = 0; + thread->wakeup_time.tv_sec = 0; + thread->wakeup_time.tv_nsec = 0; + + thread->previous_wakeup_time.tv_sec = 0; + thread->previous_wakeup_time.tv_nsec = 0; } else { /* Get the current time: */ GET_CURRENT_TOD(tv); TIMEVAL_TO_TIMESPEC(&tv, ¤t_time); /* Calculate the time for the current thread to wake up: */ - _thread_run->wakeup_time.tv_sec = current_time.tv_sec + timeout->tv_sec; - _thread_run->wakeup_time.tv_nsec = current_time.tv_nsec + timeout->tv_nsec; + _add_timespec3(&thread->wakeup_time, ¤t_time, timeout); - /* Check if the nanosecond field needs to wrap: */ - if (_thread_run->wakeup_time.tv_nsec >= 1000000000) { - /* Wrap the nanosecond field: */ - _thread_run->wakeup_time.tv_sec += 1; - _thread_run->wakeup_time.tv_nsec -= 1000000000; - } + /* Set the timeout length of this wake up operation so that it can be + * properly recalculated after being suspended and put at the tail of the + * waiting queue. --billh + */ + + thread->previous_wakeup_time.tv_sec = timeout->tv_sec; + thread->previous_wakeup_time.tv_nsec = timeout->tv_nsec; } } Only in /usr/src/lib/libc_r/uthread: uthread_kern.c.orig diff -ru libc_r.clean/uthread/uthread_resume_np.c /usr/src/lib/libc_r/uthread/uthread_resume_np.c --- libc_r.clean/uthread/uthread_resume_np.c Sat Dec 8 19:12:35 2001 +++ /usr/src/lib/libc_r/uthread/uthread_resume_np.c Thu Dec 13 02:10:24 2001 @@ -36,6 +36,8 @@ #include #include "pthread_private.h" +void _pthread_resume_by_pthread_common(pthread_t, enum pthread_susp ); + /* Resume a thread: */ int pthread_resume_np(pthread_t thread) @@ -49,48 +51,67 @@ old_suspended = thread->suspended; thread->suspended = SUSP_NO; - /* Is it currently suspended? */ - if (thread->state == PS_SUSPENDED) { - /* - * Defer signals to protect the scheduling queues - * from access by the signal handler: - */ - _thread_kern_sig_defer(); - - switch (old_suspended) { - case SUSP_MUTEX_WAIT: - /* Set the thread's state back. */ - PTHREAD_SET_STATE(thread,PS_MUTEX_WAIT); - break; - case SUSP_COND_WAIT: - /* Set the thread's state back. */ - PTHREAD_SET_STATE(thread,PS_COND_WAIT); - break; - case SUSP_JOIN: - /* Set the thread's state back. */ - PTHREAD_SET_STATE(thread,PS_JOIN); - break; - case SUSP_NOWAIT: - /* Allow the thread to run. */ - PTHREAD_SET_STATE(thread,PS_RUNNING); - PTHREAD_WAITQ_REMOVE(thread); - PTHREAD_PRIOQ_INSERT_TAIL(thread); - break; - case SUSP_NO: - case SUSP_YES: - /* Allow the thread to run. */ - PTHREAD_SET_STATE(thread,PS_RUNNING); - PTHREAD_PRIOQ_INSERT_TAIL(thread); - break; - } - - /* - * Undefer and handle pending signals, yielding if - * necessary: - */ - _thread_kern_sig_undefer(); - } + _pthread_resume_by_pthread_common(thread, old_suspended); } +fprintf(stderr, "pthread_resume_np END\n"); return(ret); } + +void _pthread_resume_by_pthread_common(pthread_t thread, enum pthread_susp old_suspended) +{ + /* Is it currently suspended? */ + if (thread->state == PS_SUSPENDED) { + /* + * Defer signals to protect the scheduling queues + * from access by the signal handler: + */ + _thread_kern_sig_defer(); + + switch (old_suspended) { + case SUSP_MUTEX_WAIT: + /* Set the thread's state back. */ + PTHREAD_SET_STATE(thread,PS_MUTEX_WAIT); + break; + case SUSP_COND_WAIT: + /* For cases where it was doing a pthread_cond_timedwait() + * restor the previous suspend time. + * --billh + */ + thread->wakeup_time.tv_sec = thread->previous_wakeup_time.tv_sec; + thread->wakeup_time.tv_nsec = thread->previous_wakeup_time.tv_nsec; + thread->previous_wakeup_time.tv_sec = -1; + thread->previous_wakeup_time.tv_nsec = -1; + + thread->suspended = SUSP_NO; + + /* Set the thread's state back. */ + PTHREAD_SET_STATE(thread,PS_COND_WAIT); + break; + case SUSP_JOIN: + /* Set the thread's state back. */ + PTHREAD_SET_STATE(thread,PS_JOIN); + break; + case SUSP_NOWAIT: + /* Allow the thread to run. */ + PTHREAD_SET_STATE(thread,PS_RUNNING); + PTHREAD_WAITQ_REMOVE(thread); + PTHREAD_PRIOQ_INSERT_TAIL(thread); + break; + case SUSP_NO: + case SUSP_YES: + /* Allow the thread to run. */ + PTHREAD_SET_STATE(thread,PS_RUNNING); + PTHREAD_PRIOQ_INSERT_TAIL(thread); + break; + } + + /* + * Undefer and handle pending signals, yielding if + * necessary: + */ + _thread_kern_sig_undefer(); + } +} + #endif + Only in /usr/src/lib/libc_r/uthread: uthread_resume_np.c.orig diff -ru libc_r.clean/uthread/uthread_suspend_np.c /usr/src/lib/libc_r/uthread/uthread_suspend_np.c --- libc_r.clean/uthread/uthread_suspend_np.c Sat Dec 8 19:12:35 2001 +++ /usr/src/lib/libc_r/uthread/uthread_suspend_np.c Thu Dec 13 02:10:04 2001 @@ -38,6 +38,8 @@ static void finish_suspension(void *arg); +void _pthread_suspend_np_by_pthread_common(pthread_t thread); + /* Suspend a thread: */ int pthread_suspend_np(pthread_t thread) @@ -52,92 +54,7 @@ */ _thread_kern_sig_defer(); - switch (thread->state) { - case PS_RUNNING: - /* - * Remove the thread from the priority queue and - * set the state to suspended: - */ - PTHREAD_PRIOQ_REMOVE(thread); - PTHREAD_SET_STATE(thread, PS_SUSPENDED); - break; - - case PS_SPINBLOCK: - case PS_FDR_WAIT: - case PS_FDW_WAIT: - case PS_POLL_WAIT: - case PS_SELECT_WAIT: - /* - * Remove these threads from the work queue - * and mark the operation as interrupted: - */ - if ((thread->flags & PTHREAD_FLAGS_IN_WORKQ) != 0) - PTHREAD_WORKQ_REMOVE(thread); - _thread_seterrno(thread,EINTR); - - /* FALLTHROUGH */ - case PS_SLEEP_WAIT: - thread->interrupted = 1; - - /* FALLTHROUGH */ - case PS_SIGTHREAD: - case PS_WAIT_WAIT: - case PS_SIGSUSPEND: - case PS_SIGWAIT: - /* - * Remove these threads from the waiting queue and - * set their state to suspended: - */ - PTHREAD_WAITQ_REMOVE(thread); - PTHREAD_SET_STATE(thread, PS_SUSPENDED); - break; - - case PS_MUTEX_WAIT: - /* Mark the thread as suspended and still in a queue. */ - thread->suspended = SUSP_MUTEX_WAIT; - - PTHREAD_SET_STATE(thread, PS_SUSPENDED); - break; - case PS_COND_WAIT: - /* Mark the thread as suspended and still in a queue. */ - thread->suspended = SUSP_COND_WAIT; - - PTHREAD_SET_STATE(thread, PS_SUSPENDED); - break; - case PS_JOIN: - /* Mark the thread as suspended and joining: */ - thread->suspended = SUSP_JOIN; - - PTHREAD_NEW_STATE(thread, PS_SUSPENDED); - break; - case PS_FDLR_WAIT: - case PS_FDLW_WAIT: - case PS_FILE_WAIT: - /* Mark the thread as suspended: */ - thread->suspended = SUSP_YES; - - /* - * Threads in these states may be in queues. - * In order to preserve queue integrity, the - * cancelled thread must remove itself from the - * queue. Mark the thread as interrupted and - * set the state to running. When the thread - * resumes, it will remove itself from the queue - * and call the suspension completion routine. - */ - thread->interrupted = 1; - _thread_seterrno(thread, EINTR); - PTHREAD_NEW_STATE(thread, PS_RUNNING); - thread->continuation = finish_suspension; - break; - - case PS_DEAD: - case PS_DEADLOCK: - case PS_STATE_MAX: - case PS_SUSPENDED: - /* Nothing needs to be done: */ - break; - } + _pthread_suspend_np_by_pthread_common(thread); /* * Undefer and handle pending signals, yielding if @@ -145,7 +62,104 @@ */ _thread_kern_sig_undefer(); } +fprintf(stderr, "pthread_suspend_np END\n"); return(ret); +} + + +void _pthread_suspend_np_by_pthread_common(pthread_t thread) +{ + switch (thread->state) { + case PS_RUNNING: + /* + * Remove the thread from the priority queue and + * set the state to suspended: + */ + PTHREAD_PRIOQ_REMOVE(thread); + PTHREAD_SET_STATE(thread, PS_SUSPENDED); + break; + + case PS_SPINBLOCK: + case PS_FDR_WAIT: + case PS_FDW_WAIT: + case PS_POLL_WAIT: + case PS_SELECT_WAIT: + /* + * Remove these threads from the work queue + * and mark the operation as interrupted: + */ + if ((thread->flags & PTHREAD_FLAGS_IN_WORKQ) != 0) + PTHREAD_WORKQ_REMOVE(thread); + _thread_seterrno(thread,EINTR); + + /* FALLTHROUGH */ + case PS_SLEEP_WAIT: + thread->interrupted = 1; + + /* FALLTHROUGH */ + case PS_SIGTHREAD: + case PS_WAIT_WAIT: + case PS_SIGSUSPEND: + case PS_SIGWAIT: + /* + * Remove these threads from the waiting queue and + * set their state to suspended: + */ + PTHREAD_WAITQ_REMOVE(thread); + PTHREAD_SET_STATE(thread, PS_SUSPENDED); + break; + + case PS_MUTEX_WAIT: + /* Mark the thread as suspended and still in a queue. */ + thread->suspended = SUSP_MUTEX_WAIT; + + PTHREAD_SET_STATE(thread, PS_SUSPENDED); + break; + case PS_COND_WAIT: + thread->previous_wakeup_time.tv_nsec = thread->wakeup_time.tv_nsec; + thread->previous_wakeup_time.tv_sec = thread->wakeup_time.tv_sec; + + thread->wakeup_time.tv_nsec = -1; + thread->wakeup_time.tv_sec = -1; + + /* Mark the thread as suspended and still in a queue. */ + thread->suspended = SUSP_COND_WAIT; + PTHREAD_NEW_STATE(thread, PS_SUSPENDED); + break; + case PS_JOIN: + /* Mark the thread as suspended and joining: */ + thread->suspended = SUSP_JOIN; + + PTHREAD_NEW_STATE(thread, PS_SUSPENDED); + break; + case PS_FDLR_WAIT: + case PS_FDLW_WAIT: + case PS_FILE_WAIT: + /* Mark the thread as suspended: */ + thread->suspended = SUSP_YES; + + /* + * Threads in these states may be in queues. + * In order to preserve queue integrity, the + * cancelled thread must remove itself from the + * queue. Mark the thread as interrupted and + * set the state to running. When the thread + * resumes, it will remove itself from the queue + * and call the suspension completion routine. + */ + thread->interrupted = 1; + _thread_seterrno(thread, EINTR); + PTHREAD_NEW_STATE(thread, PS_RUNNING); + thread->continuation = finish_suspension; + break; + + case PS_DEAD: + case PS_DEADLOCK: + case PS_STATE_MAX: + case PS_SUSPENDED: + /* Nothing needs to be done: */ + break; + } } static void Only in /usr/src/lib/libc_r/uthread: uthread_suspend_np.c.orig --IJpNTDwzlM2Ie8A6-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Thu Dec 13 6:10:14 2001 Delivered-To: freebsd-java@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id CDAAE37B41B for ; Thu, 13 Dec 2001 06:10:04 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id fBDE5bBx024639; Thu, 13 Dec 2001 09:05:37 -0500 (EST) Date: Thu, 13 Dec 2001 09:05:37 -0500 (EST) From: Daniel Eischen To: Bill Huey Cc: Bill Huey , freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] In-Reply-To: <20011213063207.GA7359@gnuppy> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 12 Dec 2001, Bill Huey wrote: > On Wed, Dec 12, 2001 at 07:24:12AM -0500, Daniel Eischen wrote: > > > > diff -u -r1.38 uthread_kern.c > > > > --- uthread_kern.c 4 May 2001 20:37:07 -0000 1.38 > > > > +++ uthread_kern.c 12 Dec 2001 04:15:35 -0000 > > > > @@ -387,6 +387,10 @@ > > > > ((pthread->wakeup_time.tv_sec == ts.tv_sec) && > > > > (pthread->wakeup_time.tv_nsec <= ts.tv_nsec)))) { > > > > switch (pthread->state) { > > > > + case PS_SUSPENDED: > > > > + PTHREAD_WAITQ_REMOVE(pthread); > > > > + pthread->suspended = SUSP_YES; > > > > + break; > > > > case PS_POLL_WAIT: > > > > case PS_SELECT_WAIT: > > > > /* Return zero file descriptors ready: */ > > > > Dan Eischen > > > > Yes, this should keep the state equal to PS_SUSPENDED. When the thread > > is resumed, its state should be set to PS_RUNNING and then it will be > > added back to the run queue. > > This didn't work. A thread would SEGV and then the entire thing blows up > shortly afterward in a wierd kind of delayed signal delivery way. Well, the intent of the patch is correct. The patch that you posted (subsequent to this email) is much more than is necessary. There should be no need to keep previous timeout times... And in general, keeping previous anythings doesn't work due to signal semantics. Threads are allowed to longjmp out of signal handlers which can bypass anything the scheduler wanted to do in regards to restoring "previous" values. If a thread timesout, you want to prevent it from being added to the run queue if it is suspended. As long as a thread is not in the run queue, it will not run. If a suspended thread is running before it is resumed, then the timeout loop (my patch attempts to correct it) is the place to look. I am running with my patch without any problems, and I have passed all my regression tests. I don't have anything that tests suspend and resume, though. Do you have a simple C program that demonstrates the problem? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Thu Dec 13 8:29:12 2001 Delivered-To: freebsd-java@freebsd.org Received: from web10406.mail.yahoo.com (web10406.mail.yahoo.com [216.136.130.98]) by hub.freebsd.org (Postfix) with SMTP id 4E90F37B41D for ; Thu, 13 Dec 2001 08:28:54 -0800 (PST) Message-ID: <20011213162854.42519.qmail@web10406.mail.yahoo.com> Received: from [64.90.179.71] by web10406.mail.yahoo.com via HTTP; Thu, 13 Dec 2001 08:28:54 PST Date: Thu, 13 Dec 2001 08:28:54 -0800 (PST) From: Dylan Carlson Reply-To: absinthe@pobox.com Subject: bus error on jdk1.3.1p5 native threads / tomcat 3.2.3 To: freebsd-java@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, Should I post java bug reports to GNATS or to this list? Anyway, here's a bug report for you. Running FreeBSD 4.4, native-thread build of 1.3.1 patchset 5, trying to start Tomcat 3.2.3 under it. Wondering if you have any ideas. We get the following errors: ~~~~~~~~~~ Starting tomcat. Check logs/tomcat.log for error messages SIGBUS 10* bus error Full thread dump Classic VM (1.3.1-internal-root-011212-15:00, native threads): "Thread-23" (TID:0x28e9d998, sys_thread_t:0x8063280, state:CW, native ID:0x8 04f000) prio=5 "Thread-22" (TID:0x28e9d9d8, sys_thread_t:0x837bb80, state:CW, native ID:0x8 392c00) prio=5 at java.lang.Object.wait(Native Method) at org.apache.tomcat.util.ThreadPool$MonitorRunnable.run(ThreadPool.java :393) at java.lang.Thread.run(Thread.java:484) "Thread-21" (TID:0x28e9dc38, sys_thread_t:0x837ba80, state:R, native ID:0x83 92800) prio=5 at java.net.InetAddressImpl.getHostByAddr(Native Method) at java.net.InetAddress.getHostName(InetAddress.java:156) at java.net.InetAddress.getHostName(InetAddress.java:127) at java.net.InetAddress.toString(InetAddress.java:265) at java.lang.String.valueOf(String.java:1947) at java.lang.StringBuffer.append(StringBuffer.java:370) at java.net.ServerSocket.toString(ServerSocket.java:316) at java.text.MessageFormat.format(MessageFormat.java:756) at java.text.MessageFormat.format(MessageFormat.java:491) at java.text.Format.format(Format.java:121) at java.text.MessageFormat.format(MessageFormat.java:476) at org.apache.tomcat.util.StringManager.getString(StringManager.java:171 ) at org.apache.tomcat.util.StringManager.getString(StringManager.java:209 ) at org.apache.tomcat.service.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoin t.java:317) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java: 402) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :501) at java.lang.Thread.run(Thread.java:484) "Thread-20" (TID:0x28e9dbe8, sys_thread_t:0x837b980, state:CW, native ID:0x8 392400) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "Thread-19" (TID:0x28e9db98, sys_thread_t:0x837b880, state:CW, native ID:0x8 385c00) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "Thread-18" (TID:0x28e9db08, sys_thread_t:0x837b780, state:CW, native ID:0x8 385800) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "Thread-17" (TID:0x28e9dda0, sys_thread_t:0x837b680, state:CW, native ID:0x8 385400) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "Thread-16" (TID:0x28e9dd50, sys_thread_t:0x837b580, state:CW, native ID:0x8 385000) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "Thread-15" (TID:0x28e9dd00, sys_thread_t:0x837b480, state:CW, native ID:0x8 383c00) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "Thread-14" (TID:0x28e9dcb0, sys_thread_t:0x837b380, state:CW, native ID:0x8 383800) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "Thread-13" (TID:0x28e9df20, sys_thread_t:0x837b280, state:CW, native ID:0x8 383400) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "Thread-12" (TID:0x28e9ded0, sys_thread_t:0x837b180, state:CW, native ID:0x8 37d000) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "Thread-11" (TID:0x28e9e790, sys_thread_t:0x837b080, state:CW, native ID:0x8 376c00) prio=5 at java.lang.Object.wait(Native Method) at org.apache.tomcat.util.ThreadPool$MonitorRunnable.run(ThreadPool.java :393) at java.lang.Thread.run(Thread.java:484) "Thread-10" (TID:0x28e9ece8, sys_thread_t:0x8355f80, state:CW, native ID:0x8 376800) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "Thread-9" (TID:0x28e9eba8, sys_thread_t:0x8355e80, state:R, native ID:0x837 6400) prio=5 at java.net.InetAddressImpl.getHostByAddr(Native Method) at java.net.InetAddress.getHostName(InetAddress.java:156) at java.net.InetAddress.getHostName(InetAddress.java:127) at java.net.InetAddress.toString(InetAddress.java:265) at java.lang.String.valueOf(String.java:1947) at java.lang.StringBuffer.append(StringBuffer.java:370) at java.net.ServerSocket.toString(ServerSocket.java:316) at java.text.MessageFormat.format(MessageFormat.java:756) at java.text.MessageFormat.format(MessageFormat.java:491) at java.text.Format.format(Format.java:121) at java.text.MessageFormat.format(MessageFormat.java:476) at org.apache.tomcat.util.StringManager.getString(StringManager.java:171 ) at org.apache.tomcat.util.StringManager.getString(StringManager.java:209 ) at org.apache.tomcat.service.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoin t.java:317) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java: 402) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :501) at java.lang.Thread.run(Thread.java:484) "Thread-8" (TID:0x28e9eb58, sys_thread_t:0x8355d80, state:CW, native ID:0x83 76000) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "Thread-7" (TID:0x28e9efb8, sys_thread_t:0x8355c80, state:CW, native ID:0x83 71c00) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "Thread-6" (TID:0x28e9ef68, sys_thread_t:0x8355b80, state:CW, native ID:0x83 71800) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "Thread-5" (TID:0x28e9ee00, sys_thread_t:0x8355a80, state:CW, native ID:0x83 71400) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "Thread-4" (TID:0x28e9ee80, sys_thread_t:0x8355980, state:CW, native ID:0x83 71000) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "Thread-3" (TID:0x28e6bff8, sys_thread_t:0x8355880, state:CW, native ID:0x83 65c00) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "Thread-2" (TID:0x28e9f2a0, sys_thread_t:0x8355780, state:CW, native ID:0x83 65000) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "Thread-1" (TID:0x28e9f1d8, sys_thread_t:0x8355680, state:CW, native ID:0x83 5c800) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :480) at java.lang.Thread.run(Thread.java:484) "StandardManager" (TID:0x28e94b00, sys_thread_t:0x8355380, state:CW, native ID:0x8358800) prio=5 at java.lang.Thread.sleep(Native Method) at org.apache.tomcat.session.StandardManager.threadSleep(StandardManager .java:495) at org.apache.tomcat.session.StandardManager.run(StandardManager.java:55 2) ... [the StandardManager block repeats several times] __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Thu Dec 13 15:20:35 2001 Delivered-To: freebsd-java@freebsd.org Received: from db.nexgen.com (db.nexgen.com [66.92.98.149]) by hub.freebsd.org (Postfix) with SMTP id 78C0137B405 for ; Thu, 13 Dec 2001 15:20:30 -0800 (PST) Received: (qmail 31934 invoked from network); 13 Dec 2001 23:19:49 -0000 Received: from localhost.nexgen.com (HELO alexus) (127.0.0.1) by localhost.nexgen.com with SMTP; 13 Dec 2001 23:19:49 -0000 Message-ID: <000901c1842c$c11faab0$0d00a8c0@alexus> From: "alexus" To: Subject: jakarta ant 1.4 Date: Thu, 13 Dec 2001 18:20:03 -0500 Organization: NexGen MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org when I build ANT itself it builds fine.. when i do build install it fails.. any ideas? su-2.05# cd $ANT_HOME su-2.05# sh build.sh expr: syntax error Buildfile: build.xml main: prepare: check_for_optional_packages: build: Copying 2 files to /usr/local/java/jakarta-ant-1.4/build/classes jars: Building jar: /usr/local/java/jakarta-ant-1.4/build/lib/ant.jar dist-lite: Copying 1 file to /usr/local/java/jakarta-ant-1.4/dist/lib BUILD SUCCESSFUL Total time: 3 seconds su-2.05# sh build.sh install expr: syntax error Buildfile: build.xml install: prepare: check_for_optional_packages: build: Copying 2 files to /usr/local/java/jakarta-ant-1.4/build/classes jars: Building jar: /usr/local/java/jakarta-ant-1.4/build/lib/ant.jar dist-lite: Copying 1 file to /usr/local/java/jakarta-ant/lib Result: -1 javadoc_check: javadocs: dist_javadocs: Copying 530 files to /usr/local/java/jakarta-ant/docs/manual/api BUILD FAILED java.lang.IllegalMonitorStateException at java.lang.ref.Finalizer.add(Finalizer.java:45) at java.lang.ref.Finalizer.(Finalizer.java:70) at java.lang.ref.Finalizer.register(Finalizer.java:75) at org.apache.tools.ant.util.FileUtils.copyFile(FileUtils.java:225) at org.apache.tools.ant.util.FileUtils.copyFile(FileUtils.java:140) at org.apache.tools.ant.taskdefs.Copy.doFileOperations(Copy.java:375) at org.apache.tools.ant.taskdefs.Copy.execute(Copy.java:254) at org.apache.tools.ant.Task.perform(Task.java:217) at org.apache.tools.ant.Target.execute(Target.java:164) at org.apache.tools.ant.Target.performTasks(Target.java:182) at org.apache.tools.ant.Project.executeTarget(Project.java:601) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:256) at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:120) at org.apache.tools.ant.Task.perform(Task.java:217) at org.apache.tools.ant.Target.execute(Target.java:164) at org.apache.tools.ant.Target.performTasks(Target.java:182) at org.apache.tools.ant.Project.executeTarget(Project.java:601) at org.apache.tools.ant.Project.executeTargets(Project.java:560) at org.apache.tools.ant.Main.runBuild(Main.java:454) at org.apache.tools.ant.Main.start(Main.java:153) at org.apache.tools.ant.Main.main(Main.java:176) Total time: 6 seconds su-2.05# To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Thu Dec 13 18:57:42 2001 Delivered-To: freebsd-java@freebsd.org Received: from service.sh.cvut.cz (service.sh.cvut.cz [147.32.127.214]) by hub.freebsd.org (Postfix) with ESMTP id 4154E37B405 for ; Thu, 13 Dec 2001 18:57:37 -0800 (PST) Received: from Heptium.sh.cvut.cz (heptium.sh.cvut.cz [147.32.127.194]) by service.sh.cvut.cz (Postfix) with ESMTP id 57FC11E65D for ; Fri, 14 Dec 2001 03:57:36 +0100 (CET) Received: from sh.cvut.cz (viking.sh.cvut.cz [147.32.124.181]) by Heptium.sh.cvut.cz (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id DAA25846 for ; Fri, 14 Dec 2001 03:57:36 +0100 X-Authentication-Warning: Heptium.sh.cvut.cz: Host viking.sh.cvut.cz [147.32.124.181] claimed to be sh.cvut.cz Message-ID: <3C196A9F.E0EB8163@sh.cvut.cz> Date: Fri, 14 Dec 2001 03:57:35 +0100 From: "Arcadius A." Organization: CTU X-Mailer: Mozilla 4.77 [en] (X11; U; FreeBSD 4.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-java@freebsd.org Subject: JDK13 BUG ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello ! I'm having serious troubles with the JDK13 and the patch5 I'm doing this on FreeBSD4.4 RELEASE. I think there is a bug .... something like : " java.util.MissingResourceException: Can't find bundle for base name com.sun.tools.javah.resources.FreeBSD_i386, locale en_US " ... Error loading resources. Please file a bug report. " The whole output of the built is : viking# pwd /usr/ports/java/jdk13 viking# which java java: Command not found. viking# make build ===> Building for jdk-1.3.1p5 i386 Build started: 1.3.1-internal-arcad-011214-03:37 Sanity check passed >>>Recursively making java all @ Fri Dec 14 03:37:15 CET 2001 ... gmake[1]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java' >>>Recursively making hpi all @ Fri Dec 14 03:37:15 CET 2001 ... gmake[2]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi' >>>Recursively making green all @ Fri Dec 14 03:37:15 CET 2001 ... gmake[3]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake ../../../../build/bsd-i386/lib/i386/green_threads/libhpi.so VARIANT=OPT gmake[4]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake[4]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake ../../../../build/bsd-i386/lib/i386/green_threads/libhpi_g.so VARIANT=DBG gmake[4]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake[4]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake[3]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' <<>>Recursively making version all @ Fri Dec 14 03:37:16 CET 2001 ... gmake[2]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/version' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/version' <<>>Recursively making jvm all @ Fri Dec 14 03:37:16 CET 2001 ... gmake[2]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' gmake ../../../build/bsd-i386/lib/i386/classic/libjvm.so VARIANT=OPT gmake[3]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' rm -f ../../../build/bsd-i386/tmp/java/java.lang/jvm/.classes.list if [ -s ../../../build/bsd-i386/tmp/java/java.lang/jvm/.classes.list ] ; \ then /usr/local/linux-jdk1.3.1/bin/javac -J-Xmx64m -classpath ../../../build/bsd-i386/classes -bootclasspath "" -sourcepath "../../../build/bsd-i386/gensrc:../../../src/solaris/classes:../../../src/share/classes" -d ../../../build/bsd-i386/classes \ ; \ fi /usr/local/linux-jdk1.3.1/bin/javah -old -bootclasspath ../../../build/bsd-i386/classes -d ../../../build/bsd-i386/tmp/java/java.lang/jvm/CClassHeaders/ \ java.io.InputStream java.lang.Boolean java.lang.Byte java.lang.Character java.lang.Class java.lang.ClassLoader java.lang.Double java.lang.Float java.lang.Integer java.lang.Long java.lang.Object java.lang.Runtime java.lang.Short java.lang.StackOverflowError java.lang.String java.lang.Thread java.lang.ThreadGroup java.lang.Throwable java.lang.ref.Reference java.lang.ref.SoftReference java.lang.reflect.Field java.lang.reflect.Method java.lang.reflect.Constructor java.lang.reflect.InvocationTargetException java.security.AccessControlContext java.util.Properties sun.io.ByteToCharConverter sun.io.CharToByteConverter sun.misc.VM java.util.MissingResourceException: Can't find bundle for base name com.sun.tools.javah.resources.FreeBSD_i386, locale en_US at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:712) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:683) at java.util.ResourceBundle.getBundle(ResourceBundle.java:546) at com.sun.tools.javah.Util.initPlatform(Util.java:159) at com.sun.tools.javah.Util.getPlatformString(Util.java:144) at com.sun.tools.javah.OldHeaders.write(OldHeaders.java:92) at com.sun.tools.javah.Gen.run(Gen.java:152) at com.sun.tools.javah.Main.run(Main.java:176) at com.sun.tools.javah.Main.main(Main.java:45) Error loading resources. Please file a bug report. gmake[3]: *** [../../../build/bsd-i386/tmp/java/java.lang/jvm/obj/.class.headers.i386] Error 10 gmake[3]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' gmake[2]: *** [optimized] Error 2 gmake[2]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' gmake[1]: *** [all] Error 1 gmake[1]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java' gmake: *** [all] Error 1 *** Error code 2 Stop in /usr/ports/java/jdk13. *** Error code 1 Stop in /usr/ports/java/jdk13. *** Error code 1 Stop in /usr/ports/java/jdk13. viking# thanks ... Arcadius Ahouansou To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Thu Dec 13 19:43:33 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id 8BF9237B417 for ; Thu, 13 Dec 2001 19:43:30 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16EjFu-00013y-00; Thu, 13 Dec 2001 19:43:26 -0800 Date: Thu, 13 Dec 2001 19:43:26 -0800 To: Daniel Eischen Cc: Bill Huey , freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] Message-ID: <20011214034326.GA4018@gnuppy> References: <20011213063207.GA7359@gnuppy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Dec 13, 2001 at 09:05:37AM -0500, Daniel Eischen wrote: > Well, the intent of the patch is correct. The patch that you > posted (subsequent to this email) is much more than is necessary. > There should be no need to keep previous timeout times... > And in general, keeping previous anythings doesn't work due to > signal semantics. Threads are allowed to longjmp out of signal > handlers which can bypass anything the scheduler wanted to do > in regards to restoring "previous" values. I'll need to review this to get an idea of what you're talking about. > If a thread timesout, you want to prevent it from being added > to the run queue if it is suspended. As long as a thread is > not in the run queue, it will not run. If a suspended thread > is running before it is resumed, then the timeout loop (my > patch attempts to correct it) is the place to look. One of the shot in the dark reason why I still kept thread in the waiting queue and marked the timeout value as -1, is that some operation dealing with mutexes failed on an assert when it could not find the thread to remove in the waiting queue. I'm not sure where the logic for that is just yet and how to solve that problem. > I am running with my patch without any problems, and I have > passed all my regression tests. I don't have anything that > tests suspend and resume, though. Do you have a simple C > program that demonstrates the problem? Other than the JVM itself, no. I would expect that the regression tests would pass since it only triggers in cases where it deals with suspend and resume states, but trying to get a small test program to trigger what I'm running into is going to be difficult. The threads that seem to give me the problems are condition variable related. I'm not sure what to say other than that. bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Fri Dec 14 0:25:53 2001 Delivered-To: freebsd-java@freebsd.org Received: from alcatraz.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by hub.freebsd.org (Postfix) with ESMTP id 21C5337B405 for ; Fri, 14 Dec 2001 00:25:40 -0800 (PST) Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by alcatraz.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id KAA10039; Fri, 14 Dec 2001 10:25:37 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from vega.vega.com (h19.227.dialup.iptcom.net [212.9.227.19]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id KAA81454; Fri, 14 Dec 2001 10:25:33 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.6/8.11.3) with ESMTP id fBE8P2F31880; Fri, 14 Dec 2001 10:25:02 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3C19B818.BA3FBC05@FreeBSD.org> Date: Fri, 14 Dec 2001 10:28:08 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: java@FreeBSD.org Cc: "Arcadius A." Subject: [Fwd: JDK13 BUG] Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Does anybody have any ideas? -Maxim -------- Original Message -------- Subject: JDK13 BUG Date: Fri, 14 Dec 2001 03:27:45 +0100 From: "Arcadius A." Organization: CTU To: sobomax@FreeBSD.ORG Hello ! I've just updated all my port collection , then try to install the FreeBSD JDK13 I'm using FreeBSD 4.4 release ... Of course , I got all the necessary files from the net .... I think there is a bug in the port :" java.util.MissingResourceException: Can't find bundle for base name com.sun.tools.javah.resources.FreeBSD_i386, locale en_US " here is the output message when I try to build the port : viking# pwd /usr/ports/java/jdk13 viking# which java java: Command not found. viking# make build ===> Building for jdk-1.3.1p5 i386 Build started: 1.3.1-internal-arcad-011214-02:58 Sanity check passed >>>Recursively making java all @ Fri Dec 14 02:58:44 CET 2001 ... gmake[1]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java' >>>Recursively making hpi all @ Fri Dec 14 02:58:44 CET 2001 ... gmake[2]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi' >>>Recursively making green all @ Fri Dec 14 02:58:44 CET 2001 ... gmake[3]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake ../../../../build/bsd-i386/lib/i386/green_threads/libhpi.so VARIANT=OPT gmake[4]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake[4]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake ../../../../build/bsd-i386/lib/i386/green_threads/libhpi_g.so VARIANT=DBG gmake[4]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake[4]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake[3]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' <<>>Recursively making version all @ Fri Dec 14 02:58:45 CET 2001 ... gmake[2]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/version' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/version' <<>>Recursively making jvm all @ Fri Dec 14 02:58:45 CET 2001 ... gmake[2]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' gmake ../../../build/bsd-i386/lib/i386/classic/libjvm.so VARIANT=OPT gmake[3]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' rm -f ../../../build/bsd-i386/tmp/java/java.lang/jvm/.classes.list if [ -s ../../../build/bsd-i386/tmp/java/java.lang/jvm/.classes.list ] ; \ then /usr/local/linux-jdk1.3.1/bin/javac -J-Xmx64m -classpath ../../../build/bsd-i386/classes -bootclasspath "" -sourcepath "../../../build/bsd-i386/gensrc:../../../src/solaris/classes:../../../src/share/classes" -d ../../../build/bsd-i386/classes \ ; \ fi /usr/local/linux-jdk1.3.1/bin/javah -old -bootclasspath ../../../build/bsd-i386/classes -d ../../../build/bsd-i386/tmp/java/java.lang/jvm/CClassHeaders/ \ java.io.InputStream java.lang.Boolean java.lang.Byte java.lang.Character java.lang.Class java.lang.ClassLoader java.lang.Double java.lang.Float java.lang.Integer java.lang.Long java.lang.Object java.lang.Runtime java.lang.Short java.lang.StackOverflowError java.lang.String java.lang.Thread java.lang.ThreadGroup java.lang.Throwable java.lang.ref.Reference java.lang.ref.SoftReference java.lang.reflect.Field java.lang.reflect.Method java.lang.reflect.Constructor java.lang.reflect.InvocationTargetException java.security.AccessControlContext java.util.Properties sun.io.ByteToCharConverter sun.io.CharToByteConverter sun.misc.VM java.util.MissingResourceException: Can't find bundle for base name com.sun.tools.javah.resources.FreeBSD_i386, locale en_US at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:712) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:683) at java.util.ResourceBundle.getBundle(ResourceBundle.java:546) at com.sun.tools.javah.Util.initPlatform(Util.java:159) at com.sun.tools.javah.Util.getPlatformString(Util.java:144) at com.sun.tools.javah.OldHeaders.write(OldHeaders.java:92) at com.sun.tools.javah.Gen.run(Gen.java:152) at com.sun.tools.javah.Main.run(Main.java:176) at com.sun.tools.javah.Main.main(Main.java:45) Error loading resources. Please file a bug report. gmake[3]: *** [../../../build/bsd-i386/tmp/java/java.lang/jvm/obj/.class.headers.i386] Error 10 gmake[3]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' gmake[2]: *** [optimized] Error 2 gmake[2]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' gmake[1]: *** [all] Error 1 gmake[1]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java' gmake: *** [all] Error 1 *** Error code 2 Stop in /usr/ports/java/jdk13. *** Error code 1 Stop in /usr/ports/java/jdk13. *** Error code 1 Stop in /usr/ports/java/jdk13. viking# make build ===> Building for jdk-1.3.1p5 i386 Build started: 1.3.1-internal-arcad-011214-03:12 Sanity check passed >>>Recursively making java all @ Fri Dec 14 03:12:36 CET 2001 ... gmake[1]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java' >>>Recursively making hpi all @ Fri Dec 14 03:12:36 CET 2001 ... gmake[2]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi' >>>Recursively making green all @ Fri Dec 14 03:12:36 CET 2001 ... gmake[3]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake ../../../../build/bsd-i386/lib/i386/green_threads/libhpi.so VARIANT=OPT gmake[4]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake[4]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake ../../../../build/bsd-i386/lib/i386/green_threads/libhpi_g.so VARIANT=DBG gmake[4]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake[4]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake[3]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' <<>>Recursively making version all @ Fri Dec 14 03:12:37 CET 2001 ... gmake[2]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/version' gmake[2]: Nothing to be done for `all'. viking# pwd /usr/ports/java/jdk13 viking# make build ===> Building for jdk-1.3.1p5 i386 Build started: 1.3.1-internal-arcad-011214-03:17 Sanity check passed >>>Recursively making java all @ Fri Dec 14 03:17:03 CET 2001 ... gmake[1]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java' >>>Recursively making hpi all @ Fri Dec 14 03:17:03 CET 2001 ... gmake[2]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi' >>>Recursively making green all @ Fri Dec 14 03:17:03 CET 2001 ... gmake[3]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake ../../../../build/bsd-i386/lib/i386/green_threads/libhpi.so VARIANT=OPT gmake[4]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake[4]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake ../../../../build/bsd-i386/lib/i386/green_threads/libhpi_g.so VARIANT=DBG gmake[4]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake[4]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' gmake[3]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' <<>>Recursively making version all @ Fri Dec 14 03:17:03 CET 2001 ... gmake[2]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/version' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/version' <<>>Recursively making jvm all @ Fri Dec 14 03:17:03 CET 2001 ... gmake[2]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' gmake ../../../build/bsd-i386/lib/i386/classic/libjvm.so VARIANT=OPT gmake[3]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' rm -f ../../../build/bsd-i386/tmp/java/java.lang/jvm/.classes.list if [ -s ../../../build/bsd-i386/tmp/java/java.lang/jvm/.classes.list ] ; \ then /usr/local/linux-jdk1.3.1/bin/javac -J-Xmx64m -classpath ../../../build/bsd-i386/classes -bootclasspath "" -sourcepath "../../../build/bsd-i386/gensrc:../../../src/solaris/classes:../../../src/share/classes" -d ../../../build/bsd-i386/classes \ ; \ fi /usr/local/linux-jdk1.3.1/bin/javah -old -bootclasspath ../../../build/bsd-i386/classes -d ../../../build/bsd-i386/tmp/java/java.lang/jvm/CClassHeaders/ \ java.io.InputStream java.lang.Boolean java.lang.Byte java.lang.Character java.lang.Class java.lang.ClassLoader java.lang.Double java.lang.Float java.lang.Integer java.lang.Long java.lang.Object java.lang.Runtime java.lang.Short java.lang.StackOverflowError java.lang.String java.lang.Thread java.lang.ThreadGroup java.lang.Throwable java.lang.ref.Reference java.lang.ref.SoftReference java.lang.reflect.Field java.lang.reflect.Method java.lang.reflect.Constructor java.lang.reflect.InvocationTargetException java.security.AccessControlContext java.util.Properties sun.io.ByteToCharConverter sun.io.CharToByteConverter sun.misc.VM java.util.MissingResourceException: Can't find bundle for base name com.sun.tools.javah.resources.FreeBSD_i386, locale en_US at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:712) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:683) at java.util.ResourceBundle.getBundle(ResourceBundle.java:546) at com.sun.tools.javah.Util.initPlatform(Util.java:159) at com.sun.tools.javah.Util.getPlatformString(Util.java:144) at com.sun.tools.javah.OldHeaders.write(OldHeaders.java:92) at com.sun.tools.javah.Gen.run(Gen.java:152) at com.sun.tools.javah.Main.run(Main.java:176) at com.sun.tools.javah.Main.main(Main.java:45) Error loading resources. Please file a bug report. gmake[3]: *** [../../../build/bsd-i386/tmp/java/java.lang/jvm/obj/.class.headers.i386] Error 10 gmake[3]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' gmake[2]: *** [optimized] Error 2 gmake[2]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' gmake[1]: *** [all] Error 1 gmake[1]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java' gmake: *** [all] Error 1 *** Error code 2 Stop in /usr/ports/java/jdk13. *** Error code 1 Stop in /usr/ports/java/jdk13. *** Error code 1 Stop in /usr/ports/java/jdk13. viking# To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Fri Dec 14 6:59:32 2001 Delivered-To: freebsd-java@freebsd.org Received: from calliope.cs.brandeis.edu (calliope.cs.brandeis.edu [129.64.3.189]) by hub.freebsd.org (Postfix) with ESMTP id A8E6D37B416; Fri, 14 Dec 2001 06:57:43 -0800 (PST) Received: from localhost (meshko@localhost) by calliope.cs.brandeis.edu (8.9.3/8.9.3) with ESMTP id JAA24261; Fri, 14 Dec 2001 09:57:41 -0500 Date: Fri, 14 Dec 2001 09:57:41 -0500 (EST) From: Mikhail Kruk To: Maxim Sobolev Cc: , "Arcadius A." Subject: Re: [Fwd: JDK13 BUG] In-Reply-To: <3C19B818.BA3FBC05@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org As usual locale related problem it seems... en_US is missing... Maybe he is missing en_US locale? Maybe it is not actually called en_US on FreeBSD? (I've been running FreeBSD with locale set to KOI8 for as long as I can remember ;) Anyway you may want to try cleaning up locale-related enironment variables before installing. > Does anybody have any ideas? > > -Maxim > > -------- Original Message -------- > Subject: JDK13 BUG > Date: Fri, 14 Dec 2001 03:27:45 +0100 > From: "Arcadius A." > Organization: CTU > To: sobomax@FreeBSD.ORG > > Hello ! > I've just updated all my port collection , then try to install the > FreeBSD JDK13 > I'm using FreeBSD 4.4 release ... > Of course , I got all the necessary files from the net .... > I think there is a bug in the port :" > java.util.MissingResourceException: Can't find bundle for base name > com.sun.tools.javah.resources.FreeBSD_i386, locale en_US " > > here is the output message when I try to build the port : > > > viking# pwd > /usr/ports/java/jdk13 > viking# which java > java: Command not found. > viking# make build > ===> Building for jdk-1.3.1p5 > i386 Build started: 1.3.1-internal-arcad-011214-02:58 > Sanity check passed > >>>Recursively making java all @ Fri Dec 14 02:58:44 CET 2001 ... > gmake[1]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java' > >>>Recursively making hpi all @ Fri Dec 14 02:58:44 CET 2001 ... > gmake[2]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi' > >>>Recursively making green all @ Fri Dec 14 02:58:44 CET 2001 ... > gmake[3]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > gmake ../../../../build/bsd-i386/lib/i386/green_threads/libhpi.so > VARIANT=OPT > gmake[4]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > gmake[4]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > gmake ../../../../build/bsd-i386/lib/i386/green_threads/libhpi_g.so > VARIANT=DBG > gmake[4]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > gmake[4]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > gmake[3]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > << 2001. > gmake[2]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi' > << >>>Recursively making version all @ Fri Dec 14 02:58:45 CET 2001 ... > gmake[2]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/version' > gmake[2]: Nothing to be done for `all'. > gmake[2]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/version' > << 2001. > >>>Recursively making jvm all @ Fri Dec 14 02:58:45 CET 2001 ... > gmake[2]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' > gmake ../../../build/bsd-i386/lib/i386/classic/libjvm.so VARIANT=OPT > gmake[3]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' > rm -f ../../../build/bsd-i386/tmp/java/java.lang/jvm/.classes.list > if [ -s ../../../build/bsd-i386/tmp/java/java.lang/jvm/.classes.list ] > ; > \ > then /usr/local/linux-jdk1.3.1/bin/javac -J-Xmx64m -classpath > ../../../build/bsd-i386/classes -bootclasspath "" -sourcepath > "../../../build/bsd-i386/gensrc:../../../src/solaris/classes:../../../src/share/classes" > -d ../../../build/bsd-i386/classes \ > ; \ > fi > /usr/local/linux-jdk1.3.1/bin/javah -old -bootclasspath > ../../../build/bsd-i386/classes -d > ../../../build/bsd-i386/tmp/java/java.lang/jvm/CClassHeaders/ \ > java.io.InputStream java.lang.Boolean java.lang.Byte > java.lang.Character java.lang.Class java.lang.ClassLoader > java.lang.Double java.lang.Float java.lang.Integer java.lang.Long > java.lang.Object java.lang.Runtime java.lang.Short > java.lang.StackOverflowError java.lang.String java.lang.Thread > java.lang.ThreadGroup java.lang.Throwable java.lang.ref.Reference > java.lang.ref.SoftReference java.lang.reflect.Field > java.lang.reflect.Method java.lang.reflect.Constructor > java.lang.reflect.InvocationTargetException > java.security.AccessControlContext java.util.Properties > sun.io.ByteToCharConverter sun.io.CharToByteConverter sun.misc.VM > java.util.MissingResourceException: Can't find bundle for base name > com.sun.tools.javah.resources.FreeBSD_i386, locale en_US > at > java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:712) > at > java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:683) > at java.util.ResourceBundle.getBundle(ResourceBundle.java:546) > at com.sun.tools.javah.Util.initPlatform(Util.java:159) > at com.sun.tools.javah.Util.getPlatformString(Util.java:144) > at com.sun.tools.javah.OldHeaders.write(OldHeaders.java:92) > at com.sun.tools.javah.Gen.run(Gen.java:152) > at com.sun.tools.javah.Main.run(Main.java:176) > at com.sun.tools.javah.Main.main(Main.java:45) > Error loading resources. Please file a bug report. > gmake[3]: *** > [../../../build/bsd-i386/tmp/java/java.lang/jvm/obj/.class.headers.i386] > Error 10 > gmake[3]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' > gmake[2]: *** [optimized] Error 2 > gmake[2]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' > gmake[1]: *** [all] Error 1 > gmake[1]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java' > gmake: *** [all] Error 1 > *** Error code 2 > > Stop in /usr/ports/java/jdk13. > *** Error code 1 > > Stop in /usr/ports/java/jdk13. > *** Error code 1 > > Stop in /usr/ports/java/jdk13. > viking# make build > ===> Building for jdk-1.3.1p5 > i386 Build started: 1.3.1-internal-arcad-011214-03:12 > Sanity check passed > >>>Recursively making java all @ Fri Dec 14 03:12:36 CET 2001 ... > gmake[1]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java' > >>>Recursively making hpi all @ Fri Dec 14 03:12:36 CET 2001 ... > gmake[2]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi' > >>>Recursively making green all @ Fri Dec 14 03:12:36 CET 2001 ... > gmake[3]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > gmake ../../../../build/bsd-i386/lib/i386/green_threads/libhpi.so > VARIANT=OPT > gmake[4]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > gmake[4]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > gmake ../../../../build/bsd-i386/lib/i386/green_threads/libhpi_g.so > VARIANT=DBG > gmake[4]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > gmake[4]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > gmake[3]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > << 2001. > gmake[2]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi' > << >>>Recursively making version all @ Fri Dec 14 03:12:37 CET 2001 ... > gmake[2]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/version' > gmake[2]: Nothing to be done for `all'. > viking# pwd > /usr/ports/java/jdk13 > viking# make build > ===> Building for jdk-1.3.1p5 > i386 Build started: 1.3.1-internal-arcad-011214-03:17 > Sanity check passed > >>>Recursively making java all @ Fri Dec 14 03:17:03 CET 2001 ... > gmake[1]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java' > >>>Recursively making hpi all @ Fri Dec 14 03:17:03 CET 2001 ... > gmake[2]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi' > >>>Recursively making green all @ Fri Dec 14 03:17:03 CET 2001 ... > gmake[3]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > gmake ../../../../build/bsd-i386/lib/i386/green_threads/libhpi.so > VARIANT=OPT > gmake[4]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > gmake[4]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > gmake ../../../../build/bsd-i386/lib/i386/green_threads/libhpi_g.so > VARIANT=DBG > gmake[4]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > gmake[4]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > gmake[3]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/green' > << 2001. > gmake[2]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi' > << >>>Recursively making version all @ Fri Dec 14 03:17:03 CET 2001 ... > gmake[2]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/version' > gmake[2]: Nothing to be done for `all'. > gmake[2]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/version' > << 2001. > >>>Recursively making jvm all @ Fri Dec 14 03:17:03 CET 2001 ... > gmake[2]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' > gmake ../../../build/bsd-i386/lib/i386/classic/libjvm.so VARIANT=OPT > gmake[3]: Entering directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' > rm -f ../../../build/bsd-i386/tmp/java/java.lang/jvm/.classes.list > if [ -s ../../../build/bsd-i386/tmp/java/java.lang/jvm/.classes.list ] > ; > \ > then /usr/local/linux-jdk1.3.1/bin/javac -J-Xmx64m -classpath > ../../../build/bsd-i386/classes -bootclasspath "" -sourcepath > "../../../build/bsd-i386/gensrc:../../../src/solaris/classes:../../../src/share/classes" > -d ../../../build/bsd-i386/classes \ > ; \ > fi > /usr/local/linux-jdk1.3.1/bin/javah -old -bootclasspath > ../../../build/bsd-i386/classes -d > ../../../build/bsd-i386/tmp/java/java.lang/jvm/CClassHeaders/ \ > java.io.InputStream java.lang.Boolean java.lang.Byte > java.lang.Character java.lang.Class java.lang.ClassLoader > java.lang.Double java.lang.Float java.lang.Integer java.lang.Long > java.lang.Object java.lang.Runtime java.lang.Short > java.lang.StackOverflowError java.lang.String java.lang.Thread > java.lang.ThreadGroup java.lang.Throwable java.lang.ref.Reference > java.lang.ref.SoftReference java.lang.reflect.Field > java.lang.reflect.Method java.lang.reflect.Constructor > java.lang.reflect.InvocationTargetException > java.security.AccessControlContext java.util.Properties > sun.io.ByteToCharConverter sun.io.CharToByteConverter sun.misc.VM > java.util.MissingResourceException: Can't find bundle for base name > com.sun.tools.javah.resources.FreeBSD_i386, locale en_US > at > java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:712) > at > java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:683) > at java.util.ResourceBundle.getBundle(ResourceBundle.java:546) > at com.sun.tools.javah.Util.initPlatform(Util.java:159) > at com.sun.tools.javah.Util.getPlatformString(Util.java:144) > at com.sun.tools.javah.OldHeaders.write(OldHeaders.java:92) > at com.sun.tools.javah.Gen.run(Gen.java:152) > at com.sun.tools.javah.Main.run(Main.java:176) > at com.sun.tools.javah.Main.main(Main.java:45) > Error loading resources. Please file a bug report. > gmake[3]: *** > [../../../build/bsd-i386/tmp/java/java.lang/jvm/obj/.class.headers.i386] > Error 10 > gmake[3]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' > gmake[2]: *** [optimized] Error 2 > gmake[2]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/jvm' > gmake[1]: *** [all] Error 1 > gmake[1]: Leaving directory > `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java' > gmake: *** [all] Error 1 > *** Error code 2 > > Stop in /usr/ports/java/jdk13. > *** Error code 1 > > Stop in /usr/ports/java/jdk13. > *** Error code 1 > > Stop in /usr/ports/java/jdk13. > viking# > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-java" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Fri Dec 14 7: 7:29 2001 Delivered-To: freebsd-java@freebsd.org Received: from service.sh.cvut.cz (service.sh.cvut.cz [147.32.127.214]) by hub.freebsd.org (Postfix) with ESMTP id CBC6137B41A; Fri, 14 Dec 2001 07:07:26 -0800 (PST) Received: from Heptium.sh.cvut.cz (heptium.sh.cvut.cz [147.32.127.194]) by service.sh.cvut.cz (Postfix) with ESMTP id 9C6541E65E; Fri, 14 Dec 2001 16:07:24 +0100 (CET) Received: from viking (viking.sh.cvut.cz [147.32.124.181]) by Heptium.sh.cvut.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id QAA12991; Fri, 14 Dec 2001 16:07:20 +0100 X-Authentication-Warning: Heptium.sh.cvut.cz: Host viking.sh.cvut.cz [147.32.124.181] claimed to be viking Message-ID: <007f01c184b1$0556d8a0$b57c2093@viking> From: "Arcadius A." To: "Mikhail Kruk" , "Maxim Sobolev" Cc: References: Subject: Re: [Fwd: JDK13 BUG] Date: Fri, 14 Dec 2001 16:07:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > As usual locale related problem it seems... > en_US is missing... Maybe he is missing en_US locale? Maybe it is not > actually called en_US on FreeBSD? (I've been running > FreeBSD with locale set to KOI8 for as long as I can remember ;) > Anyway you may want to try cleaning up locale-related enironment variables > before installing. I live in Czech Republic (central Europe) so , my time zone is "CET" ; but I'm using U.S. english only on my box.. How can I clean up "locale-related enironment variables" ? Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message From owner-freebsd-java Fri Dec 14 17: 4:30 2001 Delivered-To: freebsd-java@freebsd.org Received: from service.sh.cvut.cz (service.sh.cvut.cz [147.32.127.214]) by hub.freebsd.org (Postfix) with ESMTP id F350B37B419; Fri, 14 Dec 2001 17:04:22 -0800 (PST) Received: from Heptium.sh.cvut.cz (heptium.sh.cvut.cz [147.32.127.194]) by service.sh.cvut.cz (Postfix) with ESMTP id 668761E68C; Sat, 15 Dec 2001 02:04:21 +0100 (CET) Received: from sh.cvut.cz (viking.sh.cvut.cz [147.32.124.181]) by Heptium.sh.cvut.cz (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id CAA28886; Sat, 15 Dec 2001 02:04:21 +0100 X-Authentication-Warning: Heptium.sh.cvut.cz: Host viking.sh.cvut.cz [147.32.124.181] claimed to be sh.cvut.cz Message-ID: <3C1AA194.B96F7FA5@sh.cvut.cz> Date: Sat, 15 Dec 2001 02:04:20 +0100 From: "Arcadius A." Organization: CTU X-Mailer: Mozilla 4.77 [en] (X11; U; FreeBSD 4.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: dirk@FreeBSD.org, freebsd-java@FreeBSD.org Subject: linux-jdk1.3.1 & mod_jk ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello ! I hope I'm sending this email to the right address .... I've just installed the linux-jdk13 port on my FreeBSD4.4 box .... I've also built and installed tomcat with the linux-jdk13 port .... but I'm having troubles building the mod_jk with the linux-jdk .... Please , can someone tell me the steps to follow ? I have the most recent port collection. my modified Makefile looks like this : # New ports collection makefile for: mod_jk # Date created: Sun May 20 12:58:02 CEST 2001 # Whom: Dirk Froemberg # # $FreeBSD: ports/www/mod_jk/Makefile,v 1.3 2001/10/02 22:47:24 mharo Exp $ # PORTNAME= mod_jk PORTVERSION= 3.2.3 CATEGORIES= www MASTER_SITES= http://www.apache.org/dist/jakarta/jakarta-tomcat/release/v${PORTVERSION}/src/ DISTNAME= jakarta-tomcat-${PORTVERSION}-src MAINTAINER= dirk@FreeBSD.org BUILD_DEPENDS= ${APXS}:${PORTSDIR}/www/apache13 \ ${LOCALBASE}/linux-jdk1.3.1/bin/javac:${PORTSDIR}/java/linux-jdk13 RUN_DEPENDS= ${APXS}:${PORTSDIR}/www/apache13 \ ${LOCALBASE}/tomcat/lib/webserver.jar:${PORTSDIR}/www/jakarta-tomcat USE_GMAKE= yes MAKEFILE= Makefile.freebsd WRKSRC= ${WRKDIR}/jakarta-tomcat-${PORTVERSION}-src/src/native/apache1.3 APXS?= ${LOCALBASE}/sbin/apxs do-install: ${APXS} -i -A -n jk ${WRKSRC}/mod_jk.so ${SED} -e "s#%%PREFIX%%#${PREFIX}#g" ${FILESDIR}/mod_jk.conf > ${WRKDIR}/mod_jk.conf ${INSTALL_DATA} ${WRKDIR}/mod_jk.conf ${PREFIX}/etc/apache @${SED} -e 's#/usr/local#${PREFIX}#g' ${PKGMESSAGE} .include ## EOF Is this alright ? .... but the problem should be with the "patch-aa" file .... my "patch-aa" file looks like this : --- Makefile.freebsd.orig Tue Dec 12 23:51:55 2000 +++ Makefile.freebsd Sun May 20 15:50:41 2001 @@ -1,18 +1,18 @@ ## You need to edit this file - configure later :-) -APACHE_HOME=/usr/local/apache OS=freebsd -APXS=${APACHE_HOME}/bin/apxs +APXS=${PREFIX}/sbin/apxs -A13_FLAGS=-I${APACHE_HOME}/include +A13_FLAGS=-I${PREFIX}/include/apache ## I assume this one is set up already ## -# JAVA_HOME=/usr/local/linux-jdk1.3.1 +JAVA_HOME=${PREFIX}/linux-jdk1.3.1 JAVA_INCL=-I${JAVA_HOME}/include -I${JAVA_HOME}/include/${OS} JAVA_LIB=-L${JAVA_HOME}/jre/lib/${ARCH} -L${JAVA_HOME}/lib/${ARCH}/native_threads -CFLAGS=-DHAVE_CONFIG_H -g -fpic -DSHARED_MODULE -O2 -D_REENTRANT -pthread -DLINUX -Wall +XCFLAGS=${CFLAGS} +CFLAGS=-DHAVE_CONFIG_H -fpic -DSHARED_MODULE -DFREEBSD -Wall JK=../jk/ SRCS=jk_ajp12_worker.c jk_connect.c jk_msg_buff.c jk_util.c jk_ajp13.c \ @@ -23,7 +23,7 @@ OBJS=${patsubst %.c,%.o,${SRCS}} %.o: ../jk/%.c - ${CC} -c ${CFLAGS} ${JAVA_INCL} ${A13_FLAGS} $< -o $@ + ${CC} -c ${XCFLAGS} ${CFLAGS} ${JAVA_INCL} ${A13_FLAGS} $< -o $@ .c.o: ${APXS} -c ${JAVA_INCL} -DFREEBSD ${A13_FLAGS} -I../jk $< ## EOF when I make the built , I get the following error: arcad_root @ viking : /usr/ports/www/mod_jk # make build ===> Extracting for mod_jk-3.2.3 >> Checksum OK for jakarta-tomcat-3.2.3-src.tar.gz. ===> mod_jk-3.2.3 depends on file: /usr/local/sbin/apxs - found ===> mod_jk-3.2.3 depends on file: /usr/local/linux-jdk1.3.1/bin/javac - found ===> mod_jk-3.2.3 depends on executable: gmake - found ===> Patching for mod_jk-3.2.3 ===> Applying FreeBSD patches for mod_jk-3.2.3 patch: **** malformed patch at line 26: SRCS=jk_ajp12_worker.c jk_connect.c jk_msg_buff.c jk_util.c jk_ajp13.c \ >> Patch patch-aa failed to apply cleanly. *** Error code 1 Stop in /usr/ports/www/mod_jk. *** Error code 1 Stop in /usr/ports/www/mod_jk. *** Error code 1 Stop in /usr/ports/www/mod_jk. *** Error code 1 Stop in /usr/ports/www/mod_jk. *** Error code 1 Stop in /usr/ports/www/mod_jk. arcad_root @ viking : /usr/ports/www/mod_jk # But I havent's edited the line 26 at all !.... so , what have I done wrong ? Thanks.... Arcadius. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message