Maybe yes, maybe not... in my experience escape analysis is very fickle, e.g. it's very easy for a method to become big enough after inlining that escape analysis is not performed at all.
Dan On Fri, Mar 31, 2017 at 10:59 AM, Tristan Tarrant <ttarr...@redhat.com> wrote: > I was about to say the same: in the typical use case of returning an > optional and using it immediately it would probably end up on the stack > anyway... > > Tristan > > On 31/03/2017 09:57, Radim Vansa wrote: >> I secretly hope that all these allocations would be inlined and >> eliminated. If we find out that it really allocates the objects (from >> JFR's allocation stats), it's a reason to rewrite that piece of code to >> the dull optionless version. >> TBH I am rather afraid that the JVM will allocate the consumer which >> will need some captured variables. Maybe I trust C2 compiler too much, >> believing that if the handler isn't too big, it will generate similar >> instructions with nicer source code :-/ >> >> R. >> >> >> On 03/30/2017 11:08 PM, Sanne Grinovero wrote: >>> I'm for "at discretion" and "avoid if not really needed" : not cool to >>> allocate objects for no reason. >>> >>> On 30 Mar 2017 16:57, "Radim Vansa" <rva...@redhat.com >>> <mailto:rva...@redhat.com>> wrote: >>> >>> Hi, >>> >>> I was wondering what's the common attitude towards using Optional in >>> APIs, and what naming pattern should we use. As an example, I dislike >>> calling >>> >>> if (entry.getMetadata() != null && entry.getMetadata().version() >>> != null) { >>> foo.use(entry.getMetadata().version()) >>> } >>> >>> where I could just do >>> >>> entry.metadata().flatMap(Metadata::optionalVersion).ifPresent(foo::use) >>> >>> Here I have proposed metadata() method returning Optional<Metadata> >>> (regular getter method is called getMetadata()) and annoying >>> optionalVersion() as version() is the regular getter. >>> >>> Shall we adopt some common stance (use/don't use/use at developer's >>> discretion) and naming conventions? Is it acceptable to start adding >>> >>> default Optional<Foo> foo() { Optional.ofNullable(getFoo()); } >>> >>> whenever we feel the urge to chain Optionals? >>> >>> Radim >>> >>> -- >>> Radim Vansa <rva...@redhat.com <mailto:rva...@redhat.com>> >>> JBoss Performance Team >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> <https://lists.jboss.org/mailman/listinfo/infinispan-dev> >>> >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> > > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev