From forax at univ-mlv.fr  Sat May  2 14:31:51 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 02 May 2015 16:31:51 +0200
Subject: Implementing VarHandle
In-Reply-To: <11C8B557-1D8D-4BC4-B1B2-E6364D507AAA@oracle.com>
References: <552A870C.6030208@univ-mlv.fr>
	<11C8B557-1D8D-4BC4-B1B2-E6364D507AAA@oracle.com>
Message-ID: <5544DFD7.9010709@univ-mlv.fr>

Hi Brian,

On 04/19/2015 02:06 PM, Brian Goetz wrote:
> Thanks Remi.
>
> I?d like to separate this discussion into two components: implementation and API.  Let?s talk about API first.  We did give a fair amount of thought to the sigpoly-vs-typesafe API question.
>
> VarHandles allow you to abstract data access over several dimensions:
>   - location kind: static field, instance field, array element, native pointer, etc
>   - variable type: int, long, Object, etc
>   - access kind: relaxed, ordered, volatile, etc
>
> Both your approach and ours follow the same route for access kind: separate methods for each kind of access.
>
> Your approach unrolls the variable type dimension as well; this is a tradeoff of client-side type-safety for API surface area.  There?s a valid discussion to be had here about the pros and cons of each.
>
> Where the biggest difference is in location kind.  Your approach is built around ?instance field? as being the preferred location kind, and levering the rest into that shape (i.e., use null as receiver for static fields.)  This is obviously great for instance fields, acceptable for static fields, bad for array elements, and probably not so good for native access.  To really get type safety, we?d probably have to add new interfaces for {Static,Instance,Array,Native}VarHandle, further increasing the surface area of the API.  Also, this is very different from the approach taken by MH, where there is a single polymorphic invoke method, rather than n*m*k methods for different combinations of (kind, type, access).

I've voluntarily separated the cases Static/Instance from the cases 
Array/Native because while I start to have a good idea on how to make 
former calls safe and fast, i have no good answer about the later calls.
Moreover, the Array case has a non empty intersection with the Array 2.0 
proposal and I'm not sure how those two things mix together.

>
> The thing that pushed us over the edge is that value types are coming.  With value types, one can create type-safe, zero-cost, specialized wrappers for {Static,Instance,Array,Native}VarHandle<T> that wrap an underlying VH; because these wrappers can be values, they can provide type safety with no indirection or footprint costs.

All of these wrappers are specialized wrappers, or wrappers with a very 
specific semantics, some may have sense on value type, some don't, by 
example, a CAS require a specific hardware support so doing a CAS on any 
value type is impossible.

>   So it seemed better to provide a simple, clean, low-level API now that doesn?t make any assumptions, let the early adopters (mostly us) deal with the fact that type safety comes at runtime (just as with MHs), and later provide a clean set of value wrappers on top of it.

You can provide generic entry points that fails at runtime but given 
that those API calls are already tricky,
providing more methods but with a good javadoc is in my opinion better 
than a small clean API that nobody understand.

Anyway, the problem with your API is that for the purpose of the 
experimentation, you have to introduce a new concept inside Java the 
language, because currently the semantics of a polymorphic signature 
method is not the one you want for your API, and adding a new semantics 
just for the purpose of the experimentation doesn't worst the cost.

And if you still want to introduce a new semantics into Java, having a 
way to invoke invokedynamic in Java is the one you want :)

cheers,
R?mi

>    
>
> On Apr 12, 2015, at 4:54 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> Hi guys,
>> I was about to write a blog post explaining why i don't like the way VarHandle are currently implemented when it occurs to me that providing another implementation may be a more efficient to discuss about implementation.
>>
>> So my implementation is here,
>>   https://github.com/forax/varhandle2
>>
>> the API is typesafe, the implementation is runtime safe and i get mostly the same assembly code using unsafe or this VarHandle API.
>>
>> The idea is that there is no need to add more polymorphic signature methods, a good old Java method is enough if it using a method handle under the hood.
>> All the logic is described using method handles and the only logic written in Java is
>> 1) when to create such method handle (the first time a method is called),
>>     it works like invokedynamic but the method handles are stable instead of being constant.
>> 2) how to link all things together to do nullcheck, atomic operation and post operation (like fence or sum).
>>
>> cheers,
>> R?mi
>>
>>
>>



From brian.goetz at oracle.com  Thu May  7 20:18:49 2015
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 07 May 2015 20:18:49 +0000
Subject: hg: valhalla/valhalla/jdk: Fix bug in handling long/double
	specializations, detected during prespecialization
Message-ID: <201505072018.t47KIo08009566@aojmv0008.oracle.com>

Changeset: b7a586b5fe0e
Author:    briangoetz
Date:      2015-05-07 16:18 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/b7a586b5fe0e

Fix bug in handling long/double specializations, detected during prespecialization

! src/java.base/share/classes/valhalla/specializer/Prespecialize.java
! src/java.base/share/classes/valhalla/specializer/Specializer.java



From brian.goetz at oracle.com  Thu May  7 22:06:11 2015
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 07 May 2015 22:06:11 +0000
Subject: hg: valhalla/valhalla/jdk: Specializer bug: new int[3][] was not
	being properly handled
Message-ID: <201505072206.t47M6CCx027205@aojmv0008.oracle.com>

Changeset: 29842bdb3fd8
Author:    briangoetz
Date:      2015-05-07 18:05 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/29842bdb3fd8

Specializer bug: new int[3][] was not being properly handled

! src/java.base/share/classes/valhalla/specializer/Specializer.java
! test/valhalla/test/valhalla/specializer/MiscManglingsTest.java



From brian.goetz at oracle.com  Thu May  7 22:13:41 2015
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Thu, 07 May 2015 22:13:41 +0000
Subject: hg: valhalla/valhalla/jdk: Remove stray debugging println
Message-ID: <201505072213.t47MDf5M028362@aojmv0008.oracle.com>

Changeset: e026694cf1a6
Author:    briangoetz
Date:      2015-05-07 18:13 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/e026694cf1a6

Remove stray debugging println

! src/java.base/share/classes/valhalla/specializer/Specializer.java



From maurizio.cimadamore at oracle.com  Fri May  8 16:20:04 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 08 May 2015 16:20:04 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: certain symbols are not
	specialized.
Message-ID: <201505081620.t48GK4fB019057@aojmv0008.oracle.com>

Changeset: 1e4495ade29c
Author:    mcimadamore
Date:      2015-05-08 12:58 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/1e4495ade29c

Fix: certain symbols are not specialized.
If a class is non-specializable but one of its superclasses/superinterfaces is,
the specialization machinery should produce a specialized symbol for such a class.

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java



From brian.goetz at oracle.com  Fri May  8 16:33:36 2015
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Fri, 08 May 2015 16:33:36 +0000
Subject: hg: valhalla/valhalla/jdk: Initial run at anyfied Stream
	implementation,
	starting from the bottom up -- anyfied interfaces and base Task and
	Node classes, deleted remainder for now,
	will add them back as they are adapted. Playing fast-and-loose with
	binary compatibility for now.
Message-ID: <201505081633.t48GXbaV022268@aojmv0008.oracle.com>

Changeset: 6ac883c14908
Author:    briangoetz
Date:      2015-05-08 12:32 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/6ac883c14908

Initial run at anyfied Stream implementation, starting from the bottom up -- anyfied interfaces and base Task and Node classes, deleted remainder for now, will add them back as they are adapted.  Playing fast-and-loose with binary compatibility for now.

! src/java.base/share/classes/java/anyutil/Spliterator.java
- src/java.base/share/classes/java/anyutil/stream/AbstractPipeline.java
! src/java.base/share/classes/java/anyutil/stream/AbstractShortCircuitTask.java
- src/java.base/share/classes/java/anyutil/stream/AbstractSpinedBuffer.java
! src/java.base/share/classes/java/anyutil/stream/AbstractTask.java
- src/java.base/share/classes/java/anyutil/stream/DistinctOps.java
- src/java.base/share/classes/java/anyutil/stream/DoublePipeline.java
- src/java.base/share/classes/java/anyutil/stream/FindOps.java
- src/java.base/share/classes/java/anyutil/stream/ForEachOps.java
- src/java.base/share/classes/java/anyutil/stream/IntPipeline.java
- src/java.base/share/classes/java/anyutil/stream/LongPipeline.java
- src/java.base/share/classes/java/anyutil/stream/MatchOps.java
! src/java.base/share/classes/java/anyutil/stream/Node.java
! src/java.base/share/classes/java/anyutil/stream/Nodes.java
! src/java.base/share/classes/java/anyutil/stream/PipelineHelper.java
- src/java.base/share/classes/java/anyutil/stream/ReduceOps.java
- src/java.base/share/classes/java/anyutil/stream/ReferencePipeline.java
! src/java.base/share/classes/java/anyutil/stream/Sink.java
- src/java.base/share/classes/java/anyutil/stream/SliceOps.java
- src/java.base/share/classes/java/anyutil/stream/SortedOps.java
! src/java.base/share/classes/java/anyutil/stream/SpinedBuffer.java
- src/java.base/share/classes/java/anyutil/stream/StreamShape.java
! src/java.base/share/classes/java/anyutil/stream/StreamSpliterators.java
! src/java.base/share/classes/java/anyutil/stream/StreamSupport.java
! src/java.base/share/classes/java/anyutil/stream/Streams.java
! src/java.base/share/classes/java/anyutil/stream/TerminalOp.java
! src/java.base/share/classes/java/anyutil/stream/TerminalSink.java



