AW: AW: AW: How to pin/avoid gc for an oop?
Christian Hagedorn
ch-hagedorn at hispeed.ch
Mon Mar 13 16:27:03 UTC 2017
Thank you all for your help and your suggestions! :)
That is right I only need a way to still reach it but not actually pin it. It seems to be working by creating a global ref with
JNIHandles::make_global(handle), which is exactly what the jni_NewGlobalRef function does pointed out by Ioi.
The GC did not remove the oops.
Christian
-----Ursprüngliche Nachricht-----
Von: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] Im Auftrag von Ioi Lam
Gesendet: Montag, 13. März 2017 13:43
An: Aleksey Shipilev; hotspot-dev at openjdk.java.net
Betreff: Re: AW: AW: How to pin/avoid gc for an oop?
I don't think Christian actually needs object pinning (as in avoiding relocation of an object due to GC).
- Ioi
On 3/13/17 8:36 PM, Aleksey Shipilev wrote:
> 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