Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v12]

On Mon, 14 Mar 2022 19:12:29 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on >> int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single >> element >> - minor javad

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v12]

On Mon, 14 Mar 2022 19:12:29 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on >> int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single >> element >> - minor javad

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v12]

On Fri, 13 May 2022 17:48:50 GMT, Piotr Tarsa wrote: > allocating extra buffers and catching OOME when sorting primitives is rather > unsatisfactory. you're not giving a reliable option for sorting under low > memory conditions. IMO at least the single-threaded primitives (ints, longs, > float

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v12]

On Mon, 14 Mar 2022 19:12:29 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on >> int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single >> element >> - minor javad

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v10]

On Mon, 29 Nov 2021 21:16:32 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on >> int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single >> element >> - minor javad

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v10]

On Mon, 29 Nov 2021 21:16:32 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on >> int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single >> element >> - minor javad

Re: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13]

On Mon, 6 Dec 2021 07:07:03 GMT, Markus KARG wrote: >> Markus KARG has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Draft: Eliminated duplicate code using lambda expressions >> - Draft: Use blocking mode also for target channel > > Ple

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v9]

On Mon, 15 Nov 2021 16:20:07 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on >> int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single >> element >> - minor javad

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v9]

On Mon, 15 Nov 2021 16:20:07 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on >> int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single >> element >> - minor javad

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v9]

On Mon, 15 Nov 2021 16:20:07 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on >> int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single >> element >> - minor javad

Re: RFR: JDK-8277095 : Empty streams create too many objects

On Fri, 5 Nov 2021 12:53:46 GMT, kabutz wrote: > This is a draft proposal for how we could improve stream performance for the > case where the streams are empty. Empty collections are common-place. If we > iterate over them with an Iterator, we would have to create one small > Iterator object

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v6]

On Wed, 6 Oct 2021 21:21:29 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on >> int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single >> element >> - minor javad

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v6]

On Wed, 6 Oct 2021 21:21:29 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on >> int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single >> element >> - minor javad

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)

On Fri, 14 May 2021 17:50:11 GMT, Piotr Tarsa wrote: >> I made a JMH test on jdk16 to test count4 (xor) performance: >> https://github.com/bourgesl/nearly-optimal-mergesort-code/tree/master/sort-bench/results/count_xor >> >> >> Benchmark (size) Mode Cnt Score Error Units >> ArrayXorBenchmark.a

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)

On Thu, 20 May 2021 21:21:26 GMT, Nils Eliasson wrote: >> A small update of the XorINodes type calculation makes the bound check go >> away. Testing now. > > That bounds check shouldn't be there, it's an obvious case and will be fixed: > https://github.com/openjdk/jdk/pull/4136 Thanks for fixi

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)

On Fri, 14 May 2021 07:41:19 GMT, Richard Startin wrote: >> Great analysis on C2, richard. >> >> maybe (x ^ 0x80) &0xFF would help C2 to eliminate bound checks... > > I don't know Laurent, I find the handling of signed order over-complicated. > Subtracting `Integer.MIN_VALUE` is really cheap..

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)

On Thu, 13 May 2021 09:53:37 GMT, Richard Startin wrote: >> Laurent, the date in this class is not the date of our last commit, >> this date is the date when I have final idea regarding to Radix sort, >> therefore, I prefer to keep 2020.06.14 > > Hi @iaroslavski I'm unconvinced that this work wa

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)

On Thu, 13 May 2021 21:44:38 GMT, Richard Startin wrote: >> For what it's worth, I benchmarked this implementation radix sort ([adapted >> here to fit in to my >> harness](https://github.com/richardstartin/radix-sort-benchmark/commit/07169e8e8602152cfda859baa159db165bf5fcab#diff-6c13d3fb74f389

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)