From brian.goetz at oracle.com  Sun May 10 14:49:00 2015
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Sun, 10 May 2015 14:49:00 +0000
Subject: hg: valhalla/valhalla/jdk: Anyfied version of terminal ops classes
Message-ID: <201505101449.t4AEn0oC007698@aojmv0008.oracle.com>

Changeset: a10cef9c99eb
Author:    briangoetz
Date:      2015-05-10 10:48 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/a10cef9c99eb

Anyfied version of terminal ops classes

! src/java.base/share/classes/java/anyutil/function/ObjIntConsumer.java
+ src/java.base/share/classes/java/anyutil/stream/FindOps.java
+ src/java.base/share/classes/java/anyutil/stream/ForEachOps.java
+ src/java.base/share/classes/java/anyutil/stream/MatchOps.java
! src/java.base/share/classes/java/anyutil/stream/PipelineHelper.java
+ src/java.base/share/classes/java/anyutil/stream/ReduceOps.java
! src/java.base/share/classes/java/anyutil/stream/TerminalOp.java



From paul.sandoz at oracle.com  Tue May 12 08:02:16 2015
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Tue, 12 May 2015 08:02:16 +0000
Subject: hg: valhalla/valhalla/jdk: Moved the named class to static member
	class as a temporary
Message-ID: <201505120802.t4C82GOG027068@aojmv0008.oracle.com>

Changeset: d5e7660d0f50
Author:    psandoz
Date:      2015-05-12 10:01 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/d5e7660d0f50

Moved the named class to static member class as a temporary
workaround to ensure the specializer runs without error
when constructing the JDK images.

! src/java.base/share/classes/java/anyutil/stream/ReduceOps.java



From maurizio.cimadamore at oracle.com  Tue May 12 18:19:32 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 12 May 2015 18:19:32 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: getfield inside local inner
	class missing BytecodeMapping entry.
Message-ID: <201505121819.t4CIJWri007612@aojmv0008.oracle.com>

Changeset: 4f7c56237d8c
Author:    mcimadamore
Date:      2015-05-12 19:19 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/4f7c56237d8c

Fix: getfield inside local inner class missing BytecodeMapping entry.
Overhauled the BytecodeMappingHarness test to execute more precise bytecode-level checks.

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java
! test/tools/javac/valhalla/typespec/items/BytecodeMappingHarness.java
! test/tools/javac/valhalla/typespec/items/tests/TestNestedGenerics.java



From paul.sandoz at oracle.com  Wed May 13 09:46:26 2015
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 13 May 2015 09:46:26 +0000
Subject: hg: valhalla/valhalla/jdk: Revert to inner class now the compiler has
	been fixed to
Message-ID: <201505130946.t4D9kQFv019990@aojmv0008.oracle.com>

Changeset: 79e35144df9e
Author:    psandoz
Date:      2015-05-13 11:46 +0200
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/79e35144df9e

Revert to inner class now the compiler has been fixed to
generate correct byte code mappings for getfield.

! src/java.base/share/classes/java/anyutil/stream/ReduceOps.java



From simon at ochsenreither.de  Tue May 19 15:15:30 2015
From: simon at ochsenreither.de (Simon Ochsenreither)
Date: Tue, 19 May 2015 17:15:30 +0200 (CEST)
Subject: Are value types supposed to work at all currently?
Message-ID: <1685000089.81157.1432048530952.JavaMail.open-xchange@srv005.service.ps-server.net>

Hi,
 
I'm currently working on my talk about value types for tomorrow, and it seems
that currently even the most basic value types are broken:
 
public final __ByValue class Cell {
  public Cell(int value) {
    this.value = value;
  }
  public final int value;
}
 
/home/soc/Development/valhalla/build/linux-x86_64-normal-server-release/images/jdk/bin/java
 Cell
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.VerifyError: Bad instruction: cb
Exception Details:
  Location:
    Cell.<init>(I)V @0: fast_agetfield
  Reason:
    Error exists in the bytecode
  Bytecode:
    0000000: cb00 b700 01cb 001b b500 02b1          

    at java.lang.Class.getDeclaredMethods0(Native Method)
    at java.lang.Class.privateGetDeclaredMethods(Class.java:2747)
    at java.lang.Class.privateGetMethodRecursive(Class.java:3092)
    at java.lang.Class.getMethod0(Class.java:3062)
    at java.lang.Class.getMethod(Class.java:1830)
    at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:567)
    at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:534)
 
