RFR (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles

[Aleksey Shipilev]

Hi Coleen,

On 01/26/2016 06:49 PM, Coleen Phillimore wrote:
> This might be a good time to split vmIntrinsics off from vmSymbols and
> create new .hpp and .cpp files for them.  There are a lot of both now
> and they're different. 

vmSymbols depends on vmIntrinsics:

#define VM_SYMBOLS_DO(template do_alias)
 ...

  /* class symbols needed by intrinsics */
  VM_INTRINSICS_DO(VM_INTRINSIC_IGNORE, template, VM_SYMBOL_IGNORE,
VM_SYMBOL_IGNORE, VM_ALIAS_IGNORE)

Therefore, splitting out vmIntrinsics would mean vmSymbols would have to
include vmIntrinsics anyway, so I don't see the benefit of doing that
within this patch.


>  Is the implementation of these mostly in
> library_call.cpp?

C2 intrinsics are implemented in library_call.cpp. The subsequent
patches would probably bring C1 intrinsics as well, which will reference
the same vmIntrinsic symbols.


> Also, if there are changes to vmStructs there are likely changes to the
> serviceability agent duplicated code. If not, then there is no need to
> make changes to vmStructs. 

Well, I grepped through SA code, and see no references even for the
existing CompareAndSwap nodes. Which makes me to believe we would just
want to communicate the nodes appropriately through vmStructs table, and
be done. This is what the patch already does.


> There might be changes to jvmciStructs though.  I don't know.

I grepped through JVMCI, and found no clear dependencies, except for
referenced MH intrinsics, that are not affected by this patch.


>> On 1/25/16 8:32 AM, Aleksey Shipilev wrote:
>>> Webrev:
>>>   http://cr.openjdk.java.net/~shade/8148146/webrev.jdk.00/
>>>   http://cr.openjdk.java.net/~shade/8148146/webrev.hs.00/

Cheers,
-Aleksey