On Wed, 12 May 2021 12:20:09 GMT, iaroslavski wrote: >> src/java.base/share/classes/java/util/DualPivotQuicksort.java line 47: >> >>> 45: * @author Doug Lea >>> 46: * >>> 47: * @version 2020.06.14 >> >> Vladimir, I would update to 2021.05.06 (+your hash) > > Laurent, the date in this class

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)

On Sat, 8 May 2021 20:54:48 GMT, iaroslavski wrote: > Sorting: > > - adopt radix sort for sequential and parallel sorts on int/long/float/double > arrays (almost random and length > 6K) > - fix tryMergeRuns() to better handle case when the last run is a single > element > - minor javadoc and

Re: How to know if cpu supports unaligned memory accesses ?

(edges, rle tile cache). Cheers, Laurent Le dim. 18 avr. 2021 à 09:11, Alan Bateman a écrit : > > On 17/04/2021 19:02, Laurent Bourgès wrote: > > Hi, > > In the Marlin renderer & in other Unsafe use cases (pixel tile > processing) > > for java2d pipelines, I do use put

How to know if cpu supports unaligned memory accesses ?

Hi, In the Marlin renderer & in other Unsafe use cases (pixel tile processing) for java2d pipelines, I do use putInt()/putLong() primitives even if the address is not aligned (to 4 or 8 bytes) to get faster processing of byte buffer or arrays... Is it possible in java (jdk internals) to query cpu

Re: 8252827: Caching Integer.toString just like Integer.valueOf

Hi, I read the JBS bug and I interpret it as: - IntegerCache provides Integer instances for [-128, 127] by default - Having Integer.toString(int) could behave the same or at least cache most probable values like [-1 to 16] or using the IntegerCache range. It looks trivial and potentially could be

Re: RFR(S): 8242848: Improve performance of InflaterOutputStream.write()

Thank you Volker for sharing your results. It is amazing, to improve such widely used feature (zip -> jar, http compression...) Congratulations. Laurent Le jeu. 23 avr. 2020 à 12:19, Volker Simonis a écrit : > On Thu, Apr 23, 2020 at 10:56 AM Laurent Bourgès > wrote: > >

Re: RFR(S): 8242848: Improve performance of InflaterOutputStream.write()

Hi Volker, Could you give some benchmark results in the jbs bug to have an idea of the performance gain ? Thanks, Laurent Le jeu. 23 avr. 2020 à 10:20, Langer, Christoph a écrit : > Hi Volker, > > since it's not yet pushed, I also went over the change and I like it. +1 😊 > > One little style n

Re: RFR: 8226297: Dual-pivot quicksort improvements

nd re-generate your patch. I don't know > if > > that would be less work than just comparing raw files. > > > > Alternatively, if it would be easiest for those familiar with the > > evolution of this fix to leave things where Vladimir had them, I can >

Re: RFR: 8226297: Dual-pivot quicksort improvements

Hi Brent, Thank you for sponsoring this patch. I tried to compare your webrev against my latest (diff patch files) but it gives me too many changes lines. Do you have another idea to see incremental changes only ? (anyway I can compare raw files) Thanks, Laurent Le lun. 5 août 2019 à 23:43, Br

Re: The final optimized version of Dual-Pivot Quicksort (ver.19.1)

