build error in lambda repo

[Brian Goetz]

tee() seems the wrong way to start a timer, since it will get called for 
each element.

If all you are looking to do is measure the time, you could do:

   Stream<Foo> stream = list.stream();
   beginTimer();
   stream.map(...).forEach(e -> { });
   endTimer();

That gives you timing on your map function, but you lose your data, 
which is probably fine if all you want to do is performance measurement.

There's no free lunch here.  You gain efficiency by interleaving the 
stages, but that makes it harder to do fine-grained performance 
measurement.



On 8/29/2012 2:53 PM, Jose wrote:
>
> Thanks for the info, the tee operator is not yet present in the current b50
> build but seems promising.
>
> I want to find the best way to profile separated elements of the chain, as I
> used to do before converting my code to the new syntax. But profiling
> pipelines seems to be more subtle than profiling regular code and I've been
> doing some misinterpretations that amost lead me crazy for not paying enough
> attention.
>
> Suppose you have a pipeline like this:
>
> 	
> collection.map(lambda1).map(lambda2).map(lambda3)....
>
> and you have two implementations of the lambda2, you wan to compare to each
> other.
>
> I guess the tee operator would be handy to place a timer before and other
> after the second map. But in fact I dont want to measue the time spent in
> computing a SINGLE ELEMENT of the collection, which is too tiny, almost
> irrelevant in my case. I want to profile lambda2 against ALL THE ELEMENTS in
> the collection.
>
> So I need to "isolate" the second map by means of some sort of "forcing
> evaluation" before and after it. The only way I can advise is to copy to a
> new collection, so that the testing pipleine would seem something like this:
>
> collection.map(lambda1).into(coll).tee(timer(start)).map(lambda2).into(coll)
> .tee(timer(end)).map(lambda3)....
>
> Not that bad, but I wonder if there is, could be in the future, a better
> solution for profiiling.
> On the other hand, it would be convinient to include in the doc some advice
> on profiling pipelines, to avoid probable pitfalls.
>
>
>
>
>
> -----Mensaje original-----
> De: lambda-dev-bounces at openjdk.java.net
> [mailto:lambda-dev-bounces at openjdk.java.net] En nombre de Mike Duigou
> Enviado el: miércoles, 29 de agosto de 2012 19:45
> Para: lambda-dev
> Asunto: Re: build error in lambda repo
>
> We're working on syncing the lambda repo to latest jdk8 mainline but there
> have been some issues in <speculation>interactions between the new 292 work
> and the lambda extensions</speculation>. Those issues will hopefully soon be
> resolved. In the meantime I have imported the
> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/5e2dc722e70d changeset into
> the lambda/hotspot repo which should resolve build issues. If there are
> other single changesets we can cherry-pick from jdk8 mainline to fix
> specific issues I am happy to try.
>
> Mike
>
> On Aug 29 2012, at 03:59 , David Holmes wrote:
>
>> Fixed in JDK 8-b51, hs24-b19
>>
>> David
>>
>> On 29/08/2012 8:49 PM, Peter Levart wrote:
>>> ----------  Forwarded Message  ----------
>>>
>>> Subject: Re: build error in lambda repo
>>> Date: Wednesday, August 29, 2012, 07:47:36 PM
>>> From: David Holmes<david.holmes at oracle.com>
>>> To: Peter Levart<peter.levart at marand.si>
>>> CC: hotspot-runtime-dev at openjdk.java.net
>>>
>>> Hi Peter,
>>>
>>> I'm pretty sure this has already been fixed in the hsx&  jdk8 forests.
>>>
>>> Thanks,
>>> david
>>>
>>> On 29/08/2012 6:35 PM, Peter Levart wrote:
>>>> Hello,
>>>>
>>>> I had to make the following changes to 2 hotspot source files (suggested
> by the gcc messages) in order to build the latest lambda enabled JDK:
>>>>
>>>>
>>>> diff -r ad87adf32248 src/share/vm/utilities/hashtable.cpp
>>>> --- a/src/share/vm/utilities/hashtable.cpp      Wed Aug 08 15:11:28 2012
> -0400
>>>> +++ b/src/share/vm/utilities/hashtable.cpp      Wed Aug 29 10:26:11 2012
> +0200
>>>> @@ -135,7 +135,7 @@
>>>>          // walking the hashtable past these entries requires
>>>>          // BasicHashtableEntry::make_ptr() call.
>>>>          bool keep_shared = p->is_shared();
>>>> -      unlink_entry(p);
>>>> +      this->unlink_entry(p);
>>>>          new_table->add_entry(index, p);
>>>>          if (keep_shared) {
>>>>            p->set_shared();
>>>> diff -r ad87adf32248 src/share/vm/utilities/hashtable.hpp
>>>> --- a/src/share/vm/utilities/hashtable.hpp      Wed Aug 08 15:11:28 2012
> -0400
>>>> +++ b/src/share/vm/utilities/hashtable.hpp      Wed Aug 29 10:26:11 2012
> +0200
>>>> @@ -260,7 +260,7 @@
>>>>      }
>>>>
>>>>      int index_for(Symbol* name) {
>>>> -    return hash_to_index(compute_hash(name));
>>>> +    return this->hash_to_index(compute_hash(name));
>>>>      }
>>>>
>>>>      // Table entry management
>>>>
>>>>
>>>> I'm using g++ (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5) on Fedora 17.
>>>>
>>>> Regards, Peter
>>>>
>>> -----------------------------------------
>>
>
>