Quantcast

How to pin/avoid gc for an oop?

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

How to pin/avoid gc for an oop?

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Volker Simonis
Not quite sure what you want to achieve, but with G1 you could
allocate a "humongous" object [1,2] which is just as big as a G1
region. It will be allocated into the old generation and not moved
around by GC.

Regards,
Volker

[1] http://www.oracle.com/technetwork/articles/java/g1gc-1984535.html
[2] https://plumbr.eu/handbook/gc-tuning-in-practice/other-examples/humongous-allocations

On Thu, Mar 9, 2017 at 6:25 PM, Christian Hagedorn
<[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jon V.
In reply to this post by Christian Hagedorn
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 <[hidden email]>
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
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Christian Hagedorn
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, 19:00, um 19:00, "Jon V." <[hidden email]> 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
><[hidden email]>
>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
>>
>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jon V.
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 <[hidden email]> 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." <[hidden email]> 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 <[hidden email]>
> 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
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Christian Hagedorn
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
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
make the undo log in the managed heap as well, but I hoped that this can
be done directly in the JVM.

Am 9. März 2017, 21:12, um 21:12, "Jon V." <[hidden email]> 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 <[hidden email]>
>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." <[hidden email]> 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
><[hidden email]>
>> 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
>>
>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jon V.
My knowledge of the JVM is limited to the GC and memory allocation, but I
think I can be helpful.  You are correct, switching from InVM to InNative
to prevent the GC from running would be a bad idea if you plan on spending
a long time inside your atomic block.

I don't remember how Handles work.

OOPs are managed in a ptr table.  When you get a ptr to an OOP it is
actually a pointer to the ptr table.  Dereferencing it will get you the
actual OOP.  This is done that way to keep the references valid across GC
intervals when the actual object may be moved in memory.

I'm not aware of any way to create an OOP where you own the lifecycle.
Creating OOPs outside of the JVM lifecycle causes all sorts of errors when
the JVM tries to count references.

For the reasons above the undo log is going to be expensive in terms of
garbage creation.

The atomic scope heap undo log might be the only way to do it without
requiring extensive modifications to the JVM.

On Fri, Mar 10, 2017 at 3:56 AM, Christian <[hidden email]> 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
> 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
> make the undo log in the managed heap as well, but I hoped that this can
> be done directly in the JVM.
> Am 9. März 2017, um 21:12, "Jon V." <[hidden email]> 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 < [hidden email]>
>> 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." < [hidden email]> 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 <
>>> [hidden email]> 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
>>>
>>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Holmes
In reply to this post by Christian Hagedorn
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." <[hidden email]> 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 <[hidden email]>
>> 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." <[hidden email]> 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
>> <[hidden email]>
>>> 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
>>>
>>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Christian Hagedorn
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.

How could  I make the log  a GC root?

Christian

-----Ursprüngliche Nachricht-----
Von: David Holmes [mailto:[hidden email]]
Gesendet: Samstag, 11. März 2017 04:58
An: Christian; Jon V.
Cc: [hidden email]
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." <[hidden email]> 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 <[hidden email]>
>> 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." <[hidden email]> 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
>> <[hidden email]>
>>> 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
>>>
>>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Holmes
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:[hidden email]]
> Gesendet: Samstag, 11. März 2017 04:58
> An: Christian; Jon V.
> Cc: [hidden email]
> 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." <[hidden email]> 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 <[hidden email]>
>>> 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." <[hidden email]> 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
>>> <[hidden email]>
>>>> 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
>>>>
>>>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Christian Hagedorn
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:[hidden email]]
Gesendet: Sonntag, 12. März 2017 00:39
An: Christian Hagedorn; [hidden email]
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:[hidden email]]
> Gesendet: Samstag, 11. März 2017 04:58
> An: Christian; Jon V.
> Cc: [hidden email]
> 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." <[hidden email]> 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 <[hidden email]>
>>> 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." <[hidden email]> 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
>>> <[hidden email]>
>>>> 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
>>>>
>>>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[hidden email]>
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:[hidden email]]
> Gesendet: Sonntag, 12. März 2017 00:39
> An: Christian Hagedorn; [hidden email]
> 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:[hidden email]]
> > Gesendet: Samstag, 11. März 2017 04:58
> > An: Christian; Jon V.
> > Cc: [hidden email]
> > 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." <[hidden email]>
> 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 <[hidden email]>
> >>> 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." <[hidden email]> 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
> >>> <[hidden email]>
> >>>> 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
> >>>>
> >>>>
> >
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Holmes
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 <[hidden email]>
> 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:[hidden email]]
>> Gesendet: Sonntag, 12. März 2017 00:39
>> An: Christian Hagedorn; [hidden email]
>> 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:[hidden email]]
>>> Gesendet: Samstag, 11. März 2017 04:58
>>> An: Christian; Jon V.
>>> Cc: [hidden email]
>>> 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." <[hidden email]>
>> 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 <[hidden email]>
>>>>> 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." <[hidden email]> 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
>>>>> <[hidden email]>
>>>>>> 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
>>>>>>
>>>>>>
>>>
>>
>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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:[hidden email]]
Gesendet: Sonntag, 12. März 2017 06:05
An: Jon V.; Christian Hagedorn; [hidden email]
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
> <[hidden email]>
> 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:[hidden email]]
>> Gesendet: Sonntag, 12. März 2017 00:39
>> An: Christian Hagedorn; [hidden email]
>> 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:[hidden email]]
>>> Gesendet: Samstag, 11. März 2017 04:58
>>> An: Christian; Jon V.
>>> Cc: [hidden email]
>>> 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." <[hidden email]>
>> 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 <[hidden email]>
>>>>> 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." <[hidden email]> 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
>>>>> <[hidden email]>
>>>>>> 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
>>>>>>
>>>>>>
>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Thomas Schatzl
Hi,

