RFR (S) JDK-6311046: -Xcheck:jni should support checking of GetPrimitiveArrayCritical
david.holmes at oracle.com
Tue May 6 10:36:49 UTC 2014
Is this "fenced memory" terminology in common use? I'm more used to
"memory fences" - which is quite a different thing.
On 6/05/2014 7:05 PM, David Simms wrote:
> Dropped compileBroker.cpp (have marked 8042428 with appropriate rules),
> updated patch here:
> 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):
>> 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.
>> 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".
>>> /David Simms
More information about the hotspot-compiler-dev