Re: ClassValue perf?

Hi Peter, thanks! I'll start another test run. Best, Michael > Am 31.05.2016 um 13:05 schrieb Peter Levart : > > > > On 05/30/2016 11:09 PM, Peter Levart wrote: >> Will revert that to volatile semantics... > > So, here it is. The latest incarnation - the same as

Re: ClassValue perf?

On 05/30/2016 11:09 PM, Peter Levart wrote: Will revert that to volatile semantics... So, here it is. The latest incarnation - the same as webrev.04.1 but with volatile semantics: http://cr.openjdk.java.net/~plevart/misc/ClassValue.Alternative2/webrev.04.2/ Benchmarks show no change in

Re: ClassValue perf?

On 05/30/2016 07:47 PM, Aleksey Shipilev wrote: On 05/30/2016 06:59 PM, Peter Levart wrote: I also employed get-acquire/put-release memory ordering semantics instead of SC (volatile) in hope that it might improve a bit the performance on platforms such as PowerPC or ARM, but this can be

Re: ClassValue perf?

Hi Michael, In the meantime I improved LinearProbeHashtable as I identified a weakness in its implementation. In general, if an entry for the same key was inserted and removed repeatably, then each such repetition planted a "tombstone" at a position of inserted key which means that lookup

Re: ClassValue perf?

Hi Peter, the internal tests look good. I'll assign the issue over to you. Thanks! Best, Michael > Am 26.05.2016 um 14:42 schrieb Michael Haupt : > > Hi Peter, > > thank you for this wonderful piece of work. > >> Am 26.05.2016 um 10:59 schrieb Peter Levart

Re: LinearProbeHashtable Re: ClassValue perf?

Hi Peter, > On 27 May 2016, at 12:41, Peter Levart wrote: > > Hi Paul, > > On 05/26/2016 01:20 PM, Paul Sandoz wrote: >> Hi Peter, >> >> Opportunistically if your LinearProbeHashtable works out then i am wondering >> if we could replace the use of CHM within >>

Re: ClassValue perf?

Hi Peter,thank you for this wonderful piece of work.Am 26.05.2016 um 10:59 schrieb Peter Levart : How does this implementation compare on your hardware, Michael?Results attached. It improves on the unpatched version in all cases, is in most cases even faster than the

Re: ClassValue perf?

Hi Michael, On 05/23/2016 03:56 PM, Michael Haupt wrote: I've ran the unpatched version and Peter's two patches once more. The results are attached (results.txt). They confirm Aleksey's observation. Regarding the 03 patch (plevart3 column in the results), perfasm output (see

Re: ClassValue perf?

Hi Aleksey,thanks; comments inlined.Am 19.05.2016 um 15:57 schrieb Aleksey Shipilev :On 05/19/2016 03:32 PM, Michael Haupt wrote:It may well be that running the bechmark so few times does not deliver astable enough result. I'd like Aleksey to comment on this: is

Re: ClassValue perf?

On 05/19/2016 03:32 PM, Michael Haupt wrote: > It may well be that running the bechmark so few times does not deliver a > stable enough result. I'd like Aleksey to comment on this: is adopting > Peter's code worthwhile given it improves on footprint and reduces code > size and complexity? Eh, if

Re: ClassValue perf?

Hi Peter,thank you. As some background info, the machine I'm running the benchmarks on is a 32-core Xeon.Results of running your latest benchmarks with unmodified 9-dev and your two patches (02, 03) are attached. Overall, it seems your solution 03 is a bit slower than 02, and 02 shines especially

Re: ClassValue perf?

Hi Christian, > Am 06.05.2016 um 22:35 schrieb Christian Thalinger > : >> Given that one concern with this issue, next to reducing footprint, was to >> optimise for the single-value case, I'm still a bit hesitant even though the >> sheer amount of code reduction

Re: ClassValue perf?

