RFR (S) JDK-6311046: -Xcheck:jni should support checking of GetPrimitiveArrayCritical

[David Holmes]

On 6/05/2014 9:04 PM, David Simms wrote:
> I admit to thinking of extending "Fence" to "ElectricFence" if someone
> needs actual page guards for a specific use case...hence the naming
> ("Electric Fence" bounds checking tool).

That name's already taken

http://en.wikipedia.org/wiki/Electric_Fence

:)

> Understand the concern with actual memory fence. Thinking "Guarded
> Memory" or "Memory Guard" might be be appropriate ?

I'm fine with Guard or Check.

To be clear I haven't looked at the code in detail.

David H.


> (Dropped compiler ML, no longer relevant)
>
> On 6/05/2014 12:36 p.m., David Holmes wrote:
>> Hi David,
>>
>> Is this "fenced memory" terminology in common use? I'm more used to
>> "memory fences" - which is quite a different thing.
>>
>> David H.
>>
>> On 6/05/2014 7:05 PM, David Simms wrote:
>>>
>>> Dropped compileBroker.cpp (have marked 8042428 with appropriate rules),
>>> updated patch here:
>>>
>>> http://cr.openjdk.java.net/~dsimms/6311046/rev3/
>>>
>>> On 5/05/2014 10:56 p.m., Vladimir Kozlov wrote:
>>>> Hi David,
>>>>
>>>> compileBroker.cpp was recently modified by 8040798 (it was pushed into
>>>> main repo today):
>>>>
>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/48c15b47a4f1
>>>>
>>>> And it still has the problem you pointed (overwrite _next pointer). I
>>>> think it should be a separate fix since we don't delete the task
>>>> object now but put it on free list. I will file a bug. Please, remove
>>>> this change from yours.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 5/5/14 4:37 AM, David Simms wrote:
>>>>> Gidday all:
>>>>>
>>>>> Bug/Enhancement: https://bugs.openjdk.java.net/browse/JDK-6311046
>>>>>
>>>>> Web review: http://cr.openjdk.java.net/~dsimms/6311046/rev2/
>>>>>
>>>>> Cleaned up the "hand rolled" memory bounds checking in
>>>>> os::malloc/realloc/free and type checking in checked JNI (GetString*),
>>>>> and unified into a single helper class "FencedMemory". Added some
>>>>> extra
>>>>> checks to checked JNI (release mode).
>>>>>
>>>>> There is now some extra debugging support for free/release operations,
>>>>> FencedMemory::release_for_freeing()" will now mark user bytes with
>>>>> "freeBlockPad", which did yeld a result when testing:
>>>>>
>>>>> Found a minor bug in CompilerQueue (hence CC compiler ML),
>>>>> shouldn't be
>>>>> a problem in practice (probably won't crash), but the code is
>>>>> incorrect...and now fixed here.
>>>>>
>>>>> Testing Completed:
>>>>>
>>>>> Ran on all platforms:
>>>>>
>>>>>   * JPRT
>>>>>   * jteg jdk_core & jdk_svc
>>>>>   * "RT nightly".
>>>>>
>>>>>
>>>>> Cheers
>>>>> /David Simms
>>>
>