[foreign-memaccess] RFR 8234581: Cleanup use of exceptions in the memory access API

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Nov 21 13:28:41 UTC 2019


On 21/11/2019 13:07, sundararajan.athijegannathan at oracle.com wrote:
> Looks good.
>
> Minor:
>
> +
>
> private static boolean skipZeroMemory;
> +
> +static {
> +skipZeroMemory = 
> GetBooleanAction.privilegedGetProperty(“jdk.internal.foreign.skipZeroMemory”);
> +}
>
>
> could be static final & inline initialization.

Whoops - good catch; will fix before push

Maurizio

>
> -Sundar
>
> On 21/11/19 6:23 pm, Maurizio Cimadamore wrote:
>> New day, new cleanup :-)
>>
>> This time, following some of the indications from Paul, the goal is 
>> to cleanup usages of exceptions in the memory access API. I found 4 
>> broad categories of issues:
>>
>> - We sometimes throw IAE where an IOOB would be preferred (namely, 
>> MemorySegment::slice and MemoryAddress::copy)
>>
>> - We sometimes use RuntimeException to document unforeseen failures 
>> of Unsafe::allocateMemory (ByteBuffer::allocateDirect does not do so)
>>
>> - The handling of exceptions when forming layout paths is plain 
>> inconsistent - and IAE should be used throughout
>>
>> - MemorySegment::close should always throw ISE if the state is not valid
>>
>>
>> The changes in LayoutPath handling required some deeper changes in 
>> the implementation - which now triggers an uniform IAE with a message 
>> of the kind: Bad layout path: <cause>.
>>
>>
>> Since I was there, I also added the logic to zero the native memory 
>> allocated with MemorySegment::allocateNative. This behavior can be 
>> disabled with a runtime flag: -Djdk.internal.foreign.skipZeroMemory.
>>
>>
>> I also made extra sure that the exceptions thrown in the code are 
>> reflected in the throws clause of the API methods, and that there are 
>> the right @throw taglets for them.
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~mcimadamore/panama/8234581/
>>
>> javadoc:
>>
>> cr.openjdk.java.net/~mcimadamore/panama/8234581_javadoc
>>
>>
>> Cheers
>> Maurizio
>>


More information about the panama-dev mailing list