Is this expected? Is there some working branch/revision somewhere which is
usable for a demo?
 
Thanks!
 
Simon
 
PS: What's the suggested way to inspect the "bytecode" of specialized classes
(the one after the generic type is instantiated)?

From brian.goetz at oracle.com  Tue May 19 15:18:34 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 19 May 2015 11:18:34 -0400
Subject: Are value types supposed to work at all currently?
In-Reply-To: <1685000089.81157.1432048530952.JavaMail.open-xchange@srv005.service.ps-server.net>
References: <1685000089.81157.1432048530952.JavaMail.open-xchange@srv005.service.ps-server.net>
Message-ID: <555B544A.9000403@oracle.com>

No, our primary focus in the compiler has been on generics.  The support 
in the compiler for value types has almost certainly decayed (but there 
was not much there to start with.)

Cheers,
-Brian

On 5/19/2015 11:15 AM, Simon Ochsenreither wrote:
> Hi,
>
> I'm currently working on my talk about value types for tomorrow, and it seems
> that currently even the most basic value types are broken:
>
> public final __ByValue class Cell {
>    public Cell(int value) {
>      this.value = value;
>    }
>    public final int value;
> }
>
> /home/soc/Development/valhalla/build/linux-x86_64-normal-server-release/images/jdk/bin/java
>   Cell
> Error: A JNI error has occurred, please check your installation and try again
> Exception in thread "main" java.lang.VerifyError: Bad instruction: cb
> Exception Details:
>    Location:
>      Cell.<init>(I)V @0: fast_agetfield
>    Reason:
>      Error exists in the bytecode
>    Bytecode:
>      0000000: cb00 b700 01cb 001b b500 02b1
>
>      at java.lang.Class.getDeclaredMethods0(Native Method)
>      at java.lang.Class.privateGetDeclaredMethods(Class.java:2747)
>      at java.lang.Class.privateGetMethodRecursive(Class.java:3092)
>      at java.lang.Class.getMethod0(Class.java:3062)
>      at java.lang.Class.getMethod(Class.java:1830)
>      at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:567)
>      at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:534)
>
> Is this expected? Is there some working branch/revision somewhere which is
> usable for a demo?
>
> Thanks!
>
> Simon
>
> PS: What's the suggested way to inspect the "bytecode" of specialized classes
> (the one after the generic type is instantiated)?
>


From maurizio.cimadamore at oracle.com  Tue May 19 15:21:57 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 19 May 2015 16:21:57 +0100
Subject: Are value types supposed to work at all currently?
In-Reply-To: <1685000089.81157.1432048530952.JavaMail.open-xchange@srv005.service.ps-server.net>
References: <1685000089.81157.1432048530952.JavaMail.open-xchange@srv005.service.ps-server.net>
Message-ID: <555B5515.9080509@oracle.com>

Value types are currently not supported - the compiler will swalow them 
and attempt to generate reasonable bytecode - but the VM changes to deal 
with this bytecode are not in the repository.

Maurizio

On 19/05/15 16:15, Simon Ochsenreither wrote:
> Hi,
>   
> I'm currently working on my talk about value types for tomorrow, and it seems
> that currently even the most basic value types are broken:
>   
> public final __ByValue class Cell {
>    public Cell(int value) {
>      this.value = value;
>    }
>    public final int value;
> }
>   
> /home/soc/Development/valhalla/build/linux-x86_64-normal-server-release/images/jdk/bin/java
>   Cell
> Error: A JNI error has occurred, please check your installation and try again
> Exception in thread "main" java.lang.VerifyError: Bad instruction: cb
> Exception Details:
>    Location:
>      Cell.<init>(I)V @0: fast_agetfield
>    Reason:
>      Error exists in the bytecode
>    Bytecode:
>      0000000: cb00 b700 01cb 001b b500 02b1
>
>      at java.lang.Class.getDeclaredMethods0(Native Method)
>      at java.lang.Class.privateGetDeclaredMethods(Class.java:2747)
>      at java.lang.Class.privateGetMethodRecursive(Class.java:3092)
>      at java.lang.Class.getMethod0(Class.java:3062)
>      at java.lang.Class.getMethod(Class.java:1830)
>      at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:567)
>      at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:534)
>   
> Is this expected? Is there some working branch/revision somewhere which is
> usable for a demo?
>   
> Thanks!
>   
> Simon
>   
> PS: What's the suggested way to inspect the "bytecode" of specialized classes
> (the one after the generic type is instantiated)?