Hi Brent, Le jeu. 1 août 2019 à 02:32, Brent Christian a écrit : > Thanks, Laurent. I can sponsor this fix, get a RFR thread going for > JDK-8226297, keep webrevs updated as the review progresses, etc. > Excellent, I will let you and Vladimir work on this review. FYI I have implemented DPQS (

Re: The final optimized version of Dual-Pivot Quicksort (ver.19.1)

shold for parallelism argument (0 -> 1) 2. Added constant for common parallelism 3. Updated byte / char / short counting sort. " Incremental patch change: http://cr.openjdk.java.net/~lbourges/dpqs/dpqs-8226297/diff_dpqs_1_vs_0.log Cheers, Laurent Le mer. 17 juil. 2019 à 17:12, Laurent Bou

Re: Benchmarking of new optimized Dual-Pivot Quicksort

Hi Vladimir, First Thank you for these impressive results: 15% to 70% overall gains is amazing and will make a big difference, Congratulations ! Could you publish the different test environment ? - HW: cpu (lscpu output) - OS version - JDK version + JVM settings Ideally you or I could write a sh

Re: The final optimized version of Dual-Pivot Quicksort (ver.19.1)

, Laurent Le ven. 12 juil. 2019 à 09:34, Laurent Bourgès a écrit : > Hi, > I asked alan to update the webrev, but I can publish it myself... > > Will do it asap, > Stay tuned, > Laurent > > Le mar. 9 juil. 2019 à 22:19, Brent Christian > a écrit : > >> Hi, >

Re: The final optimized version of Dual-Pivot Quicksort (ver.19.1)

Hi, I asked alan to update the webrev, but I can publish it myself... Will do it asap, Stay tuned, Laurent Le mar. 9 juil. 2019 à 22:19, Brent Christian a écrit : > Hi, > > Is the webrev incomplete? It only contains the changes for > DualPivotQuicksort.java, and not for Arrays.java, etc. > > T

Re: Extending Java Arrays/Collection Sort API

John, Any feedback ? We could discuss that during next OpenJDK workshop, but I would prefer going slowly but surely. Laurent Le jeu. 29 nov. 2018 à 17:52, Laurent Bourgès a écrit : > Hi John & Brian, > > Thanks for the proposed approach, I agree we are in the design discussion;

Re: Extending Java Arrays/Collection Sort API

Hi John & Brian, Thanks for the proposed approach, I agree we are in the design discussion; adding such API enhancements will take time, I said 13 to not hurry for 12 (CSR...). John, you wrote me a very detailed letter, I will try to be more concise and focus on Array.sort() API. Le jeu. 29 nov.

Re: Extending Java Arrays/Collection Sort API

Hi John & Brian, Thank you for your feedback finally, we almost agree Java Sort API could be improved, in jdk13 possibly. > > Doug is right that there is an enormous potential list of sort methods, > and we can't include them all. But I do miss the ability to extract > indexes instead of sorting

Re: Extending Java Arrays/Collection Sort API

Hi, I am happy to announce that I succeeded in writing my own BentleyBasher working like a swiss clock: - auto-tune benchmark passes & hot loop to obtain high accuracy on measurements ~ 2% (guaranteed), with proper variance estimators - test > 10 sorters with small, large & very large int[] arrays

Re: Extending Java Arrays/Collection Sort API

Hi Doug, That's a pleasure to read you. Le mar. 20 nov. 2018 à 13:17, Doug Lea a écrit : > On 11/20/18 2:50 AM, Laurent Bourgès wrote: > > Hi, > > Any feedback on improving Java Sort API ? > > I think most considerations await progress on value types. I posted some

Re: Re[4]: The new optimized version of Dual-Pivot Quicksort

h more predictable and much less depend on input > data than in DPQS), but I strongly believe that concentrating efforts > on testing corner cases performance and integrating RadixSort into JDK > would yield much better performance than DPQS, at least for int[] > arrays. Also the implementation

Re: Extending Java Arrays/Collection Sort API

? Do you have a JMH test suite dedicated to array sorting ? Cheers, Laurent Le mer. 14 nov. 2018 à 09:01, Laurent Bourgès a écrit : > Hi, > > I am a scientist and the author of the Marlin renderer, integrated in > OpenJDK. > > In this renderer, I needed a fast sort algorithm on s

Re: Re[4]: The new optimized version of Dual-Pivot Quicksort

> data than in DPQS), but I strongly believe that concentrating efforts > on testing corner cases performance and integrating RadixSort into JDK > would yield much better performance than DPQS, at least for int[] > arrays. Also the implementation is much simpler. > > With best regard

Re:

