hg: amber/amber/langtools: treating Intrinsics ldc as a poly signature method

[Vicente Romero]

Hi all,

After Brian's suggestion I have modified the compiler to treat 
Intrinsics.ldc(condy) as a poly signature method. It is important to 
note that this feature is only visible if the argument passed to the 
ldc() method is a Constables.DynamicConstantRef, aka condy. In all other 
cases ldc() will continue to behave as before. This, apparently, simple 
change has implied the exposition of a so far limited feature: special 
constants can contain primitives, or String types. I sent a previous 
mail to the list talking about this. I had to improve the infrastructure 
that deals with special constants in order to adapt it to the new 
interactions in which now a special constant containing a primitive, 
String, etc should behave as a primitive, String, etc constant. And 
establish a difference with the cases in which it shouldn't behave like 
it. I was expecting this new development to bring more disruption to the 
compiler, so far seems to be working nicely but probably is still soon 
to understand all the possible interactions.

Thanks
Vicente

On 08/25/2017 12:30 PM, vicente.romero at oracle.com wrote:
> Changeset: c791e4e04c3d
> Author:    vromero
> Date:      2017-08-25 12:28 -0400
> URL:       http://hg.openjdk.java.net/amber/amber/langtools/rev/c791e4e04c3d
>
> treating Intrinsics ldc as a poly signature method
> this patch also adds to the already existing infrastructure for special constants
> a method to duplicate a special constant was added, it is a 'soft' duplication in
> the sense that it doesn't clone the content, only the container is duplicated
> another method added allows replacing an existing value by a new one.
> The criteria for equality is equality of references.
> Special constants can contain primitives and Strings but those are wrapped inside the
> special constant. If a particular code in the compiler tries to access the intrinsic
> value of a constant, if any, then a difference should be made between an 'actual' accessible
> value and one that is only accessible at run time, condy, for this reason the method hasIntrisicValue
> was added to SpecialConstants, it was added in a previous patch though
>
> ! 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/ConstFold.java
> ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.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/SpecialConstantUtils.java
> ! test/tools/javac/specialConstantFolding/CondyCodeGenerationTest.java
>