AW: AW: How to pin/avoid gc for an oop?
Ioi Lam
ioi.lam at oracle.com
Mon Mar 13 12:43:09 UTC 2017
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