Hi Vladimir, > >> >> The test suite was described in this paper >> >> Jon L. Bentley, M. Douglas McILroy >> “Engineering a Sort Function”, 1993 >> >> I use Java version (a little bit extended), see attachment. >> What you need is to specified sorting classes in IntSorter.java >> and run BentleyBa

Extending Java Arrays/Collection Sort API

Hi, I am a scientist and the author of the Marlin renderer, integrated in OpenJDK. In this renderer, I needed a fast sort algorithm on small almost sorted arrays, but more important, to deal with 2 arrays: x values and their corresponding edge indices (pointer like). I derived my MergeSort class

Re:

pensource repository. > > Please let me know if you have questions/comments/improvements. > Sure, I will do, Thanks a lot. Laurent > Понедельник, 12 ноября 2018, 14:01 +03:00 от Laurent Bourgès < > bourges.laur...@gmail.com>: > > Dear Vladimir, > > No informati

Re: Re[4]: The new optimized version of Dual-Pivot Quicksort

> Is it publicly available ? If yes, where ? Cheers, Laurent > Понедельник, 12 ноября 2018, 13:06 +03:00 от Laurent Bourgès < > bourges.laur...@gmail.com>: > > Hi, > > Do you know if someone has written a complete JMH benchmark suite > dedicated to Arrays.sort() ? > w

Re: Re[2]: The new optimized version of Dual-Pivot Quicksort

ndard OpenJDK JMH test suite... For now, I forked the nearly-optimal-mergesort repository on github: https://github.com/bourgesl/nearly-optimal-mergesort-code/tree/master/results Cheers, Laurent Le sam. 10 nov. 2018 à 12:49, Laurent Bourgès a écrit : > Dear Vladimir & other Java sort experts

Re: Re[2]: The new optimized version of Dual-Pivot Quicksort

) or made any mistake on their indices... tricky. PS: Please share your updated webrev when possible to rebase my changes. Regards, Laurent Le ven. 9 nov. 2018 à 10:08, Laurent Bourgès a écrit : > Hi Vladimir, > > Thank you for your attention, you are the Sort Master. > > > Le ve

Re: Re[2]: The new optimized version of Dual-Pivot Quicksort

f new methods are acceptable for you. Then we can discuss > required changes (if any). > Perfect, I started adapting your code and will share soon the link to my github repo. > Thank you, > Vladimir > Thank you very much for your first thoughts, Laurent > Пятница, 9 ноября 2018, 1

Re: The new optimized version of Dual-Pivot Quicksort

nov. 2018 à 08:44, Laurent Bourgès a écrit : > Hi, > > I am currently testing many sort algorithms to improve the Marlin renderer > (AA 2D shape rasterizer), I integrated since OpenJDK9 and am still > improving for OpenJDK12 . > > I created my MergeSort (top down, check fo

Re: The new optimized version of Dual-Pivot Quicksort

Hi, I am currently testing many sort algorithms to improve the Marlin renderer (AA 2D shape rasterizer), I integrated since OpenJDK9 and am still improving for OpenJDK12 . I created my MergeSort (top down, check for sorted parts, array / buffer swap to minimize moves, isort on small sub arrays) t

Re: Can @Stable (or something similar) be made accessible?

Hi, I am the author of the Marlin renderer, integrated in both java.desktop & javafx.graphics modules. I wonder if such core annotations @Stable @ForceInline ... could be allowed to such openjdk modules in order to improve performance. Marlin already uses jdk.internal.Unsafe but @Stable looks pr

Re: Faster Math ?

ass will pop out of that, but FWIW i am > sympathetic to that :-) > > I liked this tweet: > > https://twitter.com/FioraAeterna/status/926150700836405248 > >life as a gpu compiler dev is basically just fielding repeated > complaints that >"fast math" isn

Re: Faster Math ?

ding repeated > complaints that > "fast math" isn't precise and "precise math" isn't fast > > as an indication of what we could be getting into :-) > > Paul. > > > On 9 Nov 2017, at 01:00, Laurent Bourgès > wrote: > > > > Hi,

