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

[David Holmes]

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
>