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
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
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,
>
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
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
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
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
>
>
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
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
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
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
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
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
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
>>
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
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
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
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
>>
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
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
(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
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
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
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:
> >
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
on'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
> do
> > that.
> >
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,
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
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
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
,
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,
>
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.
>
>
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 discuss
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
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
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[]
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
>
e 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 is mu
?
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
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 regards,
&g
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
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
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
hms.
>
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() ?
> with v
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,
>
//
b) 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
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, 10:44
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
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)
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
t 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't precise and
r dev is basically just fielding 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 <bourges.
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...@redhat.com> a écrit :
> On 09/11/17 15:02, Laurent Bourgès wrote:
> > --- test
=> 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 <bourges.laur...@gmail.com>:
> I checked in the latest jdk master and both cbrt / acos are NOT in
test this yourself 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/20
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
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
>
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
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 ?
Comments opinions from core-libs, please ?
Laurent
-- Message transféré --
De : Thomas Schatzl thomas.scha...@oracle.com
Date : 11 févr. 2014 11:28
Objet : Re: Fwd: Improve large array allocation / gc intrinsics
À : Laurent Bourgès bourges.laur...@gmail.com
Cc : hotspot
check elimination or fill / clear intrinsics ...
Who would be interested by this topics ?
Laurent
-- Message transféré --
De : Laurent Bourgès bourges.laur...@gmail.com
Date : 10 févr. 2014 10:24
Objet : Improve large array allocation / gc intrinsics
À : core-libs-dev core-libs-dev
), 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 regards,
Laurent
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);
Anybody wants to look at this logging issue I reported several months ago?
Le 27 juin 2013 11:57, Laurent Bourgès bourges.laur...@gmail.com a
écrit :
Dear members,
I have a problem within an external library using one JVM Shutdown hook
to perform resource cleanup (socket, lock file deletion
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
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
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 peter.lev...@gmail.com
On 05/09/2013 04:59 PM, Laurent Bourgès wrote:
Hi all,
A stupid
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 peter.lev...@gmail.com
Hi Aleksey,
Wouldn't it be even better if just
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
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 andrea.a...@geo-solutions.it
On Tue, Apr 9, 2013 at 3:02 PM, Laurent
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
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
timing / comparison between bench runs.
Regards,
Laurent
2013/4/11 Laurent Bourgès bourges.laur...@gmail.com
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
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:
Anthony,
Here is the updated webrev:
http://jmmc.fr/~bourgesl/share/webrev-8010297.5/
Laurent
2013/4/11 Mandy Chung mandy.ch...@oracle.com
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.java
Nit
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 andrea.a...@geo-solutions.it
On Tue, Apr 9, 2013 at 7:34 PM, Laurent Bourgès bourges.laur...@gmail.com
wrote:
Also, this should be tested on multiple platforms, preferably Linux
Dear Jim,
2013/4/9 Jim Graham james.gra...@oracle.com
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
On 4/9/13 12:37 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
This is the patch
AM, Laurent Bourgès wrote:
Dear Jim,
2013/4/9 Jim Graham james.gra...@oracle.com
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
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
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
of 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
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 -
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 andrea.a...@geo-solutions.it
On Fri, Apr 5, 2013 at 4:32 PM, Laurent Bourgès bourges.laur
differences between Logger /
PlatformLogger to make PlatformLogger API more similar to JUL Logger ?
Laurent
2013/4/8 Peter Levart peter.lev...@gmail.com
On 04/07/2013 07:11 PM, Laurent Bourgès wrote:
Hi
I started fixing All PlatformlLogger bad usages and I am fixing also
many jul Logger usages
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 bourges.laur...@gmail.com
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 bourges.laur...@gmail.com a
écrit :
Ok
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 changeset today.
On 4/5/2013 9:02 AM, Laurent Bourgès wrote:
Mandy,
I agree it should be well known; but I fixed several cases in awt/net code
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
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
, 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 object creation and method calls related to *
disabled* log statements:
Always use
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) methods
somebody have an idea to automatically analyze the JDK code and detect
missing isLoggable statements ...
Regards,
Laurent
2013/4/3 Laurent Bourgès bourges.laur...@gmail.com
Anthony,
could you tell me once it is in the OpenJDK8 repository ?
I would then perform again profiling tests to check
/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 on {0}, this);
...
}
This calls the PlatformLogger.fine( varargs):
public void
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
arrays
Does JavaFX belong to OpenJDK projects
(*openjfx/8http://hg.openjdk.java.net/openjfx/8/)
*?
How do I build the complete OpenJDK (javafx, java web start ...) ?
Laurent
2013/4/3 Alan Bateman alan.bate...@oracle.com
On 28/03/2013 20:16, mandy.ch...@oracle.com wrote:
Changeset: e433ed08b733
---
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)
comparing
in order to tune Pisces automatically depending on the
user work load.
Regards,
Laurent
On 3/29/2013 6:53 AM, Laurent Bourgès wrote:
Phil,
I agree it is a complex issue to improve memory usage while maintaining
performance at the JDK level: applications can use java2d pisces in very
) has to be smart (auto - tune)
- clipping issues (dasher, stroker) and spatial resolution (no cpu/memory
waste)
2013/3/30 Andrea Aime andrea.a...@geo-solutions.it
On Fri, Mar 29, 2013 at 3:16 PM, Laurent Bourgès
bourges.laur...@gmail.com wrote:
Andrea,
It could be very interesting if you
there is some hotspot magic involved to recognise and intrinsify
this
method, since the source code looks like a plain old for loop.
-phil.
On 3/26/2013 4:00 AM, Laurent Bourgès wrote:
Dear all,
First I joined recently the openJDK contributors, and I plan to fix
java2D pisces code in my spare
1 - 100 of 121 matches
Mail list logo