Re: Faster Math ?

lues for the same angle ? It is very useful to compute exact fourrier transform... It is called sinAndCos(double wrappers) in jafama. Cheers, Laurent Le 9 nov. 2017 17:08, "Andrew Haley" a écrit : > On 09/11/17 15:02, Laurent Bourgès wrote: > > --- testing cbrt(do

Re: Faster Math ?

=> 10x slower - cbrt() is slower than pow(1/3) : 1.1s vs 0.7s => 50% slower Any plan to enhance these specific math operations ? Laurent 2017-11-09 14:33 GMT+01:00 Laurent Bourgès : > I checked in the latest jdk master and both cbrt / acos are NOT intrinsics. > > However, cbrt(x

Re: Faster Math ?

elf using jitwatch. There is > no native call overhead. > > The standard library does not currently include less accurate but faster > Math functions, maybe someone else can answer if that is something to be > considered. > > - Jonas Konrad > > On 11/09/2017 10:00 AM, La

Faster Math ?

Hi, The Marlin renderer (JEP265) uses few Math functions: sqrt, cbrt, acos... Could you check if the current JDK uses C2 intrinsics or libfdm (native / JNI overhead?) and tell me if such functions are already highly optimized in jdk9 or 10 ? Some people have implemented their own fast Math like

Re: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8149896: Remove unnecessary values in FloatConsts and DoubleConsts

Hello, Joe, I tested your changes in the Marlin renderer as it works well ! > A quick note on the 2d changes, several constants (and a copy from a > package-private method from java.lang) were used to initialize a double > value POWER_2_TO_32; this can be accomplished more directly using a > hex

Re: RFR: JDK-8066859 java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died

Peter, Thanks for long and detailled answer. I know now better why OOME should not happen. However any application may also use phantom references and the ReferenceHandler thread will call Cleaner.run () which could catch OOME from the application code implementing thunk.run (). Am I right ? >>

Re: RFR: JDK-8066859 java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died

Peter, I looked at Cleaner by curiosity and it seems to be not catching the oome from thunk.run ! If oome1 is thrown by thunk.run at line 150 then it is catched at line 157 but your new try/catch block (oome2) only encapsulates the doPriviledge block. If this block also throws a new oome2 due to

Fwd: Re: Fwd: Improve large array allocation / gc & intrinsics

Comments & opinions from core-libs, please ? Laurent -- Message transféré -- De : "Thomas Schatzl" Date : 11 févr. 2014 11:28 Objet : Re: Fwd: Improve large array allocation / gc & intrinsics À : "Laurent Bourgès" Cc : > Hi, > > just

Fwd: Improve large array allocation / gc & intrinsics

check elimination or fill / clear intrinsics ... Who would be interested by this topics ? Laurent -- Message transféré -- De : "Laurent Bourgès" Date : 10 févr. 2014 10:24 Objet : Improve large array allocation / gc & intrinsics À : "core-libs-dev&

Improve large array allocation / gc & intrinsics

ays (clean), update usage statistics and manage cache eviction policy (avoid wasting memory) Please give me your feedback & opinion and evaluate if this feature seems possible to implement into the JDK (hotspot, gc, core-libs) ... What is the procedure to create such JDK9 RFE ? Best reg

Re: Conflicts between JVM application and j.u.l logging shutdown hooks

Alan, Thanks for creating the bug 9005822 ! As I spotted in my initial email, both shutdown hook problems (JavaWS and JUL) are due to the concurrent execution of shutdown hooks : com.sun.imageio.stream.StreamCloser.java 101: Runtime.getRuntime().addShutdownHook(streamCloser); java.util.logging

Conflicts between JVM application and j.u.l logging shutdown hooks

Anybody wants to look at this logging issue I reported several months ago? Le 27 juin 2013 11:57, "Laurent Bourgès" a écrit : > > Dear members, > > I have a problem within an external library using one JVM Shutdown hook to perform resource cleanup (socket, lock file de

Re: JVM application shutdown hooks

Dear core-libs members, I finally succeed in diagnosing my shutdown hook issue in Java Web Start environment: see Bug ID: 9005822. Could you please give ma feedback to my questions related to LogManager and StreamCloser shutdown hooks ? This library uses java.util.logging to log warnings and ex

JVM application shutdown hooks

dencies between them (like systemd or rc scripts does). PS: As shutdown hooks are given by the application as Thread class instances, I suspect also a possible classloader leak ? In Java web start environment, it may be the cause of my problems as I do not know if the hook thread is still within the application class loader ... Laurent Bourgès

Re: RFR (XS) CR 8014233: java.lang.Thread should be @Contended

short lived objects but for the old generation (long lived objects) it is not the case: maybe G1 can provide different partitioning and maybe take into acccount the thread affinity ? Laurent 2013/5/9 Peter Levart > > On 05/09/2013 04:59 PM, Laurent Bourgès wrote: > > Hi all, > > A

Re: RFR (XS) CR 8014233: java.lang.Thread should be @Contended

Hi all, A stupid question: any ThreadLocal subclass should be marked @Contended to be sure that false sharing never happens between ThreadLocal instance and any other object on the heap ? Laurent 2013/5/9 Peter Levart > Hi Aleksey, > > Wouldn't it be even better if just threadLocalRandom* fiel

Re: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements

Jim, thanks for having some interest for my efforts ! As I got almost no feedback, I felt quite disappointed and was thinking that improving pisces was not important ... Here are ductus results and comparison (open office format): http://jmmc.fr/~bourgesl/share/java2d-pisces/ductus_det.log http:/

Re: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements

3743,255 3745,111 83,027 3746,031 3828,138 3549,364 3866,612 shp_alllayers_47 4 80 6960,23 6960,948 189,75 6963,533 7150,698 6432,945 7431,541 Linux 64 server vm JVM: -Xms128m -Xmx128m (low mem) Laurent 2013/4/14 Andrea Aime > On Tue, Apr 9, 2013 at 3:02 PM, Laurent Bourgès > wrote: >

Re: sun.awt.X11 logs still using String + (waste)

Anthony, Here is the updated webrev: http://jmmc.fr/~bourgesl/share/webrev-8010297.5/ Laurent 2013/4/11 Mandy Chung > On 4/11/13 8:43 AM, Laurent Bourgès wrote: > > > I don't understand if I should fix it or not ? > > src/solaris/classes/sun/awt/X11/XListPeer.jav

Re: sun.awt.X11 logs still using String + (waste)

Mandy, I'd really like to see if we can avoid the boilerplate "if (isLoggable(...)) logger.fine()" and help ease of development and I file a RFE (8012006). Agreed but there is no easy way to have clear code and performance: - maybe JDK 8 Supplier may help - or a shorter syntax: logger.isDebug

Re: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste

e better timing / comparison between bench runs. Regards, Laurent 2013/4/11 Laurent Bourgès > Jim and Sergey, > > 1/ Here are few benchmarks (based on mapBench again) running several > modified versions of AAShapePipe: > http://jmmc.fr/~bourgesl/share/AAShapePipe/mapBench/ >

Fwd: sun.awt.X11 logs still using String + (waste)

Anthony, Mandy, here the 4th patch: http://jmmc.fr/~bourgesl/share/webrev-8010297.4/ It only contains awt / swing / net classes that use PlatformLogger (no code modification). Laurent

Re: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste

Jim and Sergey, 1/ Here are few benchmarks (based on mapBench again) running several modified versions of AAShapePipe: http://jmmc.fr/~bourgesl/share/AAShapePipe/mapBench/ - ref: 1 threads and 20 loops per thread, time: 3742 ms 2 threads and 20 loops per thread, time: 4756 ms 4 threads and 20 loop

Re: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste

Sergey, I am not an expert here but just my 50 cents. > This optimization shall take place only if it is really hotspot. But if it > is a really hotspot - probably it would be better to remove these > array/object allocation at all and use plane bytes? > Java2D calls AAShapePipe for each shape (l

Re: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste

s, Peter > > > > On 04/10/2013 10:58 AM, Laurent Bourgès wrote: > > Dear Jim, > > 2013/4/9 Jim Graham > >> >> The allocations will always show up on a heap profiler, I don't know of >> any way of having them not show up if they are stack allocated,

Re: sun.awt.X11 logs still using String + (waste)

AM, Laurent Bourgès wrote: > > Mandy, > > first I would like to have the given patch applied to OpenJDK 8 (+ JDK7u) > as it fixes many problems: > - string concatenations > - object creations (Object[] or other objects given as params) > - method calls in log statements >

Re: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste

Dear Jim, 2013/4/9 Jim Graham > > The allocations will always show up on a heap profiler, I don't know of > any way of having them not show up if they are stack allocated, but I don't > think that stack allocation is the issue here - small allocations come out > of a fast generation that costs a

Re: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste

.fr 2.6.35.14-106.fc14.x86_64 #1 SMP Wed Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux 2013/4/10 Andrea Aime > On Tue, Apr 9, 2013 at 7:34 PM, Laurent Bourgès > wrote: > >> Also, this should be tested on multiple platforms, preferably Linux, >> Windows and Mac to s

Re: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste

Dear Jim, I advocated I only looked at the netbeans memory profiler's output: no more megabytes allocated ! The main question is: how to know how GC / hotspot deals with such small allocations ? Is there any JVM flag to enable to see real allocations as does jmap -histo. > > Quick questions - wh

[OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements

bounds Could somebody support me ? ie help me working on these tasks or just to discuss on Pisces algorithm / implementation ? Best regards, Laurent Bourgès

Re: sun.awt.X11 logs still using String + (waste)

Mandy, first I would like to have the given patch applied to OpenJDK 8 (+ JDK7u) as it fixes many problems: - string concatenations - object creations (Object[] or other objects given as params) - method calls in log statements In a second step, I can help somebody migrating JUL usages to Platfor

Re: sun.awt.X11 logs still using String + (waste)

Anthony, here is an updated patch concerning both PlatformLogger and Logger 'bad' usages: http://jmmc.fr/~bourgesl/share/webrev-8010297.3/ It impacts now awt, swing, JMX, security, network, and apache xml. Thanks for the review, Laurent 2013/4/8 Laurent Bourgès > Peter, Mandy, &

Re: sun.awt.X11 logs still using String + (waste)

differences between Logger / PlatformLogger to make PlatformLogger API more similar to JUL Logger ? Laurent 2013/4/8 Peter Levart > On 04/07/2013 07:11 PM, Laurent Bourgès wrote: > > Hi > > I started fixing All PlatformlLogger "bad" usages and I am fixing also > ma

Re: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)

such shared arrays static final int INITIAL_ARRAY = 256 + 1; static final int INITIAL_Y_ARRAY = 2048 + 1; static final int INITIAL_LARGE_ARRAY = 16384 + 1; // large Laurent 2013/4/7 Andrea Aime > On Fri, Apr 5, 2013 at 4:32 PM, Laurent Bourgès > wrote: > >> Dear all, &

Re: sun.awt.X11 logs still using String + (waste)

Hi I started fixing All PlatformlLogger "bad" usages and I am fixing also many jul Logger usages without isLoggable ... That represents a lot of changes and a very boring job. I think sending a webrew tomorrow. Laurent Le 4 avr. 2013 14:08, "Laurent Bourgès" a écrit : &g

Re: Review request: 8011380: FX dependency on PlatformLogger broken

rformance efficient to concatenate strings in logger messages. It is better to use a template message with placeholders that are replaced by concrete values only when the message is really going to be logged. *Since NetBeans 6.9* " Cheers, Laurent > Mandy > P.S. I'll be pushing the chan

Re: Review request: 8011380: FX dependency on PlatformLogger broken

Laurent > > On 4/5/2013 1:55 AM, Laurent Bourgès wrote: > > Mandy, > > I would like to add few performance advices in the PlatformLogger Javadoc: > " > NOTE: For performance reasons, PlatformLogger usages should take care of > avoiding useless / wasted obje

Re: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)

Dear all, Here is my first pisces (beta) patch (webrev): http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/ I succeed in fixing memory usage by having only 1 pisces instance (Renderer, stroker, iterator ...) per RendererContext (GC friendly). Impressive results between small and large drawin

AAShapePipe concurrency & memory waste

Dear java2d members, I figured out some troubles in java2d.pipe.AAShapePipe related to both concurrency & memory usage: - concurrency issue related to static theTile field: only 1 tile is cached so a new byte[] is created for other threads at each call to renderTile() - excessive memory usage (byt

Re: Review request: 8011380: FX dependency on PlatformLogger broken

Mandy, I would like to add few performance advices in the PlatformLogger Javadoc: " NOTE: For performance reasons, PlatformLogger usages should take care of avoiding useless / wasted object creation and method calls related to * disabled* log statements: Always use isLoggable(level) wrapping logs

Re: Review request: 8011380: FX dependency on PlatformLogger broken

Well done: binary search to find the closest matching level ! However, I still do not see any concrete use case for custom Levels in such closed API as PlatformLogger is: KISS, please ! I mean as PlatformLogger is only used (available) to JDK and related projects, is there any RFE or will to use

Re: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)

sun.java2d.pisces.RendererContext$1 Regards, Laurent 2013/4/3 Laurent Bourgès > Thanks for your valueable feedback! > > Here is the current status of my patch alpha version: >>> http://jmmc.fr/~bourgesl/share/java2d-pisces/ >>> >>> There is still a lot to be

Re: sun.awt.X11 logs still using String + (waste)

> > On 04/04/13 15:47, Laurent Bourgès wrote: > >> Dear all, >> >> I just realized there is another problem with PlatformLogger log >> statements: >> XBaseWindow: >> public boolean grabInput() { >> grabLog.fine("Grab input

Re: sun.awt.X11 logs still using String + (waste)

is problem ? Does somebody have an idea to automatically analyze the JDK code and detect missing isLoggable statements ... Regards, Laurent 2013/4/3 Laurent Bourgès > Anthony, > > could you tell me once it is in the OpenJDK8 repository ? > I would then perform again profiling tests to che

Re: Review request: 8011380: FX dependency on PlatformLogger broken

Mandy, Peter, here are my comments: On 04/04/2013 06:52 AM, Mandy Chung wrote: > > Peter, Laurent, > > History and details are described below. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8011380/webrev.00/ > > I add back the getLevel(int), setLevel(int) and isLoggable(int) m

Re: hg: jdk8/tl/jdk: 8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level

Does JavaFX belong to OpenJDK projects (*openjfx/8) *? How do I build the complete OpenJDK (javafx, java web start ...) ? Laurent 2013/4/3 Alan Bateman > On 28/03/2013 20:16, mandy.ch...@oracle.com wrote: > > Changeset: e433ed08b733 > Author:mchung >

Re: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)

Thanks for your valueable feedback! Here is the current status of my patch alpha version: >> http://jmmc.fr/~bourgesl/share/java2d-pisces/ >> >> There is still a lot to be done: clean-up, stats, pisces class instance >> recycling (renderer, stroker ...) and of course sizing correctly initial >> ar

Re: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap

> --- > > 604 Arrays.fill(elementData, newSize, size, null); > > In performance-critical code I would avoid Arrays.fill because it adds a > bit of overhead (unless it's intrinsified, which I don't think it is). > Last week, I sent few benchmarks I did on array cleaning (zero fill) compari

  1   2   >