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

[David Simms]

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).

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

(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
>>