From mr at sun.com Sat Mar 1 07:46:24 2008 From: mr at sun.com (Mark Reinhold) Date: Fri, 29 Feb 2008 23:46:24 -0800 Subject: FYI: Mercurial gates are open for JDK 7 Message-ID: <20080301074624.687F97B67@callebaut.niobe.net> Changesets can now be pushed into the JDK 7 Mercurial repositories [1]. At the moment the only developers with push rights are Sun employees, but that will change over time. Many of us working on JDK 7 have built up a considerable backlog over the last few months, so expect to see a significant number of changesets over the next few weeks. The draft Developers' Guide describes the forest layout and naming scheme, and how to install and configure Mercurial [2]. Note to those outside of Sun: You may see references to "jcheck", a Mercurial extension that validates changeset comments and contents and is run in all the repository gates. This extension will be open-sourced just as soon as it completes Sun's internal legal-review process. - Mark [1] http://hg.openjdk.java.net/jdk7/jdk7 [2] http://openjdk.java.net/guide/repositories.html From fw at deneb.enyo.de Sat Mar 1 09:32:29 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 01 Mar 2008 10:32:29 +0100 Subject: FYI: Mercurial gates are open for JDK 7 In-Reply-To: <20080301074624.687F97B67@callebaut.niobe.net> (Mark Reinhold's message of "Fri, 29 Feb 2008 23:46:24 -0800") References: <20080301074624.687F97B67@callebaut.niobe.net> Message-ID: <87ve4694cy.fsf@mid.deneb.enyo.de> * Mark Reinhold: > [1] http://hg.openjdk.java.net/jdk7/jdk7 Is this the MASTER repository mentioned in the documentation? This is not 100% clear from the description. From Kelly.Ohair at Sun.COM Sat Mar 1 17:35:15 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sat, 01 Mar 2008 09:35:15 -0800 Subject: FYI: Mercurial gates are open for JDK 7 In-Reply-To: <87ve4694cy.fsf@mid.deneb.enyo.de> References: <20080301074624.687F97B67@callebaut.niobe.net> <87ve4694cy.fsf@mid.deneb.enyo.de> Message-ID: <47C993D3.9040201@sun.com> I'll stick my nose in... Mark may be getting some sleep. ;^) Yes. Although keep in mind it's a forest of repositories. -kto Florian Weimer wrote: > * Mark Reinhold: > >> [1] http://hg.openjdk.java.net/jdk7/jdk7 > > Is this the MASTER repository mentioned in the documentation? This is > not 100% clear from the description. From gnu_andrew at member.fsf.org Wed Mar 5 22:09:53 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 5 Mar 2008 22:09:53 +0000 Subject: Google Summer of Code 2008 Message-ID: <17c6771e0803051409k2bb207d2sc52d71e155a6da1e@mail.gmail.com> Hi everyone, Are there any plans for OpenJDK to try and participate in Google's Summer of Code this year? The deadline for mentoring organisations is March 12th. With the Innovation Awards taking place as well, it may just be too much to deal with simultaneously however. -- Andrew :-) Document Freedom Day - March 26th http://documentfreedom.org Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net From Xiomara.Jayasena at Sun.COM Fri Mar 7 03:15:25 2008 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Thu, 06 Mar 2008 19:15:25 -0800 Subject: JDK 7 Integration Schedule Message-ID: <47D0B34D.90604@sun.com> Hi, When a team is ready to push their changes to the MASTER repositories they would then do an integration. Integrations are done regularly on a bi-weekly basis for now but may become weekly in the future. The following is the integration schedule: http://openjdk.java.net/projects/jdk7/builds Some basics for integrators: 1) pull and merge changes from the MASTER repositories from here: http://hg.openjdk.java.net/jdk7/jdk7 to the integration area. e.g. hg fclone http://hg.openjdk.java.net/jdk7/jdk7 integration then merge this with your repository changes. 2) Ensure the integration area builds and tests OK. 3) Check correct content of bug id numbers, rfe's, etc. 4) Push changes to the MASTER jdk 7 repositories. Results of integration pushes will appear on jdk7-dev at openjdk.java.net so if interested in seeing the changes then subscribe to that alias. For schedule changes send mail to: jdk7-gk at openjdk.java.net or send me a note. Thanks, -Xiomara From mr at sun.com Fri Mar 14 17:51:29 2008 From: mr at sun.com (Mark Reinhold) Date: Fri, 14 Mar 2008 10:51:29 -0700 Subject: Mercurial notifications Message-ID: <20080314175129.F14D0204A@eggemoggin.niobe.net> The Mercurial gates for JDK 7 have now been open for almost two weeks. Once the initial flurry of pushes for the jcheck configuration file that was needed in each and every repository blew past (sorry about that), we've seen 61 pushes of actual code into the various JDK 7 development forests. The forests were initially configured to send push-notification messages to the primary -dev mailing lists of the appropriate Group(s). This seemed like a reasonable starting point, on the assumption that if a Group has Members who regularly push code into a JDK 7 forest then they'll want to (and arguably should) be aware of every push into that forest. Some have expressed the concern, privately, that this results in people receiving too many messages in which they're not actually interested. There are (at least) a couple of ways to deal with this: - People can filter the incoming messages (look for the X-Hg-URL header, which points back to the repository for which the notification was generated); or - We could create an additional list for each forest and arrange to send Mercurial notifications to those lists only. People could then subscribe to those lists, or subscribe to the appropriate per-repository RSS feeds (broken at the moment, but to be fixed soon), or live in peaceful ignorance. So, what do people think? Should we create separate per-forest lists for Mercurial notifications, do nothing, or do something else? BTW, when gatekeepers integrate changes from their local forests into the master forest (jdk7/jdk7) then the resulting notification messages will be sent to jdk7-dev at openjdk.java.net. Integrations take place at most two or three times a day [1], so this should not result in an enormous amount of traffic. Also BTW, if you want to see every single push notification then you can subscribe to jdk7-changes at ojn. It does make for interesting reading ... - Mark [1] http://openjdk.java.net/projects/jdk7/builds/ From roman at kennke.org Fri Mar 14 18:40:46 2008 From: roman at kennke.org (Roman Kennke) Date: Fri, 14 Mar 2008 19:40:46 +0100 Subject: Mercurial notifications In-Reply-To: <20080314175129.F14D0204A@eggemoggin.niobe.net> References: <20080314175129.F14D0204A@eggemoggin.niobe.net> Message-ID: <1205520046.9971.21.camel@mercury> Hi Mark, > Once the initial flurry of pushes for the jcheck configuration file that > was needed in each and every repository blew past (sorry about that), > we've seen 61 pushes of actual code into the various JDK 7 development > forests. Yeah, that is very nice. Finally we can see what is going on. > The forests were initially configured to send push-notification messages > to the primary -dev mailing lists of the appropriate Group(s). This > seemed like a reasonable starting point, on the assumption that if a > Group has Members who regularly push code into a JDK 7 forest then > they'll want to (and arguably should) be aware of every push into that > forest. > Some have expressed the concern, privately, that this results in people > receiving too many messages in which they're not actually interested. > There are (at least) a couple of ways to deal with this: > > - People can filter the incoming messages (look for the X-Hg-URL > header, which points back to the repository for which the > notification was generated); or > > - We could create an additional list for each forest and arrange to > send Mercurial notifications to those lists only. People could > then subscribe to those lists, or subscribe to the appropriate > per-repository RSS feeds (broken at the moment, but to be fixed > soon), or live in peaceful ignorance. > > So, what do people think? Should we create separate per-forest lists for > Mercurial notifications, do nothing, or do something else? I think it is important to be able to see every commit. I'm not sure if the commit messages should go to the -dev mailinglists though. I for one would subscribe to the RSS feeds published by the repositories, that is perfect for me. I would rather not create more mailinglists, there are already to many of them. I also don't care having the commit messages on the -dev lists. They are easy enough to filter. Cheers, /Roman -- http://kennke.org/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From Jonathan.Gibbons at Sun.COM Fri Mar 14 20:14:20 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 14 Mar 2008 13:14:20 -0700 Subject: Mercurial notifications In-Reply-To: <20080314175129.F14D0204A@eggemoggin.niobe.net> References: <20080314175129.F14D0204A@eggemoggin.niobe.net> Message-ID: <47DADC9C.8030809@sun.com> Mark Reinhold wrote: > Some have expressed the concern, privately, that this results in people > receiving too many messages in which they're not actually interested. > There are (at least) a couple of ways to deal with this: > > - People can filter the incoming messages (look for the X-Hg-URL > header, which points back to the repository for which the > notification was generated); or > > - We could create an additional list for each forest and arrange to > send Mercurial notifications to those lists only. People could > then subscribe to those lists, or subscribe to the appropriate > per-repository RSS feeds (broken at the moment, but to be fixed > soon), or live in peaceful ignorance. > > So, what do people think? Should we create separate per-forest lists for > Mercurial notifications, do nothing, or do something else? Filtering messages is inconvenient and if most people are filtering them out, then that is a symptom that something is wrong in the first place. For my part, I use three different mail readers depending on time of day and where I am, to keep track of mail, and it makes it more annoying to have to set up and maintain filters on each system. I also know (from private communication) that some people have unsubscribed from -dev lists because of the increased mail traffic. Also, filtering does not apply to the mail archives, If you look at the compiler-dev archive, for example, it is now dominated by hg messages. http://mail.openjdk.java.net/pipermail/compiler-dev/2008-March/subject.html#start In addition, the hg messages to compiler-dev are duplicated on serviceability-dev ... http://mail.openjdk.java.net/pipermail/serviceability-dev/2008-March/subject.html and core-libs-dev ... http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-March/subject.html Would it not make more sense to have the hg messages that go to all these aliases instead go to a separate alias to which people can choose to subscribe or not. Finally, relevance and interest. There are over 200 people subscribed to the compiler-dev list (my favorite example of course.) Of those, there are only a few who can put back changes and who may be interested in all the change messages. There may be some more that may be interested in messages related to updates to the compiler itself. Which probably leaves 60%-70% of people subscribed to the alias for any interesting discussion regarding compiler development and who probably are not interested in any putback messages at all. -- Jon From gnu_andrew at member.fsf.org Sat Mar 15 00:10:54 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sat, 15 Mar 2008 00:10:54 +0000 Subject: Mercurial notifications In-Reply-To: <1205520046.9971.21.camel@mercury> References: <20080314175129.F14D0204A@eggemoggin.niobe.net> <1205520046.9971.21.camel@mercury> Message-ID: <17c6771e0803141710i1e21dedfu50a5ae7209e5032a@mail.gmail.com> On 14/03/2008, Roman Kennke wrote: > Hi Mark, > > > > Once the initial flurry of pushes for the jcheck configuration file that > > was needed in each and every repository blew past (sorry about that), > > we've seen 61 pushes of actual code into the various JDK 7 development > > forests. > > > Yeah, that is very nice. Finally we can see what is going on. > +1 from me too :) > > > The forests were initially configured to send push-notification messages > > to the primary -dev mailing lists of the appropriate Group(s). This > > seemed like a reasonable starting point, on the assumption that if a > > Group has Members who regularly push code into a JDK 7 forest then > > they'll want to (and arguably should) be aware of every push into that > > forest. > > > Some have expressed the concern, privately, that this results in people > > receiving too many messages in which they're not actually interested. > > There are (at least) a couple of ways to deal with this: > > > > - People can filter the incoming messages (look for the X-Hg-URL > > header, which points back to the repository for which the > > notification was generated); or > > > > - We could create an additional list for each forest and arrange to > > send Mercurial notifications to those lists only. People could > > then subscribe to those lists, or subscribe to the appropriate > > per-repository RSS feeds (broken at the moment, but to be fixed > > soon), or live in peaceful ignorance. > > > > So, what do people think? Should we create separate per-forest lists for > > Mercurial notifications, do nothing, or do something else? > > > I think it is important to be able to see every commit. I'm not sure if > the commit messages should go to the -dev mailinglists though. I for one > would subscribe to the RSS feeds published by the repositories, that is > perfect for me. I would rather not create more mailinglists, there are > already to many of them. I also don't care having the commit messages on > the -dev lists. They are easy enough to filter. > I agree with Roman. With Classpath we've also had separate discussion, patch and commit lists. However, that is for the _whole project_. It doesn't scale to the OpenJDK multitude of lists so I think RSS feeds would be a good option, given the messages are archived anyway in Mercurial itself. I think the point about the -dev lists being flooded with commit messages is a pertinent one; it hides discussion threads and persists in the archive even if painstakingly filtered by each user. > Cheers, > /Roman > > > -- > http://kennke.org/blog/ > > -- Andrew :-) Document Freedom Day - March 26th http://documentfreedom.org Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Jonathan.Gibbons at Sun.COM Sat Mar 15 01:30:26 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 14 Mar 2008 18:30:26 -0700 Subject: Where's jtreg? Message-ID: <47DB26B2.4050201@sun.com> Where's jtreg? People have been looking for the source code for the regression test harness, jtreg, recently, in the light of some recent comments about its availability. In fact, we are still awaiting the necessary approvals to release the source code, so you cannot find it outside of Sun, yet. But, we know you are waiting for it and we are still working to make it happen. Separately, there is still some minor engineering work to be done. The source code is currently an extension of Sun's test harness, JavaTest. That has been already released as open source under the name jtharness, and you can find the source for that at https://jtharness.dev.java.net/. What remains for jtreg is to make sure that it compiles, builds, and behaves correctly against the latest stable version of jtharness. Where will it be available? Probably the simplest way to publish the jtreg source is as a source bundle, in the same way we published the source bundle for the compiler in the early days of OpenJDK. If there is sufficient interest, it has been suggested that we could also start an OpenJDK project for jtreg. When will it be available? Well, as soon as we can get the approvals. Watch this space; we'll make an announcement here when it is available. -- Jonathan Gibbons From robilad at kaffe.org Sat Mar 15 20:02:14 2008 From: robilad at kaffe.org (Dalibor Topic) Date: Sat, 15 Mar 2008 21:02:14 +0100 Subject: Where's jtreg? In-Reply-To: <47DB26B2.4050201@sun.com> References: <47DB26B2.4050201@sun.com> Message-ID: <47DC2B46.1000108@kaffe.org> Jonathan Gibbons wrote: > When will it be available? Well, as soon as we can get the approvals. > Watch this space; we'll make an announcement here when it is available. Thanks Jonathan, I hope you'll get the approvals quickly. cheers, dalibor topic From robilad at kaffe.org Sat Mar 15 20:11:42 2008 From: robilad at kaffe.org (Dalibor Topic) Date: Sat, 15 Mar 2008 21:11:42 +0100 Subject: Mercurial notifications In-Reply-To: <20080314175129.F14D0204A@eggemoggin.niobe.net> References: <20080314175129.F14D0204A@eggemoggin.niobe.net> Message-ID: <47DC2D7E.2070205@kaffe.org> Mark Reinhold wrote: > - We could create an additional list for each forest and arrange to > send Mercurial notifications to those lists only. People could > then subscribe to those lists, or subscribe to the appropriate > per-repository RSS feeds (broken at the moment, but to be fixed > soon), or live in peaceful ignorance. That sounds like the way to go. cheers, dalibor topic From Jonathan.Gibbons at Sun.COM Tue Mar 18 00:47:55 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 17 Mar 2008 17:47:55 -0700 Subject: CFV: New Member Neal Gafter In-Reply-To: <47D5FE2B.805@sun.com> References: <47D5FE2B.805@sun.com> Message-ID: <47DF113B.3050802@sun.com> The voting has now closed, and the results have been tallied. Valid votes were received from the following Members of the Compiler Group Joe.Darcy at Sun.COM Vote: yes iris at sun.com Vote: yes Kumar.Srinivasan at Sun.COM Vote: yes According to the rules[*], this is sufficient to approve the proposal for Neal Gafter to become a Member of the Compiler Group. Welcome, Neal. -- Jonathan Gibbons [*] http://openjdk.java.net/groups/ Jonathan Gibbons wrote: > Neal Gafter has requested to be a Member of the Compiler Group. > > Please cast your vote by replying to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may indicate the reason for your decision, if you wish, on > subsequent lines. > This is optional and not required. > > Votes are due by midnight UTC next Monday, 17 March, after which time > the votes will > be tallied and reported to this list and to discuss at openjdk.java.net. > > Only Members of the Compiler Group are eligible to vote on this > decision. [1] > > The current Members are: > > Alex Buckley > Maurizio Cimadamore > Iris Clark > Joe Darcy > Jonathan Gibbons > Kumar Srinivasan > > > [1] http://blogs.sun.com/mr/entry/cosmology > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robilad at kaffe.org Tue Mar 18 12:22:20 2008 From: robilad at kaffe.org (Dalibor Topic) Date: Tue, 18 Mar 2008 13:22:20 +0100 Subject: Announcing Finalists for the OpenJDK Community Innovator's Challenge In-Reply-To: <47DF20CF.8030103@sun.com> References: <47DF20CF.8030103@sun.com> Message-ID: <47DFB3FC.60501@kaffe.org> Rich Sands wrote: > Thanks again to everyone who has participated. Good luck to all > Finalists on your projects! Congrats to proposals that made it into the finals, and best of luck for everyone involved for the projects. cheers, dalibor topic From linuxhippy at gmail.com Fri Mar 21 12:25:10 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 21 Mar 2008 13:25:10 +0100 Subject: JNI-performance - Is it really that fast? Message-ID: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> Hello, I did some benchmarks to evaluate JNI-call-per-operation vs. Command-batch-buffer performance for a design where low per-primitive overhead is important. I was totally impressed about the low overhead JNI has in modern SUN-JVMs. On my Core2Duo-2ghz it took only 35cycles to call a native method with 4 jint parameters and count an int-loop-counter up, 58mio times per second. Making the methods synchronized however time went up to 100 cycles per call. Has JNI really become that fast, or is it likely that I have hit a microbenchmark trap? I thought JDK6 has BiasedLocking (I only tested single threaded), why is synchronization so expensive in this case? (my call-graph is benchmark-loop -> (synchronized) accessor-method -> native-method). Thanks, lg Clemens From roman.kennke at aicas.com Fri Mar 21 12:31:28 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Fri, 21 Mar 2008 13:31:28 +0100 Subject: JNI-performance - Is it really that fast? In-Reply-To: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> References: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> Message-ID: <1206102688.6262.3.camel@mercury> Hi, > Has JNI really become that fast Yes, I think so. /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-0 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From Paul.Hohensee at Sun.COM Fri Mar 21 20:43:37 2008 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 21 Mar 2008 16:43:37 -0400 Subject: JNI-performance - Is it really that fast? In-Reply-To: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> References: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> Message-ID: <47E41DF9.7010702@sun.com> Yes, it really is that fast. Sounds like biased locking is disabled, which it shouldn't be. We'd have to have the benchmark source to puzzle out why. Paul Clemens Eisserer wrote: > Hello, > > I did some benchmarks to evaluate JNI-call-per-operation vs. > Command-batch-buffer performance for a design where low per-primitive > overhead is important. > > I was totally impressed about the low overhead JNI has in modern > SUN-JVMs. On my Core2Duo-2ghz it took only 35cycles to call a native > method with 4 jint parameters and count an int-loop-counter up, 58mio > times per second. Making the methods synchronized however time went up > to 100 cycles per call. > > Has JNI really become that fast, or is it likely that I have hit a > microbenchmark trap? > I thought JDK6 has BiasedLocking (I only tested single threaded), why > is synchronization so expensive in this case? (my call-graph is > benchmark-loop -> (synchronized) accessor-method -> native-method). > > Thanks, lg Clemens > From popeyelin at gmail.com Fri Mar 21 20:55:19 2008 From: popeyelin at gmail.com (yueyu lin) Date: Fri, 21 Mar 2008 13:55:19 -0700 Subject: JNI-performance - Is it really that fast? In-Reply-To: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> References: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> Message-ID: <8e7e4d020803211355k1ecd167du14388be710159fd1@mail.gmail.com> You can look at the BerkeleyDB's JNI wrapper edition(not Java Edition), it's almost as fast as its c edition from my experience. I use both of them in production. On Fri, Mar 21, 2008 at 5:25 AM, Clemens Eisserer wrote: > Hello, > > I did some benchmarks to evaluate JNI-call-per-operation vs. > Command-batch-buffer performance for a design where low per-primitive > overhead is important. > > I was totally impressed about the low overhead JNI has in modern > SUN-JVMs. On my Core2Duo-2ghz it took only 35cycles to call a native > method with 4 jint parameters and count an int-loop-counter up, 58mio > times per second. Making the methods synchronized however time went up > to 100 cycles per call. > > Has JNI really become that fast, or is it likely that I have hit a > microbenchmark trap? > I thought JDK6 has BiasedLocking (I only tested single threaded), why > is synchronization so expensive in this case? (my call-graph is > benchmark-loop -> (synchronized) accessor-method -> native-method). > > Thanks, lg Clemens > -- -- Yueyu Lin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mr at sun.com Fri Mar 21 21:42:25 2008 From: mr at sun.com (Mark Reinhold) Date: Fri, 21 Mar 2008 14:42:25 -0700 Subject: Request for comments: OpenJDK Trademark Notice Message-ID: <20080321214225.4B7B65B656@eggemoggin.niobe.net> Over the last couple of months a group of us here at Sun has been working with developers at Red Hat and Canonical to integrate packages based on the open-source JDK 6 code [1] into the upcoming Fedora 9 [2] and Ubuntu Hardy Heron [3] releases. The names of these packages include the token "openjdk", and the version strings say "OpenJDK". In Hardy Heron, for example, the packages share the prefix "openjdk-6", and running "java -version" after installing them produces the output: openjdk version "1.6.0" OpenJDK Runtime Environment (build 1.6.0-b06) OpenJDK Server VM (build 1.6.0-b06, mixed mode) Now "OpenJDK" is a trademark of Sun Microsystems, so we had to come up with a way to grant permission for these types of uses. Working with Sun's trademark counsel we drafted the OpenJDK Trademark Notice and published the first version in the b06 source bundle, in the TRADEMARK file at the root of the tree. Based on early feedback from Andrew Haley, Dalibor Topic, Mark Wielaard, and others, we revised it slightly and published v1.1 [4] in b07, which shipped yesterday [5]. We couldn't address all of the open issues in time for v1.1, so attached below is the current draft of version 1.2 of the Notice. The differences from v1.1 are: - The term "Owner" has been changed to "Trademark Owner", just to make it absolutely clear that Sun is not, in this Notice, claiming ownership of anything other than the "OpenJDK" trademark; - The list of URLs from which the original code may be downloaded has been corrected and clarified, and also generalized to allow successor locations to be designated in the future; - A clause has been added to allow porting efforts to use the trademark; and - A clause has been added to allow downstream repackagers to use the HotSpot code from a different source tree if necessary, e.g. in order to use the C++ interpreter that's available in the jdk7 tree but not in the jdk6 tree. We hope to finalize this new version of the Notice by the end of next week (28 March). Comment and suggestions are most welcome. - Mark [1] http://openjdk.java.net/projects/jdk6/ [2] http://fedoraproject.org/wiki/Docs/Beats/Java [3] http://packages.ubuntu.com/openjdk?suite=hardy&keywords=openjdk [4] http://openjdk.java.net/legal/openjdk-trademark-notice.html [5] http://download.java.net/openjdk/jdk6/ -------------- next part -------------- OpenJDK Trademark Notice DRAFT Version 1.2, 2008/3/20 OpenJDK (the "Name") is a trademark of Sun Microsystems, Inc. (the "Trademark Owner"). Trademark Owner publishes source code (the "Original Software") at several World Wide Web locations (each a "Website"). These locations include: http://download.java.net/openjdk/jdk6 http://download.java.net/openjdk/jdk7 http://hg.openjdk.java.net/jdk6/jdk6 http://hg.openjdk.java.net/jdk7/jdk7 as well as any successor locations designated by Trademark Owner in future revisions of this Notice. Each Website provides Original Software in two parts: A Java virtual machine (the "Virtual Machine") and an API library and tools (the "Library and Tools"). Trademark Owner permits any person obtaining a copy of this software (the "Software") that is based on Original Software to use the Name in the package names and version strings of the Software subject to the following conditions: (1) The Software is a substantially complete implementation of the OpenJDK development-kit or runtime-environment source code retrieved from a single Website, and the vast majority of the Software code is identical to that upstream Original Software, except that: (a) Changes required to port Original Software to new operating systems or hardware architectures are permitted, so long as that work takes place in the context of an approved Project hosted in the OpenJDK Community; and (b) A Virtual Machine from one Website may be combined with the Library and Tools of another Website, so long as the vast majority of the code in each is identical to the corresponding upstream Virtual Machine or Library and Tools component. (2) No permission is hereby granted to use the Name in any other manner, unless such use constitutes "fair use", for example "based on the OpenJDK source code" or "Ubuntu's packaging of the OpenJDK 6 code". (3) Trademark Owner makes no warranties of any kind respecting the Name and all representations and warranties, including any implied warranty of merchantability, fitness for a particular purpose or non-infringement are hereby disclaimed. (4) Finally, this notice and the following legend are included in all copies of the Software or portions of it: OpenJDK is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries. Trademark Owner intends to revise this Notice as necessary in order to meet the needs of the OpenJDK Community. Please send questions or comments about this Notice to Sun Microsystems at openjdk-tm at sun.com. Revisions to this notice will be announced on the public mailing list announce at openjdk.java.net, to which you may subscribe by visiting http://mail.openjdk.java.net. From wimmer at ssw.jku.at Fri Mar 21 22:33:51 2008 From: wimmer at ssw.jku.at (Christian Wimmer) Date: Fri, 21 Mar 2008 23:33:51 +0100 Subject: JNI-performance - Is it really that fast? In-Reply-To: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> References: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> Message-ID: <00af01c88ba3$a3da9340$26914e8c@bianca> Hi > I thought JDK6 has BiasedLocking (I only tested single > threaded), why is synchronization so expensive in this case? > (my call-graph is benchmark-loop -> (synchronized) > accessor-method -> native-method). If you have a short-running benchmark, the following could be the reason: Biased locking is enabled 4 seconds after startup. Addtionally, objects that are allocated in the first 4 seconds stay unbiasable for their entire lifetime. The flag -XX:BiasedLockingStartupDelay=0 can be used to enable biased locking immediately at startup. Christian From wieczyk at gmail.com Mon Mar 24 21:46:27 2008 From: wieczyk at gmail.com (=?ISO-8859-2?Q?Pawe=B3_Wieczorek?=) Date: Mon, 24 Mar 2008 21:46:27 +0000 Subject: Hi Message-ID: <1255bf0d0803241446x70fb297at9d0a7d020a17b728@mail.gmail.com> Hi I am studying now a Object Oriented Programming and at end of semester I will need to choose C# or Java and write some not-small project. In connection to this I am collecting some information about runtime of this languages. I am using a Free/NetBSD as my primary development platform. It is possible to download some Java x86 packages for those platforms. But when I want to compile my own JDK it is a bit harder, to build JDK it is needed to have older version of JDK - why ? Mono doesn't need any .NET installed on system to build. Is it possible to change this strategy in future to do build-process more friendly for not Solaris/Windows/Linux ?. In packages for BSD platforms I can see that it is a Sun JDK with some patches. Do you have plans to port original JDK (in OpenJDK project) to other platform than Solaris/Windows/Linux ? If you will have that project in some near future I will be interested to help. Best regards Pawe? Wieczorek From Dmitri.Trembovetski at Sun.COM Mon Mar 24 22:33:33 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Mon, 24 Mar 2008 15:33:33 -0700 Subject: JNI-performance - Is it really that fast? In-Reply-To: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> References: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> Message-ID: <47E82C3D.3030106@Sun.COM> Some members of the Java2D team would incline to respectfully disagree with the assessment that JNI is "that" fast =) Jim Graham wrote an extensive JNI benchmark (which tests method calls with different types/number of arguments, Get/Set methods, GetPACritical, etc), and ran it against multiple Java releases. We have an internal page with the results. Unfortunately we don't have the bandwidth to get the benchmark out. The net result is that while the jni performance had improved over the years (the amount of improvement varies from platform to platform) it is still not satisfactory in many areas. Our per primitive cost is still mostly consists of jni overhead for small primitives (think fillRect(1x1)). Thanks, Dmitri Java2D Team Clemens Eisserer wrote: > Hello, > > I did some benchmarks to evaluate JNI-call-per-operation vs. > Command-batch-buffer performance for a design where low per-primitive > overhead is important. > > I was totally impressed about the low overhead JNI has in modern > SUN-JVMs. On my Core2Duo-2ghz it took only 35cycles to call a native > method with 4 jint parameters and count an int-loop-counter up, 58mio > times per second. Making the methods synchronized however time went up > to 100 cycles per call. > > Has JNI really become that fast, or is it likely that I have hit a > microbenchmark trap? > I thought JDK6 has BiasedLocking (I only tested single threaded), why > is synchronization so expensive in this case? (my call-graph is > benchmark-loop -> (synchronized) accessor-method -> native-method). > > Thanks, lg Clemens From aph at redhat.com Tue Mar 25 10:40:12 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 Mar 2008 10:40:12 +0000 Subject: Hi In-Reply-To: <1255bf0d0803241446x70fb297at9d0a7d020a17b728@mail.gmail.com> References: <1255bf0d0803241446x70fb297at9d0a7d020a17b728@mail.gmail.com> Message-ID: <47E8D68C.4090607@redhat.com> Pawe? Wieczorek wrote: > I am studying now a Object Oriented Programming and at end of > semester I will need to choose C# or Java and write some not-small > project. In connection to this I am collecting some information about > runtime of this languages. > > I am using a Free/NetBSD as my primary development platform. It is > possible to download some Java x86 packages for those platforms. > But when I want to compile my own JDK it is a bit harder, to build JDK > it is needed to have older version of JDK - why ? It's written in Java. gcc needs a C compiler to build it. I'm surprised at how often this question arises. > Mono doesn't need > any .NET installed on system to build. > > Is it possible to change this strategy in future to do build-process > more friendly for not Solaris/Windows/Linux ?. > In packages for BSD platforms I can see that it is a Sun JDK with > some patches. Do you have plans to port original JDK (in OpenJDK > project) to other platform than Solaris/Windows/Linux ? If you will > have that project in some near future I will be interested to help. See http://landonf.bikemonkey.org/static/soylatte/ "SoyLatte is a functional, X11-based port of the FreeBSD Java 1.6 patchset to Mac OS X Intel machines." Andrew. From pdoubleya at gmail.com Tue Mar 25 11:00:54 2008 From: pdoubleya at gmail.com (Patrick Wright) Date: Tue, 25 Mar 2008 12:00:54 +0100 Subject: Hi In-Reply-To: <1255bf0d0803241446x70fb297at9d0a7d020a17b728@mail.gmail.com> References: <1255bf0d0803241446x70fb297at9d0a7d020a17b728@mail.gmail.com> Message-ID: <64efa1ba0803250400x295b458s1fa0626b4874aee5@mail.gmail.com> Hi Pawel > In packages for BSD platforms I can see that it is a Sun JDK with > some patches. Do you have plans to port original JDK (in OpenJDK > project) to other platform than Solaris/Windows/Linux ? If you will > have that project in some near future I will be interested to help. See the OpenJDK Porters group and mailing lists: http://openjdk.java.net/groups/porters/, as they are trying to coordinate effort for porting to different systems. HTH Patrick From Steve.Goldman at Sun.COM Tue Mar 25 13:30:02 2008 From: Steve.Goldman at Sun.COM (steve goldman) Date: Tue, 25 Mar 2008 09:30:02 -0400 Subject: JNI-performance - Is it really that fast? In-Reply-To: <47E82C3D.3030106@Sun.COM> References: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> <47E82C3D.3030106@Sun.COM> Message-ID: <47E8FE5A.5020605@sun.com> Dmitri Trembovetski wrote: > > Some members of the Java2D team would incline to > respectfully disagree with the assessment that JNI is > "that" fast =) I was really enjoying this thread even though I knew that someone from J2D was going to burst the bubble. :-) > > Jim Graham wrote an extensive JNI benchmark (which tests method calls > with different types/number of arguments, Get/Set methods, > GetPACritical, etc), and ran it against multiple Java releases. > > We have an internal page with the results. Unfortunately we don't > have the bandwidth to get the benchmark out. > > The net result is that while the jni performance had improved > over the years (the amount of improvement varies > from platform to platform) it is still not satisfactory > in many areas. Our per primitive cost is still mostly > consists of jni overhead for small primitives (think > fillRect(1x1)). As a warning to people writing jni benchmarks. It is very easy to write a bad microbenchmark that tries to measure the overhead of calling a native method on sparc. Because of the register window flush we must do when we transition to native if your microbenchmark (or app for that matter) consists of a loop that repeatedly calls a jni method that does very little work (e.g. no other calls) then a large portion of the work is window flushes. I could believe there are parts of J2D that could look like that and the changes to how safepoints were done in Java 5.0 that changed the window flush strategy is painful for that type of code. The benchmarking the jvm team did showed that most code doesn't look like that and the flush was not so painful. Platforms without register windows don't suffer from this in any case. I do have some changes (which Jim has benchmarked) that improve jni performance a bit more across all the platforms and mostly remove the microbenchmark pothole on register windowed machines. At this point the changes only work for server and aren't really ready for primetime. Someday I hope to get back to them. In the meantime the people who believe jni performance is very good please continue to speak up as I'm sure the vm engineers who have worked to improve this path over the years will appreciate the feedback. :-) -- Steve From robilad at kaffe.org Tue Mar 25 15:19:41 2008 From: robilad at kaffe.org (Dalibor Topic) Date: Tue, 25 Mar 2008 16:19:41 +0100 Subject: New Project Proposal: MIPS port of OpenJDK Message-ID: <47E9180D.4030502@kaffe.org> Dear OpenJDK developers, I hereby propose, on behalf of the MIPS OpenJDK port developers, the creation of a new project to create and maintain a port of OpenJDK to the MIPS CPU architecture. For a description of the proposal, I'd like to refer you to the thread initiated by Jonathan Springer's post proposing the project on the porters-dev mailing list at [1]. cheers, dalibor topic [1] http://mail.openjdk.java.net/pipermail/porters-dev/2008-February/000090.html From mr at sun.com Tue Mar 25 15:30:05 2008 From: mr at sun.com (Mark Reinhold) Date: Tue, 25 Mar 2008 08:30:05 -0700 Subject: New Project Proposal: MIPS port of OpenJDK In-Reply-To: robilad@kaffe.org; Tue, 25 Mar 2008 16:19:41 BST; <47E9180D.4030502@kaffe.org> Message-ID: <20080325153005.3752E2BE34@callebaut.niobe.net> > Date: Tue, 25 Mar 2008 16:19:41 +0100 > From: Dalibor Topic > Subject: New Project Proposal: MIPS port of OpenJDK > To: discuss at openjdk.java.net, announce at openjdk.java.net This looks to be a fine proposal, but as a minor matter of protocol please note that proposals for new Projects (or Groups) should be sent only to announce at openjdk.java.net. Replies will be directed to discuss at openjdk.java.net automatically; there's no need to send the initial message to both lists. - Mark From linuxhippy at gmail.com Tue Mar 25 19:57:43 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 25 Mar 2008 20:57:43 +0100 Subject: JNI-performance - Is it really that fast? In-Reply-To: <47E8FE5A.5020605@sun.com> References: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> <47E82C3D.3030106@Sun.COM> <47E8FE5A.5020605@sun.com> Message-ID: <194f62550803251257w64670b87v421d9ad1c9ddf182@mail.gmail.com> Hi again, Thanks a lot for the valueable feedback :) > Biased locking is enabled 4 seconds after startup. Thanks a lot Christian and greetings from Austria! With your suggested flag the synchronization-overhead with BiasedLocking shrinks to about 10-20% on my Dual-Core machine down from a few hundred percent. Do you know wether ReentrantLock could also be optimized to use BiasedLocking? In my use-case most likely one thread will aquire/release the lock again and again, maybe from time to time another thread will aquire it, but rather seldom. > Our per primitive cost is still mostly > consists of jni overhead for small primitives (think > fillRect(1x1)). For my fillRect(1x1) test the locking of AWT's ReentrantLock was far more expensive than the JNI overhead even with almost no contention. That was for a VolatileImage, on a Dual-Core machine, on a single-core machine I tested on the hit was much smaller. > In the meantime the people who believe jni performance is very good > please continue to speak up as I'm sure the vm engineers who have > worked > to improve this path over the years will appreciate the feedback. :-) Its really impressive, congratulations and thanks to the vm engineers who made that possible :) ;) Thanks a lot, lg Clemens From Dave.Dice at Sun.COM Tue Mar 25 22:18:26 2008 From: Dave.Dice at Sun.COM (Dave Dice) Date: Tue, 25 Mar 2008 18:18:26 -0400 Subject: JNI-performance - Is it really that fast? In-Reply-To: <194f62550803251257w64670b87v421d9ad1c9ddf182@mail.gmail.com> References: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> <47E82C3D.3030106@Sun.COM> <47E8FE5A.5020605@sun.com> <194f62550803251257w64670b87v421d9ad1c9ddf182@mail.gmail.com> Message-ID: <630E75D1-5EAF-4669-AFD6-6C8CAFE20799@sun.com> > >> Biased locking is enabled 4 seconds after startup. > Thanks a lot Christian and greetings from Austria! > With your suggested flag the synchronization-overhead with > BiasedLocking shrinks to about 10-20% on my Dual-Core machine down > from a few hundred percent. > Do you know wether ReentrantLock could also be optimized to use > BiasedLocking? In my use-case most likely one thread will > aquire/release the lock again and again, maybe from time to time > another thread will aquire it, but rather seldom. In theory biased locking could be applied to the j.u.c lock family, but we have no current plans to do so. I've discussed it with Doug Lea and neither of us feel it's a good fit. The j.u.c operators are a good choice when "synchronized" doesn't fit the bill, such as when you might need timed waits, trylock, hand-over-hand "coupled" locking, etc. ReentrantLock also tends to be used in situations where the programmer is sure multiple threads are actively coordinating their operation, meaning that ReentrantLock would benefit little from biased locking. For most synchronization -- contended or uncontended -- you're better off with synchronized as you get the benefits of biased locking, adaptive spinning, potential lock elision via escape analysis, and in the future, hardware transactional lock elision (http://blogs.sun.com/dave/entry/rock_style_transactional_memory_lock ). In your case if the lock is ever shared -- that is, locked by multiple threads during its lifetime -- then biased locking probably won't provide the latency reduction benefit you're after. The object will likely become unbiased at some point. I suspect that sharing will ultimately occur in your case, but be infrequent, correct? Regards Dave p.s., even if a JVM were to use aggressive static escape analysis there'll still be lots of cases in common usage where the JIT can't conservatively prove non-escape. And of course it turn it won't be able to elide the lock. Biased locking works well in those cases. In a sense we can bet against the object ever being shared, but if wrong the JVM can detect and recover safely making it a nice dynamic adjunct to static analysis. This is important as we see lots of "precautionary" locking in the standard libraries such as hashtable or vector. It's often the case that a coarsely-synchronized collection instance will be accessed by only one thread. > > >> Our per primitive cost is still mostly >> consists of jni overhead for small primitives (think >> fillRect(1x1)). > For my fillRect(1x1) test the locking of AWT's ReentrantLock was far > more expensive than the JNI overhead even with almost no contention. > That was for a VolatileImage, on a Dual-Core machine, on a single-core > machine I tested on the hit was much smaller. > >> In the meantime the people who believe jni performance is very good >> please continue to speak up as I'm sure the vm engineers who have >> worked >> to improve this path over the years will appreciate the feedback. :-) > Its really impressive, congratulations and thanks to the vm engineers > who made that possible :) ;) > > Thanks a lot, lg Clemens From David.Herron at Sun.COM Tue Mar 25 22:54:52 2008 From: David.Herron at Sun.COM (David Herron) Date: Tue, 25 Mar 2008 15:54:52 -0700 Subject: [Fwd: DLJ bundles for 5.0u15 AND for 6u5 have been published...Re: DLJ bundles for Java 6u5 have been published] Message-ID: <47E982BC.6060106@sun.com> FYI, the DLJ bundles for 5.0u15 and 6u5 have been published. -------------- next part -------------- An embedded message was scrubbed... From: David Herron Subject: DLJ bundles for 5.0u15 AND for 6u5 have been published...Re: DLJ bundles for Java 6u5 have been published Date: Tue, 25 Mar 2008 15:43:13 -0700 Size: 912 URL: From linuxhippy at gmail.com Tue Mar 25 23:13:27 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 26 Mar 2008 00:13:27 +0100 Subject: JNI-performance - Is it really that fast? In-Reply-To: <630E75D1-5EAF-4669-AFD6-6C8CAFE20799@sun.com> References: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> <47E82C3D.3030106@Sun.COM> <47E8FE5A.5020605@sun.com> <194f62550803251257w64670b87v421d9ad1c9ddf182@mail.gmail.com> <630E75D1-5EAF-4669-AFD6-6C8CAFE20799@sun.com> Message-ID: <194f62550803251613o1f67e801y9818c8cd722784dc@mail.gmail.com> Hi Dave, Thanks a lot for answering that detailed. Congratulations to the BiasedLocking work, its really great to see such inovative features in the JVM :) > good choice when "synchronized" doesn't fit the bill, such as when you > might need timed waits, trylock, hand-over-hand "coupled" locking, > etc. ReentrantLock also tends to be used in situations where the > programmer is sure multiple threads are actively coordinating their > operation, meaning that ReentrantLock would benefit little from biased > locking. For most synchronization -- contended or uncontended -- > you're better off with synchronized as you get the benefits of biased > locking, adaptive spinning, potential lock elision via escape > analysis, and in the future, hardware transactional lock elision (http://blogs.sun.com/dave/entry/rock_style_transactional_memory_lock > ). I was asking because I did some benchmarking and (on my dual-core machine, with an obscure microbenchmark) the grabbing the AWTLock for a 1x1 rectangle takes almost as much time as the whole Xlib-processing + JNI-overhead. The code looks like: SunToolkit.awtLock(); long xgc = validate(sg2d); //simple, pure Java method XFillRect(sg2d.surfaceData.getNativeOps(), .....); // native method SunToolkit.awtUnlock(); 10mio 1x1 rect: 600ms native method commented out 850ms locking commented out. 1400ms locking+native method The numbers include all the code-path from Graphics.fillRect() up to X11Renderer.fillRetc. As you can see locking (at least on my machine) is almost as expensive as the JNI-Downcall and the real work together. I used the server-compiler. The AWTLock was a java-monitor till JDK5 (not 100% sure), but was a victim of contention because it was used also from native code and sometimes from multiple threads (but I guess it was not heavy contended in most cases). IN JDK6 it was replaced with a ReentrantLock, some features like tryLock() where used to implement the new OpenGL pipeline ... performance also improved. > In your case if the lock is ever shared -- that is, locked by multiple > threads during its lifetime -- then biased locking probably won't > provide the latency reduction benefit you're after. The object will > likely become unbiased at some point. I suspect that sharing will > ultimately occur in your case, but be infrequent, correct? Exactly, the most likely scenary is that there is one rendering-thread which does million of locks, and a few other calls from native code (currently they upcall from C to lock the ReentrantLock). It could also happen that there are two or more active rendering threads at the same time, but this is not really common and a fallback to unbiased would be totally ok. Wouldn't be a BiasedLock something worth to implement, maybe with the possibility how fast/likely the Lock can become unbiased? However this really has not a lot prioritry to me ... I really should care about other things ... somehow I entraped into this when deciding the design of my XRender-Java2d pipeline. Sorry for all the traffic... lg Clemens From Dave.Dice at Sun.COM Tue Mar 25 23:22:40 2008 From: Dave.Dice at Sun.COM (Dave Dice) Date: Tue, 25 Mar 2008 19:22:40 -0400 Subject: JNI-performance - Is it really that fast? In-Reply-To: <194f62550803251613o1f67e801y9818c8cd722784dc@mail.gmail.com> References: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> <47E82C3D.3030106@Sun.COM> <47E8FE5A.5020605@sun.com> <194f62550803251257w64670b87v421d9ad1c9ddf182@mail.gmail.com> <630E75D1-5EAF-4669-AFD6-6C8CAFE20799@sun.com> <194f62550803251613o1f67e801y9818c8cd722784dc@mail.gmail.com> Message-ID: <6AA2A6F6-052D-4397-A49F-4F86FEA3487E@sun.com> On 2008-3-25, at 7:13 PM, Clemens Eisserer wrote: > Hi Dave, > > Thanks a lot for answering that detailed. Congratulations to the > BiasedLocking work, its really great to see such inovative features in > the JVM :) Mark Moir, Bill Scherer and I wrote something about it early on. Ken Russell and Dave Detlefs are responsible for the current implementation. You can find a link to their oopsla paper via http://blogs.sun.com/dave/entry/biased_locking_in_hotspot . Dave > > >> good choice when "synchronized" doesn't fit the bill, such as when >> you >> might need timed waits, trylock, hand-over-hand "coupled" locking, >> etc. ReentrantLock also tends to be used in situations where the >> programmer is sure multiple threads are actively coordinating their >> operation, meaning that ReentrantLock would benefit little from >> biased >> locking. For most synchronization -- contended or uncontended -- >> you're better off with synchronized as you get the benefits of biased >> locking, adaptive spinning, potential lock elision via escape >> analysis, and in the future, hardware transactional lock elision (http://blogs.sun.com/dave/entry/rock_style_transactional_memory_lock >> ). > > I was asking because I did some benchmarking and (on my dual-core > machine, with an obscure microbenchmark) the grabbing the AWTLock for > a 1x1 rectangle takes almost as much time as the whole Xlib-processing > + JNI-overhead. > > The code looks like: > SunToolkit.awtLock(); > long xgc = validate(sg2d); //simple, pure Java method > XFillRect(sg2d.surfaceData.getNativeOps(), .....); // native method > SunToolkit.awtUnlock(); > > 10mio 1x1 rect: > 600ms native method commented out > 850ms locking commented out. > 1400ms locking+native method > > The numbers include all the code-path from Graphics.fillRect() up to > X11Renderer.fillRetc. > > As you can see locking (at least on my machine) is almost as expensive > as the JNI-Downcall and the real work together. I used the > server-compiler. > > The AWTLock was a java-monitor till JDK5 (not 100% sure), but was a > victim of contention because it was used also from native code and > sometimes from multiple threads (but I guess it was not heavy > contended in most cases). > IN JDK6 it was replaced with a ReentrantLock, some features like > tryLock() where used to implement the new OpenGL pipeline ... > performance also improved. > >> In your case if the lock is ever shared -- that is, locked by >> multiple >> threads during its lifetime -- then biased locking probably won't >> provide the latency reduction benefit you're after. The object will >> likely become unbiased at some point. I suspect that sharing will >> ultimately occur in your case, but be infrequent, correct? > > Exactly, the most likely scenary is that there is one rendering-thread > which does million of locks, and a few other calls from native code > (currently they upcall from C to lock the ReentrantLock). > It could also happen that there are two or more active rendering > threads at the same time, but this is not really common and a fallback > to unbiased would be totally ok. > Wouldn't be a BiasedLock something worth to implement, maybe with the > possibility how fast/likely the Lock can become unbiased? > > However this really has not a lot prioritry to me ... I really should > care about other things ... somehow I entraped into this when deciding > the design of my XRender-Java2d pipeline. Sorry for all the traffic... > > lg Clemens From Dave.Dice at Sun.COM Wed Mar 26 03:26:40 2008 From: Dave.Dice at Sun.COM (Dave Dice) Date: Tue, 25 Mar 2008 23:26:40 -0400 Subject: JNI-performance - Is it really that fast? In-Reply-To: <194f62550803251613o1f67e801y9818c8cd722784dc@mail.gmail.com> References: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> <47E82C3D.3030106@Sun.COM> <47E8FE5A.5020605@sun.com> <194f62550803251257w64670b87v421d9ad1c9ddf182@mail.gmail.com> <630E75D1-5EAF-4669-AFD6-6C8CAFE20799@sun.com> <194f62550803251613o1f67e801y9818c8cd722784dc@mail.gmail.com> Message-ID: <7A5D8793-3B37-42D0-9B03-7F7AB49FB1FF@sun.com> > Following up on the other part of the your email ... > I was asking because I did some benchmarking and (on my dual-core > machine, with an obscure microbenchmark) the grabbing the AWTLock for > a 1x1 rectangle takes almost as much time as the whole Xlib-processing > + JNI-overhead. > > The code looks like: > SunToolkit.awtLock(); > long xgc = validate(sg2d); //simple, pure Java method > XFillRect(sg2d.surfaceData.getNativeOps(), .....); // native method > SunToolkit.awtUnlock(); > > 10mio 1x1 rect: > 600ms native method commented out > 850ms locking commented out. > 1400ms locking+native method > > The numbers include all the code-path from Graphics.fillRect() up to > X11Renderer.fillRetc. > > As you can see locking (at least on my machine) is almost as expensive > as the JNI-Downcall and the real work together. I used the > server-compiler. > > The AWTLock was a java-monitor till JDK5 (not 100% sure), but was a > victim of contention because it was used also from native code and > sometimes from multiple threads (but I guess it was not heavy > contended in most cases). > IN JDK6 it was replaced with a ReentrantLock, some features like > tryLock() where used to implement the new OpenGL pipeline ... > performance also improved. I recall discussions with the 2d folks on that topic. > > >> In your case if the lock is ever shared -- that is, locked by >> multiple >> threads during its lifetime -- then biased locking probably won't >> provide the latency reduction benefit you're after. The object will >> likely become unbiased at some point. I suspect that sharing will >> ultimately occur in your case, but be infrequent, correct? > > Exactly, the most likely scenary is that there is one rendering-thread > which does million of locks, and a few other calls from native code > (currently they upcall from C to lock the ReentrantLock). > It could also happen that there are two or more active rendering > threads at the same time, but this is not really common and a fallback > to unbiased would be totally ok. > Wouldn't be a BiasedLock something worth to implement, maybe with the > possibility how fast/likely the Lock can become unbiased? Unbiasing a lock, or more properly revoking its bias, can be exceptionally expensive. In the extreme case it might require a full stop-the-world thread rendezvous to ensure there are no races between the revoking thread and the bias holding thread. (Ken's oopsla paper describes some ways to mitigate that cost). While it's not strictly fundamental to biased locking, the mechanism today also makes good use of the fact that we know that synchronization -- enter and exit operations -- are typically balanced ("last locked is first unlocked") allowing the JVM to hide additional locking information on the stack. A BiasedLock in the vein of ReentrantLock wouldn't have that property, making the implementation a bit more complicated. Generally, though, BiasedLock seems like a bet in the wrong direction. If you suspect that biased locking would be a win then for the most part you'd be better off with synchronized instead of yet another special construct. (I worry too that things like BiasedLock don't necessarily age well. Biased locking is purely a response to processor-local CAS/cmpxchg latency. As processor vendors have turned their attention to the issue the latency has shown relative improvement so today's good idea might be tomorrow's legacy baggage that needs to be towed around in perpetuity). Regards Dave > > > However this really has not a lot prioritry to me ... I really should > care about other things ... somehow I entraped into this when deciding > the design of my XRender-Java2d pipeline. Sorry for all the traffic... > > lg Clemens From linuxhippy at gmail.com Wed Mar 26 20:16:37 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 26 Mar 2008 21:16:37 +0100 Subject: JNI-performance - Is it really that fast? In-Reply-To: <7A5D8793-3B37-42D0-9B03-7F7AB49FB1FF@sun.com> References: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> <47E82C3D.3030106@Sun.COM> <47E8FE5A.5020605@sun.com> <194f62550803251257w64670b87v421d9ad1c9ddf182@mail.gmail.com> <630E75D1-5EAF-4669-AFD6-6C8CAFE20799@sun.com> <194f62550803251613o1f67e801y9818c8cd722784dc@mail.gmail.com> <7A5D8793-3B37-42D0-9B03-7F7AB49FB1FF@sun.com> Message-ID: <194f62550803261316j1890743es2097bacc29a642fa@mail.gmail.com> Hi Dave, Thanks for mentioning the blog, I already knew it but to be honest not everything was 100% clear for me ;) > Unbiasing a lock, or more properly revoking its bias, can be > exceptionally expensive. In the extreme case it might require a full > stop-the-world thread rendezvous to ensure there are no races between > the revoking thread and the bias holding thread. (Ken's oopsla paper > describes some ways to mitigate that cost). Well, ok, a stop-the-world thing "just" to revoke the bias would be really expensive ... not sure if it would be a win even under optimal conditions for this use. > If you suspect that biased locking would be a win then > for the most part you'd be better off with synchronized instead of yet > another special construct. (I worry too that things like BiasedLock > don't necessarily age well. Biased locking is purely a response to > processor-local CAS/cmpxchg latency. As processor vendors have turned > their attention to the issue the latency has shown relative > improvement so today's good idea might be tomorrow's legacy baggage > that needs to be towed around in perpetuity). Well thats an argument I not really thought of and you're right of course. Most likely the situations where this could be a win are seldom, and a lot of work would be needed to implement and maintain it. But don't you think the situation will only get worse the more cores the current "design" is stretched to? Lets just hope the situation will improve :) Thanks a lot for listening and explaining everything that detailed, lg Clemens PS: I did some micro-benchmarking again on my machine again for a JNI-call: 180ms - jni per call, no locking 240ms - command-buffer(32k), locked JNI call every 1600 calls, native-side buffer interpreter (a switch statement) 629ms - jni per call, locked locking was done with a ReentrantLock. So the command-buffering and interpreting semms to pay off, although on my machine its still slower than a un-locked JNI call. From Dave.Dice at Sun.COM Wed Mar 26 21:02:35 2008 From: Dave.Dice at Sun.COM (Dave Dice) Date: Wed, 26 Mar 2008 17:02:35 -0400 Subject: JNI-performance - Is it really that fast? In-Reply-To: <194f62550803261316j1890743es2097bacc29a642fa@mail.gmail.com> References: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> <47E82C3D.3030106@Sun.COM> <47E8FE5A.5020605@sun.com> <194f62550803251257w64670b87v421d9ad1c9ddf182@mail.gmail.com> <630E75D1-5EAF-4669-AFD6-6C8CAFE20799@sun.com> <194f62550803251613o1f67e801y9818c8cd722784dc@mail.gmail.com> <7A5D8793-3B37-42D0-9B03-7F7AB49FB1FF@sun.com> <194f62550803261316j1890743es2097bacc29a642fa@mail.gmail.com> Message-ID: >> > Well, ok, a stop-the-world thing "just" to revoke the bias would be > really expensive ... not sure if it would be a win even under optimal > conditions for this use. It speaks to how (relatively) expensive those atomics are that biased locking is profitable even though we might have to occasionally perform revocation via stop-the-world safepoints. <...> >> > Well thats an argument I not really thought of and you're right of > course. > Most likely the situations where this could be a win are seldom, and a > lot of work would be needed to implement and maintain it. > But don't you think the situation will only get worse the more cores > the current "design" is stretched to? > Lets just hope the situation will improve :) The atomics proper shouldn't be any more expensive on a 256-way than on a 2-way. For the most part they're accomplished locally in the cache. (There was a time when atomics "locked the bus" and impeded scalability, but that hasn't been true for many years). Conceptually a compare-and-swap (CAS) or other atomic shouldn't have any more impact on the system than a store. And in fact there was a rough relationship between pipeline depth and CAS latency, as most CPUs implemented CAS by draining the pipeline, allowing the store buffer to drain, and otherwise letting the processor quiesce, as well as killing out-of-order execution. Those are CPU-local effects. Furthermore they're largely an implementation artifact as until recently processor designers didn't pay too much attention to atomic latency. Thankfully that appears to be changing and we're seeing more efficient atomics. > > > Thanks a lot for listening and explaining everything that detailed, > lg Clemens > > PS: > I did some micro-benchmarking again on my machine again for a JNI- > call: > 180ms - jni per call, no locking > 240ms - command-buffer(32k), locked JNI call every 1600 calls, > native-side buffer interpreter (a switch statement) > 629ms - jni per call, locked > locking was done with a ReentrantLock. > > So the command-buffering and interpreting semms to pay off, although > on my machine its still slower than a un-locked JNI call. If I'm interpreting the data correctly, that doesn't seem too surprising. There was a sufficiently long warmup period, and the warmup exercised the code in precisely the same way it would execute during the benchmark interval? Regards Dave From linuxhippy at gmail.com Wed Mar 26 22:21:01 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 26 Mar 2008 23:21:01 +0100 Subject: JNI-performance - Is it really that fast? In-Reply-To: References: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> <47E82C3D.3030106@Sun.COM> <47E8FE5A.5020605@sun.com> <194f62550803251257w64670b87v421d9ad1c9ddf182@mail.gmail.com> <630E75D1-5EAF-4669-AFD6-6C8CAFE20799@sun.com> <194f62550803251613o1f67e801y9818c8cd722784dc@mail.gmail.com> <7A5D8793-3B37-42D0-9B03-7F7AB49FB1FF@sun.com> <194f62550803261316j1890743es2097bacc29a642fa@mail.gmail.com> Message-ID: <194f62550803261521m15375f96y4b4b1fdb7262212a@mail.gmail.com> Hello, > The atomics proper shouldn't be any more expensive on a 256-way than > on a 2-way .... Those are CPU-local effects. Furthermore > they're largely an implementation artifact as until recently processor > designers didn't pay too much attention to atomic latency. Thankfully > that appears to be changing and we're seeing more efficient atomics. Good to know, thanks for explaining. I don't want to steal your time, but, if its only a local thing why is my old pentium4 so much faster than my core2duo when it comes to cmpxchg? Sorry for asking that much... > If I'm interpreting the data correctly, that doesn't seem too > surprising. There was a sufficiently long warmup period, and the > warmup exercised the code in precisely the same way it would execute > during the benchmark interval? Yes, exactly. On my Pentium4 the buffering is even faster, because JNI is really slow on it. Thanks for your time and patience, lg Clemens From Dave.Dice at Sun.COM Wed Mar 26 23:20:48 2008 From: Dave.Dice at Sun.COM (Dave Dice) Date: Wed, 26 Mar 2008 19:20:48 -0400 Subject: JNI-performance - Is it really that fast? In-Reply-To: <194f62550803261521m15375f96y4b4b1fdb7262212a@mail.gmail.com> References: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> <47E82C3D.3030106@Sun.COM> <47E8FE5A.5020605@sun.com> <194f62550803251257w64670b87v421d9ad1c9ddf182@mail.gmail.com> <630E75D1-5EAF-4669-AFD6-6C8CAFE20799@sun.com> <194f62550803251613o1f67e801y9818c8cd722784dc@mail.gmail.com> <7A5D8793-3B37-42D0-9B03-7F7AB49FB1FF@sun.com> <194f62550803261316j1890743es2097bacc29a642fa@mail.gmail.com> <194f62550803261521m15375f96y4b4b1fdb7262212a@mail.gmail.com> Message-ID: > Good to know, thanks for explaining. > I don't want to steal your time, but, if its only a local thing why is > my old pentium4 so much faster than my core2duo when it comes to > cmpxchg? > Sorry for asking that much... No problem at all (:>). Is your pentium4 a uniprocessor? On uniprocessors HotSpot elides the lock: prefix when emitting the Intel cmpxchg (CAS) instruction. The lock prefix forces the cmpxchg to be serializing and greatly increases the latency but that's unnecessary on uniprocessors as they're always self-consistent. (Even multiple threads on a uniprocessor are always self-consistent with respect to the memory model). Regards Dave From linuxhippy at gmail.com Wed Mar 26 23:46:23 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 27 Mar 2008 00:46:23 +0100 Subject: JNI-performance - Is it really that fast? In-Reply-To: References: <194f62550803210525q64f47512p293d3227583ce2d6@mail.gmail.com> <47E8FE5A.5020605@sun.com> <194f62550803251257w64670b87v421d9ad1c9ddf182@mail.gmail.com> <630E75D1-5EAF-4669-AFD6-6C8CAFE20799@sun.com> <194f62550803251613o1f67e801y9818c8cd722784dc@mail.gmail.com> <7A5D8793-3B37-42D0-9B03-7F7AB49FB1FF@sun.com> <194f62550803261316j1890743es2097bacc29a642fa@mail.gmail.com> <194f62550803261521m15375f96y4b4b1fdb7262212a@mail.gmail.com> Message-ID: <194f62550803261646u79df6707j4f1aa70de835861c@mail.gmail.com> > No problem at all (:>). > > Is your pentium4 a uniprocessor? On uniprocessors HotSpot elides the > lock: prefix when emitting the Intel cmpxchg (CAS) instruction. The > lock prefix forces the cmpxchg to be serializing and greatly increases > the latency but that's unnecessary on uniprocessors as they're always > self-consistent. (Even multiple threads on a uniprocessor are always > self-consistent with respect to the memory model). Exactly, its a uniprocessor. Thanks a lot for clarification and for your patience, suggestions and comments :) lg Clemens From dalibor.topic at googlemail.com Thu Mar 27 19:05:39 2008 From: dalibor.topic at googlemail.com (Dalibor Topic) Date: Thu, 27 Mar 2008 20:05:39 +0100 Subject: Request for comments: OpenJDK Trademark Notice In-Reply-To: <20080321214225.4B7B65B656@eggemoggin.niobe.net> References: <20080321214225.4B7B65B656@eggemoggin.niobe.net> Message-ID: <47EBF003.50705@kaffe.org> Mark Reinhold schrieb: > Now "OpenJDK" is a trademark of Sun Microsystems, so we had to come up > with a way to grant permission for these types of uses. Working with > Sun's trademark counsel we drafted the OpenJDK Trademark Notice and > published the first version in the b06 source bundle, in the TRADEMARK > file at the root of the tree. Based on early feedback from Andrew Haley, > Dalibor Topic, Mark Wielaard, and others, we revised it slightly and > published v1.1 [4] in b07, which shipped yesterday [5]. > Hi Mark, I'm happy to see that the feedback I've seen for v1.1 has been incorporated into v 1.2. I believe this version should work fine for the distribution/ports/packages use cases I can come up with atm. For all the cases I can't come up with, it's good to see that there is an upgrade path built into the license. cheers, dalibor topic From Richard.Sands at Sun.COM Mon Mar 31 20:56:40 2008 From: Richard.Sands at Sun.COM (Rich Sands) Date: Mon, 31 Mar 2008 16:56:40 -0400 Subject: Any IcedTea developers going to FISL in Brazil? Message-ID: <47F15008.2040900@sun.com> Just curious - Ray and I will be giving talks there and if any IcedTea folks will be going, we'd like to invite you to join us for part of our presentations. We'll be talking about OpenJDK update, and OpenJDK in Linux distros. Thanks, -- rms -- Rich Sands Phone: +1 781 881 4067 / x81524 Community Marketing Manager Email: richard.sands at sun.com Java SE Marketing SMS: 6172830027 at vtext.com Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~