On Mon, 2017-03-13 at 01:59 +0100, 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?
>

  roughly these steps:

1) register (add) the oop you want to keep live during gc to some
internal data structure.
Depending on requirements like available operations on it, the amount
of oops you store there, scalability and other factors, this may be
different for you.

2) make sure the GC algorithm of your choice iterates over them during
GC and evacuates/fixes up these oops.

One example you may look at is how the GC's handle the "Universe's"
direct oops.
E.g. search for calls to Universe::oops_do() how this works.

Since Universe::oops_do() is already called in the right places, you
could start experimenting by adding your undo log to the Universe and
make sure that the closure passed to Universe::oops_do() is called for
every oop in that data structure.

That should properly keep the required oops alive across GCs for all
but G1. For that, when you modify objects in your undo log you will
need to apply its pre-barrier on the original value (All other gcs do
not require a pre-barrier, so nothing to do).

This boils down to calling
G1SDATBCardTableModRefBS::enqueue(old_obj_value) for all modifications
(unless you can guarantee that old_obj_value has been NULL).

Thanks,
  Thomas

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Ioi Lam
In reply to this post by Christian Hagedorn
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:[hidden email]]
> Gesendet: Sonntag, 12. März 2017 06:05
> An: Jon V.; Christian Hagedorn; [hidden email]
> 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
>> <[hidden email]>
>> 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:[hidden email]]
>>> Gesendet: Sonntag, 12. März 2017 00:39
>>> An: Christian Hagedorn; [hidden email]
>>> 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:[hidden email]]
>>>> Gesendet: Samstag, 11. März 2017 04:58
>>>> An: Christian; Jon V.
>>>> Cc: [hidden email]
>>>> 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." <[hidden email]>
>>> 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 <[hidden email]>
>>>>>> 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." <[hidden email]> 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
>>>>>> <[hidden email]>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Aleksey Shipilev-4
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:[hidden email]]
>> Gesendet: Sonntag, 12. März 2017 06:05
>> An: Jon V.; Christian Hagedorn; [hidden email]
>> 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
>>> <[hidden email]>
>>> 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:[hidden email]]
>>>> Gesendet: Sonntag, 12. März 2017 00:39
>>>> An: Christian Hagedorn; [hidden email]
>>>> 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:[hidden email]]
>>>>> Gesendet: Samstag, 11. März 2017 04:58
>>>>> An: Christian; Jon V.
>>>>> Cc: [hidden email]
>>>>> 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." <[hidden email]>
>>>> 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 <[hidden email]>
>>>>>>> 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." <[hidden email]> 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
>>>>>>> <[hidden email]>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Ioi Lam
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:[hidden email]]
>>> Gesendet: Sonntag, 12. März 2017 06:05
>>> An: Jon V.; Christian Hagedorn; [hidden email]
>>> 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
>>>> <[hidden email]>
>>>> 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:[hidden email]]
>>>>> Gesendet: Sonntag, 12. März 2017 00:39
>>>>> An: Christian Hagedorn; [hidden email]
>>>>> 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:[hidden email]]
>>>>>> Gesendet: Samstag, 11. März 2017 04:58
>>>>>> An: Christian; Jon V.
>>>>>> Cc: [hidden email]
>>>>>> 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." <[hidden email]>
>>>>> 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 <[hidden email]>
>>>>>>>> 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." <[hidden email]> 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
>>>>>>>> <[hidden email]>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Christian Hagedorn
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:[hidden email]] Im Auftrag von Ioi Lam
Gesendet: Montag, 13. März 2017 13:43
An: Aleksey Shipilev; [hidden email]
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:[hidden email]]
>>> Gesendet: Sonntag, 12. März 2017 06:05
>>> An: Jon V.; Christian Hagedorn; [hidden email]
>>> 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
>>>> <[hidden email]>
>>>> 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:[hidden email]]
>>>>> Gesendet: Sonntag, 12. März 2017 00:39
>>>>> An: Christian Hagedorn; [hidden email]
>>>>> 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:[hidden email]]
>>>>>> Gesendet: Samstag, 11. März 2017 04:58
>>>>>> An: Christian; Jon V.
>>>>>> Cc: [hidden email]
>>>>>> 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."
>>>>>>> <[hidden email]>
>>>>> 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
>>>>>>>> <[hidden email]>
>>>>>>>> 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." <[hidden email]> 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
>>>>>>>> <[hidden email]>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jon V.
Just a quick note:

JNI is always a safe-point for GC.

JNI Critical Access prevents the GC from running.

JNI API calls always have to acquire and release the GC lock for every
method.

NewGlobalRef must be explicitly deleted otherwise they will exist forever.

On Mon, Mar 13, 2017 at 12:27 PM, Christian Hagedorn <[hidden email]
> wrote:

> 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:[hidden email]] Im Auftrag
> von Ioi Lam
> Gesendet: Montag, 13. März 2017 13:43
> An: Aleksey Shipilev; [hidden email]
> 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:[hidden email]]
> >>> Gesendet: Sonntag, 12. März 2017 06:05
> >>> An: Jon V.; Christian Hagedorn; [hidden email]
> >>> 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
> >>>> <[hidden email]>
> >>>> 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:[hidden email]]
> >>>>> Gesendet: Sonntag, 12. März 2017 00:39
> >>>>> An: Christian Hagedorn; [hidden email]
> >>>>> 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:[hidden email]]
> >>>>>> Gesendet: Samstag, 11. März 2017 04:58
> >>>>>> An: Christian; Jon V.
> >>>>>> Cc: [hidden email]
> >>>>>> 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."
> >>>>>>> <[hidden email]>
> >>>>> 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
> >>>>>>>> <[hidden email]>
> >>>>>>>> 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." <[hidden email]>
> 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
> >>>>>>>> <[hidden email]>
> >>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>>
>
>
>
Loading...