From simon at ochsenreither.de  Tue May 19 15:33:14 2015
From: simon at ochsenreither.de (Simon Ochsenreither)
Date: Tue, 19 May 2015 17:33:14 +0200 (CEST)
Subject: Are value types supposed to work at all currently?
In-Reply-To: <555B544A.9000403@oracle.com>
References: <1685000089.81157.1432048530952.JavaMail.open-xchange@srv005.service.ps-server.net>
	<555B544A.9000403@oracle.com>
Message-ID: <2094429441.81322.1432049594414.JavaMail.open-xchange@srv005.service.ps-server.net>

Thanks Brian, thanks Maurizio!
 
I guess I will have to change the concept of the talk for tomorrow then...
Do you think there will be any considerable changes to the state of the
implementation of value types until 8th of June? (ScalaDays Amsterdam)
Or should I assume that there is nothing I can run, and plan the talk
accordingly?
 
Can you speak about whether the bytecode emitted by javac for value types is
roughly what we will probably end up?
 
Thanks,
 
Simon

From brian.goetz at oracle.com  Tue May 19 15:41:33 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 19 May 2015 11:41:33 -0400
Subject: Are value types supposed to work at all currently?
In-Reply-To: <2094429441.81322.1432049594414.JavaMail.open-xchange@srv005.service.ps-server.net>
References: <1685000089.81157.1432048530952.JavaMail.open-xchange@srv005.service.ps-server.net>	<555B544A.9000403@oracle.com>
	<2094429441.81322.1432049594414.JavaMail.open-xchange@srv005.service.ps-server.net>
Message-ID: <555B59AD.4040301@oracle.com>

> I guess I will have to change the concept of the talk for tomorrow then...
> Do you think there will be any considerable changes to the state of the
> implementation of value types until 8th of June? (ScalaDays Amsterdam)
> Or should I assume that there is nothing I can run, and plan the talk
> accordingly?

That's what we've been doing :)

There's lots to talk about in terms of possible directions.  You can 
easily talk for 10-15 minutes just on the hardware trends motivating the 
need for better control over flattening, and the toxicity of pervasive 
identity.

> Can you speak about whether the bytecode emitted by javac for value types is
> roughly what we will probably end up?

It is definitely too early to tell.  What is emitted now is definitely 
not right (it's all a* bytecodes at the back end, so we model values 
with classes, the only thing the compiler prototype does now is enforce 
things like "can't lock on a value" and "can't assign null to a value.") 
  The real question for values is, what *will* the bytecodes look like? 
  We're investigating several options, including the one laid out in the 
SotV.




From simon at ochsenreither.de  Thu May 21 14:03:48 2015
From: simon at ochsenreither.de (Simon Ochsenreither)
Date: Thu, 21 May 2015 16:03:48 +0200
Subject: Are value types supposed to work at all currently?
In-Reply-To: <555B59AD.4040301@oracle.com>
References: <1685000089.81157.1432048530952.JavaMail.open-xchange@srv005.service.ps-server.net>
	<555B544A.9000403@oracle.com>
	<2094429441.81322.1432049594414.JavaMail.open-xchange@srv005.service.ps-server.net>
	<555B59AD.4040301@oracle.com>
Message-ID: <555DE5C4.5070401@ochsenreither.de>

Hi Brian, hi Maurizio,

here are the slides I used for my talk yesterday: https://docs.google.com/presentation/d/1mkBEHmaxkiebh-r79xdSlZsqghWsZREYaBDN48Ex9xY/pub?start=false&loop=false&delayms=3000

I hope they accurately reflected the current situation as much as possible.
Corrections and comments welcome! (The talk at ScalaDays will likely look quite differently, though.)

I finished the slides a few minutes before the talk, so they are quite rough.
One thing I would certainly add are all the boxing considerations, which were discussed at the meetup, but are missing on the slides.

Thanks!

Bye,

Simon


From vitalyd at gmail.com  Thu May 21 14:19:02 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 21 May 2015 10:19:02 -0400
Subject: Are value types supposed to work at all currently?
In-Reply-To: <555DE5C4.5070401@ochsenreither.de>
References: <1685000089.81157.1432048530952.JavaMail.open-xchange@srv005.service.ps-server.net>
	<555B544A.9000403@oracle.com>
	<2094429441.81322.1432049594414.JavaMail.open-xchange@srv005.service.ps-server.net>
	<555B59AD.4040301@oracle.com> <555DE5C4.5070401@ochsenreither.de>
Message-ID: <CAHjP37GTspqOBJfOtaVE7BJt9hN-YWjtgcCxTRwG1d_MK5CD5w@mail.gmail.com>

Hi Simon,

On the 1st slide that talks about object overhead, it may be worthwhile to
mention that the overhead stated there is for 32bit.  On 64bit, the header
is either 12 or 16 bytes, depending on whether compressed oops are used or
not (in the case of 12 bytes with compressed oops, the 4 byte alignment gap
can be used to lay out a suitable field in there as well, AFAIK).  Also,
that's Hotspot specific, other JVMs can use different representation/layout.



