AW: AW: How to pin/avoid gc for an oop?

[Ioi Lam]

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