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

[Christian Hagedorn]

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