Hi Michael, On 05/06/2016 04:48 PM, Michael Haupt wrote: Hi Peter, thank you. I've run the full benchmark in my setup and uploaded the updated cumulative results to http://cr.openjdk.java.net/~mhaupt/8031043/ . The benchmark indeed shows

Re: ClassValue perf?

> On May 6, 2016, at 4:48 AM, Michael Haupt wrote: > > Hi Peter, > > thank you. I've run the full benchmark in my setup and uploaded the updated > cumulative results to http://cr.openjdk.java.net/~mhaupt/8031043/ > . > >

Re: ClassValue perf?

Hi Peter, thank you. I've run the full benchmark in my setup and uploaded the updated cumulative results to http://cr.openjdk.java.net/~mhaupt/8031043/. The benchmark indeed shows that this latest addition to the group slows down random and sequential access, especially for small numbers of

Re: ClassValue perf?

Hi Michael, On 05/04/2016 06:02 PM, Michael Haupt wrote: Hi Peter, thank you for chiming in again! :-) I'll look at this in depth on Friday. Good. Because I found bugs in expunging logic and a discrepancy of behavior when a value is installed concurrently by some other thread and then

Re: ClassValue perf?

Hi Peter, thank you for chiming in again! :-) I'll look at this in depth on Friday. Best, Michael > Am 04.05.2016 um 17:50 schrieb Peter Levart : > > Hi, > > On 04/29/2016 10:28 AM, Michael Haupt wrote: >> All, >> >> see http://cr.openjdk.java.net/~mhaupt/8031043/

Re: ClassValue perf?

Hi again, I've uploaded a reformatted results file (and an Excel sheet in case that's interesting) that show the results side by side. Best, Michael > Am 02.05.2016 um 10:38 schrieb Michael Haupt : > > Hi Jochen, > > thanks for clarifying. I've added results from

Re: ClassValue perf?

Hi, On 04/29/2016 10:28 AM, Michael Haupt wrote: All, see http://cr.openjdk.java.net/~mhaupt/8031043/ for a snapshot of what is currently available. We have three patches: * Christian's, which simply reduces the HashMap size, * Peter's,

Re: ClassValue perf?

Hi Jochen, thanks for clarifying. I've added results from running the benchmarks on an the unpatched JDK 9 base (see the CR link). The twisti and plevart patches perform better for large numbers of classes and class values; the mhaupt patch is weaker than the baseline in those settings. As

Re: ClassValue perf?

Hi, there was not really any misunderstanding, just that some optimizations have to be considered carefully. I am no JDK reviewer, so I can give only my opinion as a user. But I am missing a comparison with the unpatched version. Comparing the given results and considering the size of the

Re: ClassValue perf?

lines of removeSingleEntry seems rather mysterious. cheers, Rémi - Mail original - > De: "Michael Haupt" <michael.ha...@oracle.com> > À: "Da Vinci Machine Project" <mlvm-dev@openjdk.java.net> > Envoyé: Vendredi 29 Avril 2016 13:19:32 > Objet

Re: ClassValue perf?

Hi Jochen, > Am 29.04.2016 um 14:42 schrieb Jochen Theodorou : > On 29.04.2016 13:19, Michael Haupt wrote: >> Hi Jochen, >> >>> Am 29.04.2016 um 12:17 schrieb Jochen Theodorou >> >: >>> my fear is a bit that having only a single

Re: ClassValue perf?

On 29.04.2016 13:19, Michael Haupt wrote: Hi Jochen, Am 29.04.2016 um 12:17 schrieb Jochen Theodorou >: my fear is a bit that having only a single value, will not be enough if you have for example multiple dynamic languages running... let's say

Re: ClassValue perf?

Hi Jochen, > Am 29.04.2016 um 12:17 schrieb Jochen Theodorou : > my fear is a bit that having only a single value, will not be enough if you > have for example multiple dynamic languages running... let's say Nashorn, > JRuby, and Groovy. Also, if I ever get there, using