On Thu, May 21, 2015 at 10:03 AM, Simon Ochsenreither <
simon at ochsenreither.de> wrote:

> Hi Brian, hi Maurizio,
>
> here are the slides I used for my talk yesterday:
> https://docs.google.com/presentation/d/1mkBEHmaxkiebh-r79xdSlZsqghWsZREYaBDN48Ex9xY/pub?start=false&loop=false&delayms=3000
>
> I hope they accurately reflected the current situation as much as possible.
> Corrections and comments welcome! (The talk at ScalaDays will likely look
> quite differently, though.)
>
> I finished the slides a few minutes before the talk, so they are quite
> rough.
> One thing I would certainly add are all the boxing considerations, which
> were discussed at the meetup, but are missing on the slides.
>
> Thanks!
>
> Bye,
>
> Simon
>


From brian.goetz at oracle.com  Thu May 21 15:09:04 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 21 May 2015 11:09:04 -0400
Subject: Are value types supposed to work at all currently?
In-Reply-To: <555DE5C4.5070401@ochsenreither.de>
References: <1685000089.81157.1432048530952.JavaMail.open-xchange@srv005.service.ps-server.net>	<555B544A.9000403@oracle.com>	<2094429441.81322.1432049594414.JavaMail.open-xchange@srv005.service.ps-server.net>	<555B59AD.4040301@oracle.com>
	<555DE5C4.5070401@ochsenreither.de>
Message-ID: <555DF510.9010002@oracle.com>

> I hope they accurately reflected the current situation as much as possible.
> Corrections and comments welcome! (The talk at ScalaDays will likely look quite differently, though.)

Nice summary.  I think its fairly captures where we are now.



From volker.simonis at gmail.com  Thu May 21 20:51:42 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 21 May 2015 23:51:42 +0300
Subject: Are value types supposed to work at all currently?
In-Reply-To: <555DE5C4.5070401@ochsenreither.de>
References: <1685000089.81157.1432048530952.JavaMail.open-xchange@srv005.service.ps-server.net>
	<555B544A.9000403@oracle.com>
	<2094429441.81322.1432049594414.JavaMail.open-xchange@srv005.service.ps-server.net>
	<555B59AD.4040301@oracle.com> <555DE5C4.5070401@ochsenreither.de>
Message-ID: <CA+3eh13Nb-G-6RM-vEGrct20LZZp85e1fObfDF2TL3Hiv3rYgw@mail.gmail.com>

Hi Simon,

it may be worth mentioning that there are other projects/approaches like
IBM's PackedObjects or Gil Tene's ObjectLayout which solve at least a part
of the problems which are addressed more generally by ValueTypes.

I compared them in a talk that I was giving at FOSDEM (did we actually met
there?) and JPoint: http://progdoc.de/papers/JPoint2015/jpoint2015.html

Incidentally I'll also give this talk tomorrow at JEE Conf in Kiev so if
you should be around you're very welcome;)

Regards,
Volker

On Thursday, May 21, 2015, Simon Ochsenreither <simon at ochsenreither.de>
wrote:

> Hi Brian, hi Maurizio,
>
> here are the slides I used for my talk yesterday:
> https://docs.google.com/presentation/d/1mkBEHmaxkiebh-r79xdSlZsqghWsZREYaBDN48Ex9xY/pub?start=false&loop=false&delayms=3000
>
> I hope they accurately reflected the current situation as much as possible.
> Corrections and comments welcome! (The talk at ScalaDays will likely look
> quite differently, though.)
>
> I finished the slides a few minutes before the talk, so they are quite
> rough.
> One thing I would certainly add are all the boxing considerations, which
> were discussed at the meetup, but are missing on the slides.
>
> Thanks!
>
> Bye,
>
> Simon
>


From maurizio.cimadamore at oracle.com  Mon May 25 11:56:14 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 25 May 2015 11:56:14 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: missing synthetic cast for
	specialized generic calls
Message-ID: <201505251156.t4PBuEpY006005@aojmv0008.oracle.com>

Changeset: be15fb529cd3
Author:    mcimadamore
Date:      2015-05-25 12:55 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/be15fb529cd3

Fix: missing synthetic cast for specialized generic calls
Fix: wrong bytecode mapping generated for certain specialized calls

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java
+ test/tools/javac/valhalla/typespec/Inference07.java



