Re: RFE: Refactor java.util.Optional and add NonNull checks

2023-08-28 Thread Oleksii Kucheruk
Yes, it's 2 subclasses hierarchy. https://github.com/iselo/jdk-optional/tree/master/lib/src I'm open to learning about my pitfalls. # JMH version: 1.36 # VM version: JDK 20.0.2, Java HotSpot(TM) 64-Bit Server VM, 20.0.2+9-78 # VM invoker: /Library/Java/JavaVirtualMachines/jdk-20.jdk/Contents/Hom

Re: RFE: Refactor java.util.Optional and add NonNull checks

2023-08-28 Thread -
Can you share the benchmark code? Maybe C2 profiled class hierarchy, determined your optional only has 2 subclasses and can thus generate optimized machine code. Or maybe your benchmark is wrong that the result is not consumed by blackhole so the whole benchmark is moot. We need the code to make a

Re: RFE: Refactor java.util.Optional and add NonNull checks

2023-08-28 Thread Oleksii Kucheruk
Now it is clear. Sorry for the inconvenience. Thank you for your time. I appreciate. On Mon, 28 Aug 2023 at 2:03 PM Quân Anh Mai wrote: > Tbh I have a hard time understand what you are trying to convey. Please > write grammatically correct sentences with clear structure. > > I notice you attach

Re: RFE: Refactor java.util.Optional and add NonNull checks

2023-08-28 Thread Quân Anh Mai
Tbh I have a hard time understand what you are trying to convey. Please write grammatically correct sentences with clear structure. I notice you attach benchmark results but I don't see what was benchmarked to produce those results. Another point is that Value classes has not been delivered yet,

Re: RFE: Refactor java.util.Optional and add NonNull checks

2023-08-28 Thread Oleksii Kucheruk
Thank you Quân. All you saying guys make sense. Yes there is a difference calling methods by pointer and involving vtable. But one thing didn't came out of my head: If virtual dispatch dispatch is 10-time more expensive and polymorphism is a performance killer so how combinations of "return optio

Re: RFE: Refactor java.util.Optional and add NonNull checks

2023-08-28 Thread Quân Anh Mai
Hi, Polymorphism is a performance killer. Normally this does not matter much, but for thin wrappers such as Optional, this is one of the most important factor. Behaviour polymorphism requires virtual dispatch and prevents inlining. This is really detrimental, as simple operations such as a getter

Re: RFE: Refactor java.util.Optional and add NonNull checks

2023-08-24 Thread Oleksii Kucheruk
c-files/ValueBased.html > > > -- > > *From: *"Oleksii Kucheruk" > > *To: *"core-libs-dev" > > *Sent: *Wednesday, August 23, 2023 4:43:17 PM > *Subject: *RFE: Refactor java.util.Optional and add NonNull checks > >

Re: RFE: Refactor java.util.Optional and add NonNull checks

2023-08-23 Thread Roger Riggs
*From: *"Oleksii Kucheruk" *To: *"core-libs-dev" *Sent: *Wednesday, August 23, 2023 4:43:17 PM *Subject: *RFE: Refactor java.util.Optional and add NonNull checks Hi there. I have found that `ja

Re: RFE: Refactor java.util.Optional and add NonNull checks

2023-08-23 Thread Remi Forax
/20/docs/api/java.base/java/lang/doc-files/ValueBased.html > From: "Oleksii Kucheruk" > To: "core-libs-dev" > Sent: Wednesday, August 23, 2023 4:43:17 PM > Subject: RFE: Refactor java.util.Optional and add NonNull checks > Hi there. > I have found that `jav

RFE: Refactor java.util.Optional and add NonNull checks

2023-08-23 Thread Oleksii Kucheruk
Hi there. I have found that `java.util.Optional` is written procedural style and has `ifnonnull` checks in each method. I propose to refactor `Optional` in accordance to OOP-style. This will eliminates all unnecessary `if`-statements, removes duplications and reduces bytecode size more then twice.