Feedback on LW1 EAR

Thu Aug 23 12:38:43 UTC 2018

Yes, indeed you cannot call any lambda defined inside in a  ValueClass.
Playing a bit with breakpoint, it seems that curiously enough toString()
method on ValueClass (the automatically created one I mean) is using a
lambda without problem, probably because the lambda is defined somewhere
else.
I've also realized that I have no idea how would the binary compatibility
of a TypeValue be considered...

Thanks

Uberto

On Thu, 23 Aug 2018 at 11:54, Remi Forax <forax at univ-mlv.fr> wrote:

> Hi Uberto,
>
> ----- Mail original -----
> > De: "Uberto Barbini" <uberto.gama at gmail.com>
> > À: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> > Envoyé: Mercredi 22 Août 2018 17:14:48
> > Objet: Re: Feedback on LW1 EAR
>
> > Hi Srikanth,
> >
> > thanks for your illuminating reply.
> >
> > Introducing ValueTypes on others projects I found another curious issue,
> > seems more a javac issue but not sure.
> > concurrentHashMap.computeIfPresent (and the other similar methods) raise
> an
> > error if the map is inside a ValueType. Other map methods (like the
> > commented code) works fine.
>
> It's more a bug for Mandy, i.e. it's a JDK issue and not a compiler issue.
> When creating the lambda proxy, the object that will implement the
> functional interface and redirect the call to the lambda body,
> we have forgotten the case where the lambda body is itself declared in a
> value type.
>
> A simple code like below reproduces the issue.
>
> public __ByValue class LambdaDesugar {
>   private final int value;
>   public LambdaDesugar() { this.value = 0; }
>
>   public static void main(String[] args) {
>     Runnable r = () -> {
>       System.out.println("hello lambda inside a value type");
>     };
>     r.run();
>   }
> }
>
> cheers,
> Rémi
>
> >
> >
> > __ByValue public class UserAccounts {
> >
> >    public final Map<String, Double> accounts = new ConcurrentHashMap<>();
> >
> >    public void addReturnToUser(String userName, double amount){
> >
> > //        Double prev = accounts.get(userName);
> > //        if ( prev != null) {
> > //            accounts.put(userName, amount + prev);
> > //        }
> >        accounts.computeIfPresent(userName, (String u, Double a) -> amount
> > + a);
> >    }
> > ...
> >
> > (full code here
> >
> https://github.com/uberto/restApiCalculator/blob/valhalla/src/main/java/com/gamasoft/model/UserAccounts.java
> > )
> >
> > ---- Error
> > java.lang.IncompatibleClassChangeError: constant pool
> > com.gamasoft.model.UserAccounts$$Lambda$29/0x00000008000ba440
> inconsistent
> > value type: com.gamasoft.model.UserAccounts
> >
> > at
> >
> java.base/java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1836)
> > at com.gamasoft.model.UserAccounts.addReturnToUser(UserAccounts.java:27)
> > at
> >
> com.gamasoft.model.CompoundInterestTest.addReturnToUserAccount(CompoundInterestTest.java:55)
> > ...
> > Process finished with exit code 255
> >
> >
> >
> >
> >
> >
> >> In slightly longer term, we are also asking the question whether ==
> >> should simply be translated into the equals method call by javac where
> >> it can statically discern the operands to be values.
> >>
> >
> > For what is worth, this solution sounds very attractive and promising to
> me.
> > Maybe the same could be extended to some other operands as well... :)))
> >
> >
> >> > 5) I saw that I can override toString() and call super.toString() to
> have
> >> > the standard Object behavior.
> >> This should have been rejected by javac. That it is not is a defect I
> >> would say.
> >>
> >
> > Ok makes sense. I found being able to call on Object base methods is a
> bit
> > confusing.
> >
> >
> > Uberto
> >
> >
> >
> >
> >
> >
> >
> >> Date: Mon, 20 Aug 2018 10:41:15 +0200
> >> From: Tobias Hartmann <tobias.hartmann at oracle.com>
> >> To: Uberto Barbini <uberto.gama at gmail.com>,
> >>         valhalla-dev at openjdk.java.net
> >> Subject: Re: Feedback on LW1 EAR
> >> Message-ID: <82c3335c-147a-bfdd-e24e-2598f25568ed at oracle.com>
> >> Content-Type: text/plain; charset=utf-8
> >>
> >> Hi Uberto,
> >>
> >> first of all, thanks a lot for trying out LW1 EA and for reporting these
> >> issues!
> >>
> >> The crash is a bug in the just-in-time (JIT) compiler when compiling the
> >> WatchV:equals method, I've
> >> filed [1] and will work on a fix.
> >>
> >> As a temporary workaround you can disable JIT compilation of the
> affected
> >> method via
> >> -XX:CompileCommand=exclude,"Knapsack\$WatchV::equals" or disable JIT
> >> compilation altogether by
> >> adding the -Xint command line flag (unfortunately, both options will
> slow
> >> down execution a lot but
> >> it should be good enough for non-performance testing).
> >>
> >> Thanks,
> >> Tobias
> >>
> >> [1] https://bugs.openjdk.java.net/browse/JDK-8209687
> >>
> >>
> >> On 18.08.2018 12:40, Uberto Barbini wrote:
> >> > 5) I saw that I can override toString() and call super.toString() to
> have
> >> > the standard Object behavior. I wonder if there will be some kind of
> base
> >> > class for all ValueTypes or not.
> >> >
> >> >
> >> > Then I've tried to replace some immutable classes into Value Types use
> >> them
> >> > in my other projects.
> >> > The main hindrance has been the missing support for generics.
> >> > As workaround I've created a interface and based the collection on the
> >> > interface. It worked in a few projects but I had a Fatal Error on a
> >> simple
> >> > algorithm. I've tried to understand the exact problem but the same
> code
> >> > seems to work as standalone project... If it's something worth
> >> > investigating I can dig it more
> >> >
> >> >
> >>
> https://github.com/uberto/eopi/blob/ValhallaLW01/src/test/java/com/gamasoft/eopi/cap17_DynamicProgramming/KnapsackTest.java
> >> >
> >> >
> >> > #
> >> > # A fatal error has been detected by the Java Runtime Environment:
> >> > #
> >> > #  SIGSEGV (0xb) at pc=0x00007f08c3d648aa, pid=18399, tid=18426
> >> > #
> >> > # JRE version: OpenJDK Runtime Environment (11.0) (build
> >> > 11-lworldea+0-2018-07-30-1734349.david.simms.valhalla)
> >> > # Java VM: OpenJDK 64-Bit Server VM
> >> > (11-lworldea+0-2018-07-30-1734349.david.simms.valhalla, mixed mode,
> >> > compressed oops, g1 gc, linux-amd64)
> >> > # Problematic frame:
> >> > # V  [libjvm.so+0x4148aa]  AddPNode::Value(PhaseGVN*) const+0x7a
> >> > #
> >> > # No core dump will be written. Core dumps have been disabled. To
> enable
> >> > core dumping, try "ulimit -c unlimited" before starting Java again
> >> > #
> >> > # If you would like to submit a bug report, please visit:
> >> > #   http://bugreport.java.com/bugreport/crash.jsp
> >> > #
> >>
> >>
> >> End of valhalla-dev Digest, Vol 48, Issue 13
> >> ********************************************
>