From peter.levart at gmail.com  Mon May 25 16:26:00 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 25 May 2015 18:26:00 +0200
Subject: Are value types supposed to work at all currently?
In-Reply-To: <CA+3eh13Nb-G-6RM-vEGrct20LZZp85e1fObfDF2TL3Hiv3rYgw@mail.gmail.com>
References: <1685000089.81157.1432048530952.JavaMail.open-xchange@srv005.service.ps-server.net>	<555B544A.9000403@oracle.com>	<2094429441.81322.1432049594414.JavaMail.open-xchange@srv005.service.ps-server.net>	<555B59AD.4040301@oracle.com>
	<555DE5C4.5070401@ochsenreither.de>
	<CA+3eh13Nb-G-6RM-vEGrct20LZZp85e1fObfDF2TL3Hiv3rYgw@mail.gmail.com>
Message-ID: <55634D18.7030706@gmail.com>

Hi,

I've been playing with the idea of Packed Objects over a weekend. Not 
hacking the VM like IBM, but using pure Java (with a little help from 
Unsafe ;-). Here's what I came up with:

     https://github.com/plevart/PackedObjects

It's interesting from the semantics standpoint alone. Mutating / viewing 
operations are possible to construct and compose in a generic way. 
Packed Objects are not value types, but can be used as value types. They 
can also be used to mutate parts of "values" in a well defined way. 
Additional features that come to mind besides those already implemented 
in above prototype are:
- read-only views of components of a packed object / array
- mapping native memory instead of heap as an option (like ByteBuffer)
- atomic operations on primitive components (CAS, GAS, GAA, ...)
- "view" locks - locking a range occupied by a component to allow 
exclusive accesses to a (sub/super)component.

Regards, Peter

On 05/21/2015 10:51 PM, Volker Simonis wrote:
> Hi Simon,
>
> it may be worth mentioning that there are other projects/approaches like
> IBM's PackedObjects or Gil Tene's ObjectLayout which solve at least a part
> of the problems which are addressed more generally by ValueTypes.
>
> I compared them in a talk that I was giving at FOSDEM (did we actually met
> there?) and JPoint: http://progdoc.de/papers/JPoint2015/jpoint2015.html
>
> Incidentally I'll also give this talk tomorrow at JEE Conf in Kiev so if
> you should be around you're very welcome;)
>
> Regards,
> Volker
>
> On Thursday, May 21, 2015, Simon Ochsenreither <simon at ochsenreither.de>
> wrote:
>
>> Hi Brian, hi Maurizio,
>>
>> here are the slides I used for my talk yesterday:
>> https://docs.google.com/presentation/d/1mkBEHmaxkiebh-r79xdSlZsqghWsZREYaBDN48Ex9xY/pub?start=false&loop=false&delayms=3000
>>
>> I hope they accurately reflected the current situation as much as possible.
>> Corrections and comments welcome! (The talk at ScalaDays will likely look
>> quite differently, though.)
>>
>> I finished the slides a few minutes before the talk, so they are quite
>> rough.
>> One thing I would certainly add are all the boxing considerations, which
>> were discussed at the meetup, but are missing on the slides.
>>
>> Thanks!
>>
>> Bye,
>>
>> Simon
>>



From brian.goetz at oracle.com  Mon May 25 23:20:03 2015
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Mon, 25 May 2015 23:20:03 +0000
Subject: hg: valhalla/valhalla/jdk: 2 new changesets
Message-ID: <201505252320.t4PNK3lI002743@aojmv0008.oracle.com>

Changeset: b9c8c23385c5
Author:    briangoetz
Date:      2015-05-25 19:19 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/b9c8c23385c5

Various specializer bugfixes -- better hierarchy analysis for generic methods

! src/java.base/share/classes/java/anyutil/stream/Stream.java
! src/java.base/share/classes/java/lang/invoke/GenericMethodSpecializer.java
! src/java.base/share/classes/valhalla/specializer/Specializer.java

Changeset: 8461f3d86cfd
Author:    briangoetz
Date:      2015-05-25 19:19 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/8461f3d86cfd

Merge




From brian.goetz at oracle.com  Wed May 27 22:31:57 2015
From: brian.goetz at oracle.com (brian.goetz at oracle.com)
Date: Wed, 27 May 2015 22:31:57 +0000
Subject: hg: valhalla/valhalla/jdk: When specializing methods, if we encounter
	a Bridge attribute, follow bridge attribute to find bridgee to
	specialize;
	when specializing generic methods, if the method body is not in the
	receiver class, do a supertype hierarchy walk to find the
	corresponding class specialization parameters
Message-ID: <201505272231.t4RMVvtA012472@aojmv0008.oracle.com>

Changeset: a0b483fee3f1
Author:    briangoetz
Date:      2015-05-27 18:24 -0400
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/a0b483fee3f1

