AW: AW: How to pin/avoid gc for an oop?
Aleksey Shipilev
shade at redhat.com
Mon Mar 13 12:36:29 UTC 2017
Handle-izing / JNIRef-ing the oop != pinning.
a) If you want pinning, you have to cooperate with GC somehow. JNI has
"critical" operations for this, so it would be instructive to see
jni_GetPrimitiveArrayCritical does this with GCLocker.
b) If you just want the reachability, and are in native code, then JNI GlobalRef
would probably be the cleanest choice.
c) If you just want the reachability, and are in Java code, then calling
java.lang.ref.Reference.reachabilityFence would retain the local var in the
thread roots.
-Aleksey
On 03/13/2017 01:23 PM, Ioi Lam wrote:
> How about using JNI NewGlobalRef/DeleteGlobalRef? Unlike the C++ "Handle" class
> (which is scoped and automatically reclaimed), a reference created by
> NewGlobalRef remains valid until it's explicitly deleted using DeleteGlobalRef.
>
> - Ioi
>
> On 3/13/17 8:59 AM, Christian Hagedorn wrote:
>> So handles are not really an option. What else could I do to make my undo log
>> a GC root to ensure reachability of the oops in it?
>>
>> Christian
>>
>> -----Ursprüngliche Nachricht-----
>> Von: David Holmes [mailto:david.holmes at oracle.com]
>> Gesendet: Sonntag, 12. März 2017 06:05
>> An: Jon V.; Christian Hagedorn; hotspot-dev at openjdk.java.net
>> Betreff: Re: AW: How to pin/avoid gc for an oop?
>>
>> On 12/03/2017 10:59 AM, Jon V. wrote:
>>> I don't believe that handles will keep the objects from being garbage
>>> collected.
>> Handles are GC roots. Or rather the per-thread handle area is a GC root.
>>
>>> Hotspot does not support object pinning.
>> This isn't pinning - the object can still be moved. But the Handle ensures it
>> remains reachable.
>>
>>> Need input from a GC dev
>>>
>>> On Sat, Mar 11, 2017 at 7:53 PM Christian Hagedorn
>>> <ch-hagedorn at hispeed.ch>
>>> wrote:
>>>
>>>> The undo log would be stored as an array of handles inside a thread
>>>> and does not refer to other threads. Would that work then?
>> Handles are intended to be scoped and reclaimed using HandleMarks. This seem
>> to require a different kind of usage.
>>
>> David
>> -----
>>
>>>> Christian
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: David Holmes [mailto:david.holmes at oracle.com]
>>>> Gesendet: Sonntag, 12. März 2017 00:39
>>>> An: Christian Hagedorn; hotspot-dev at openjdk.java.net
>>>> Betreff: Re: AW: How to pin/avoid gc for an oop?
>>>>
>>>> On 11/03/2017 9:08 PM, Christian Hagedorn wrote:
>>>>> Thank you for your answers. If it is possible to do it in the JVM I
>>>> would prefer to do that.
>>>>> I have tried to maintain an array of handles. However I think I have
>>>>> not
>>>> understood its usage correctly. I only saw examples by allocating it
>>>> on the stack with Handle h1(thread, oop). But how can I create a
>>>> handle on the heap such that it is kept alive for an access later? It
>>>> asserts not to call the global operator "new" such that "new Handle(..)"
>>>> does not work.
>>>>
>>>> Sorry that was incorrect advice. Handles are per-thread so you can't
>>>> have a data structure storing them across threads.
>>>>
>>>>> How could I make the log a GC root?
>>>> GC folk should chime in on the details of that - I don't want to give
>>>> more bad advice.
>>>>
>>>> David
>>>>
>>>>> Christian
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> Von: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Gesendet: Samstag, 11. März 2017 04:58
>>>>> An: Christian; Jon V.
>>>>> Cc: hotspot-dev at openjdk.java.net
>>>>> Betreff: Re: How to pin/avoid gc for an oop?
>>>>>
>>>>> On 10/03/2017 6:56 PM, Christian wrote:
>>>>>> Hi Jon,
>>>>>>
>>>>>> The STM is to be integrated into the JVM, but the transactional
>>>>>> execution only affects modifications to the managed memory done by
>>>>>> bytecode instructions. JVM internal structures are unaffected.
>>>>>>
>>>>>> Here an example:
>>>>>>
>>>>>> class X {
>>>>>> int f;
>>>>>>
>>>>>> public static update(X x, int _new) {
>>>>>> atomic { // tx start
>>>>>> // (1) update field f of x:
>>>>>>
>>>>>> // undo log maintains a reference to x and old value of f
>>>>>> // note: x contains a direct reference to the lock
>>>>>>
>>>>>> x.f = _new;
>>>>>>
>>>>>> // (2) assume GC is run
>>>>>> // Note: The atomic section can be large and blocking,
>>>>>> // thus, inhibiting a GC run is not an option.
>>>>>>
>>>>>> // (3) End of the atomic section (tx end):
>>>>>> // 1. In case of abort: restore old value
>>>>>> // 2. Release lock (obtained via reference to x)
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> How can I assure that the reference to x in the undo log that I
>>>>>> made at
>>>>>> (1) remains valid at (3), even though a GC run may occur at (2)? I
>>>>> My making sure the GC sees everything in the undo log. The details
>>>>> will
>>>> depend on how you propose to implement that log.
>>>>>> thought that Handles (share/vm/runtime/handles.hpp) may be an
>>>>>> option, but I might have misunderstood what they are used for. I
>>>>>> can of course
>>>>> Handles are used inside the VM to protect oops when we need to use
>>>>> them
>>>> across calls that might lead to safepoint checks and thus to GC occurring.
>>>>>> make the undo log in the managed heap as well, but I hoped that
>>>>>> this can be done directly in the JVM.
>>>>> There are a number of ways to do this. If your log is a native VM
>>>>> data
>>>> structure then it might store Handles. Or you could make the log a GC
>>>> root and make it known to the GC, and store oops directly.
>>>>> Or you could implement it all in Java - which is probably a lot
>>>>> simpler,
>>>> albeit likely less performant.
>>>>> David
>>>>>
>>>>>> Am 9. März 2017, 21:12, um 21:12, "Jon V." <sybersnake at gmail.com>
>>>> schrieb:
>>>>>>> Are you trying to build a transactional memory system for the JVM
>>>>>>> or your own Java code?
>>>>>>>
>>>>>>> On Thu, Mar 9, 2017 at 2:33 PM Christian <ch-hagedorn at hispeed.ch>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Jon,
>>>>>>>>
>>>>>>>> I need this for an undo log of a transactional memory system with
>>>>>>>> pessimistic locking/eager version management.
>>>>>>>> Am 9. März 2017, um 19:00, "Jon V." <sybersnake at gmail.com> schrieb:
>>>>>>>>
>>>>>>>> Can you clarify what you mean by Undo and why you think this
>>>>>>>> should
>>>>>>> be
>>>>>>>> done at the VM level so we can better understand the request.
>>>>>>>>
>>>>>>>> If you don't want something to be garbage collected then simply
>>>>>>>> don't dereference it.
>>>>>>>>
>>>>>>>> On Thu, Mar 9, 2017 at 12:38 PM Christian Hagedorn
>>>>>>> <ch-hagedorn at hispeed.ch>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I want to implement an undo functionality and thus need to access
>>>>>>>> an
>>>>>>> oop
>>>>>>>> even when it is out of scope in the Java code. How can I pin such
>>>>>>>> an
>>>>>>> oop to
>>>>>>>> avoid garbage collection of its used memory?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Christian
>>>>>>>>
>>>>>>>>
>>>>
>
More information about the hotspot-dev
mailing list