Re: ClassValue perf?

On 29.04.2016 10:28, Michael Haupt wrote: All, see http://cr.openjdk.java.net/~mhaupt/8031043/ for a snapshot of what is currently available. We have three patches: * Christian's, which simply reduces the HashMap size, * Peter's, which refactors ClassValueMap into a WeakHashMap, * mine,

Re: ClassValue perf?

All, see http://cr.openjdk.java.net/~mhaupt/8031043/ for a snapshot of what is currently available. We have three patches: * Christian's, which simply reduces the HashMap size, * Peter's, which refactors ClassValueMap into a WeakHashMap, * mine, which attempts to introduce the single-value

Re: ClassValue perf?

Am 30.04.2015 15:43, schrieb Charles Oliver Nutter: On Mon, Apr 27, 2015 at 12:50 PM, Jochen Theodorou blackd...@gmx.org wrote: Am 27.04.2015 19:17, schrieb Charles Oliver Nutter: Jochen: Is your class-to-metaclass map usable apart from the Groovy codebase? Yes. Look for

Re: ClassValue perf?

Hi Peter, computeValue() may recursively call get() by example to crawle the inheritance hierarchy so i am not sure a lock is a good idea here because in that case, it usually takes several millis to complete the to level computeValue. regards, Rémi On 05/03/2015 12:32 AM, Peter Levart

Re: ClassValue perf?

On Wed, Apr 29, 2015 at 4:02 AM, Doug Simon doug.si...@oracle.com wrote: We considered using ClassValue in Graal for associating each Node with its NodeClass. Accessing the NodeClass is a very common operation in Graal (e.g., it’s used to iterate over a Node’s inputs). However, brief

Re: ClassValue perf?

On Mon, Apr 27, 2015 at 12:50 PM, Jochen Theodorou blackd...@gmx.org wrote: Am 27.04.2015 19:17, schrieb Charles Oliver Nutter: Jochen: Is your class-to-metaclass map usable apart from the Groovy codebase? Yes. Look for org.codehaus.groovy.reflection.GroovyClassValuePreJava7 which is

Re: ClassValue perf?

We considered using ClassValue in Graal for associating each Node with its NodeClass. Accessing the NodeClass is a very common operation in Graal (e.g., it’s used to iterate over a Node’s inputs). However, brief experimentation showed implementing this with ClassValue performed significantly

Re: ClassValue perf?

On 25/04/2015 13:44, Remi Forax fo...@univ-mlv.fr wrote: On 04/24/2015 11:17 PM, John Rose wrote: On Apr 24, 2015, at 5:38 AM, Charles Oliver Nutter head...@headius.com wrote: Hey folks! I'm wondering how the performance of ClassValue looks on recent OpenJDK 7 and 8 builds. JRuby 9000 will be

Re: ClassValue perf?

On Apr 24, 2015, at 2:17 PM, John Rose john.r.r...@oracle.com wrote: On Apr 24, 2015, at 5:38 AM, Charles Oliver Nutter head...@headius.com wrote: Hey folks! I'm wondering how the performance of ClassValue looks on recent OpenJDK 7 and 8 builds. JRuby 9000 will be Java 7+ only, so

Re: ClassValue perf?

Am 27.04.2015 19:17, schrieb Charles Oliver Nutter: It seems I may have to write some benchmarks for this then. Just so I understand, the equivalent non-ClassValue-based store would need to: * Be atomic; value may calculate more than once but only be set once. * Be weak; classes given class

Re: ClassValue perf?

On 04/24/2015 11:17 PM, John Rose wrote: On Apr 24, 2015, at 5:38 AM, Charles Oliver Nutter head...@headius.com wrote: Hey folks! I'm wondering how the performance of ClassValue looks on recent OpenJDK 7 and 8 builds. JRuby 9000 will be Java 7+ only, so this is one place I'd like to simplify