When specializing methods, if we encounter a Bridge attribute, follow bridge attribute to find bridgee to specialize; when specializing generic methods, if the method body is not in the receiver class, do a supertype hierarchy walk to find the corresponding class specialization parameters

! src/java.base/share/classes/java/anyutil/stream/FindOps.java
! src/java.base/share/classes/java/anyutil/stream/ForEachOps.java
! src/java.base/share/classes/java/anyutil/stream/PipelineHelper.java
! src/java.base/share/classes/java/anyutil/stream/StreamOpFlag.java
! src/java.base/share/classes/java/lang/invoke/GenericMethodSpecializer.java
+ src/java.base/share/classes/valhalla/specializer/BridgeAttribute.java
! src/java.base/share/classes/valhalla/specializer/SignatureSpecializer.java
! src/java.base/share/classes/valhalla/specializer/Specializer.java



From maurizio.cimadamore at oracle.com  Thu May 28 11:34:48 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 28 May 2015 11:34:48 +0000
Subject: hg: valhalla/valhalla/langtools: Fix: normalize specializer
	signatures containing captured types
Message-ID: <201505281134.t4SBYmku005948@aojmv0008.oracle.com>

Changeset: c5b28bea0a2b
Author:    mcimadamore
Date:      2015-05-28 12:34 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/c5b28bea0a2b

Fix: normalize specializer signatures containing captured types
Tweaked internal routines to handle captured types pointing to avars.
Added normalization step to remove captured types from BytecodeMapping attribute signatures.
Added tests

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java
+ test/tools/javac/valhalla/typespec/TestCapture.java
+ test/tools/javac/valhalla/typespec/items/tests/TestCapture.java



From maurizio.cimadamore at oracle.com  Fri May 29 15:52:18 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 29 May 2015 15:52:18 +0000
Subject: hg: valhalla/valhalla/langtools: Enhancement: add support for Bridge
	attribute.
Message-ID: <201505291552.t4TFqJLk018156@aojmv0008.oracle.com>

Changeset: b91634e5f051
Author:    mcimadamore
Date:      2015-05-29 16:51 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/b91634e5f051

Enhancement: add support for Bridge attribute.
Help specializer by emitting a Bridge attribute that points (through a MethodHandle) to the bridged method.

! src/jdk.compiler/share/classes/com/sun/tools/classfile/Attribute.java
+ src/jdk.compiler/share/classes/com/sun/tools/classfile/Bridge_attribute.java
! src/jdk.compiler/share/classes/com/sun/tools/classfile/ClassWriter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/jdk.compiler/share/classes/com/sun/tools/javap/AttributeWriter.java
! test/lib/annotations/annotations/classfile/ClassfileInspector.java
! test/tools/javac/MethodParameters/AttributeVisitor.java



From maurizio.cimadamore at oracle.com  Fri May 29 17:51:52 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 29 May 2015 17:51:52 +0000
Subject: hg: valhalla/valhalla/langtools: Enhancement: add support for anyfied
	lambdas
Message-ID: <201505291751.t4THprM6010203@aojmv0008.oracle.com>

Changeset: 761d199068c7
Author:    mcimadamore
Date:      2015-05-29 18:51 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/761d199068c7

Enhancement: add support for anyfied lambdas
* Overhaul boostrap static argument javac support
* Add new SpecializerSignature attribute
* Enhance BMAs for indy so that it also contains info for specialized static args
* Added smoke test

! src/jdk.compiler/share/classes/com/sun/tools/classfile/Attribute.java
! src/jdk.compiler/share/classes/com/sun/tools/classfile/ClassWriter.java
+ src/jdk.compiler/share/classes/com/sun/tools/classfile/SpecializerSignature_attribute.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/IndifierTranslator.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/SpecializeTypes.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java
! src/jdk.compiler/share/classes/com/sun/tools/javap/AttributeWriter.java
! test/lib/annotations/annotations/classfile/ClassfileInspector.java
! test/tools/javac/MethodParameters/AttributeVisitor.java
! test/tools/javac/lambda/TestInvokeDynamic.java
! test/tools/javac/valhalla/typespec/items/tests/TestLambda.java



From maurizio.cimadamore at oracle.com  Fri May 29 17:53:54 2015
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 29 May 2015 17:53:54 +0000
Subject: hg: valhalla/valhalla/jdk: Enhancement: Add support for
	specialization of BSM static arg entries.
Message-ID: <201505291753.t4THrtOZ010606@aojmv0008.oracle.com>

Changeset: f6d74cda2a7a
Author:    mcimadamore
Date:      2015-05-29 18:53 +0100
URL:       http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/f6d74cda2a7a

Enhancement: Add support for specialization of BSM static arg entries.

! src/java.base/share/classes/valhalla/specializer/Specializer.java