Feedback on LW1 EAR

[Remi Forax]

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
>> ********************************************