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

[Jon V.]

I don't believe that handles will keep the objects from being garbage
collected.

Hotspot does not support object pinning.

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