System.java Development Question
Hello. I'm not sure if there's a minor typo but I cannot find the error in it. Can you guys look? In System.c we have: JNIEXPORT void JNICALL Java_java_lang_System_setMemoryAllocationListener0(JNIEnv *env, jclass cla, jobject listener) { jfieldID fid = (*env)->GetStaticFieldID(env,cla,"memoryAllocationListener","Ljava/lang/memory/MemoryAllocationListener;"); if (fid == 0) return; (*env)->SetStaticObjectField(env,cla,fid,listener); } -- -- -- -- -- And in System.java we have: public static final MemoryAllocationListener memoryAllocationListener = null; ... public static void setMemoryAllocationListener(MemoryAllocationListener memoryAllocationListener) { checkMalloc(); setMemoryAllocationListener0(memoryAllocationListener); } ... //SecureJVM private private static native void setMemoryAllocationListener0(MemoryAllocationListener memoryAllocationListener); -- -- -- -- -- We get the following after running a trivial Java program: Exception in thread "main" java.lang.UnsatisfiedLinkError: java.lang.System.setMemoryAllocationListener0(Ljava/lang/memory/MemoryAllocationListener;)V at java.base/java.lang.System.setMemoryAllocationListener0(Native Method) at java.base/java.lang.System.setMemoryAllocationListener(System.java:261) at Hope.<init>(Hope.java:19) at Hope.main(Hope.java:11) -- -- Can we skip right to it? What is the issue here? Thanks. Max R.
On 03/08/2018 06:22, mr rupplin wrote:
:
We get the following after running a trivial Java program:
Exception in thread "main" java.lang.UnsatisfiedLinkError: java.lang.System.setMemoryAllocationListener0(Ljava/lang/memory/MemoryAllocationListener;)V at java.base/java.lang.System.setMemoryAllocationListener0(Native Method) at java.base/java.lang.System.setMemoryAllocationListener(System.java:261) at Hope.<init>(Hope.java:19) at Hope.main(Hope.java:11)
-- --
Can we skip right to it? What is the issue here?
Which JDK build is this? I can't tell if it has the map files used by the linker (mapfile-vers in the case of libjava) or not. The map files don't exist in the main line but they may exist if you are working on a patch for a previous release. -Alan
This is an OpenJDK 9 build. Can you explain? I'm very interested in getting all the details understood. Hey thanks! MR ________________________________ From: Alan Bateman <Alan.Bateman@oracle.com> Sent: Friday, August 3, 2018 9:38 AM To: mr rupplin; core-libs-dev@openjdk.java.net Subject: Re: System.java Development Question On 03/08/2018 06:22, mr rupplin wrote:
:
We get the following after running a trivial Java program:
Exception in thread "main" java.lang.UnsatisfiedLinkError: java.lang.System.setMemoryAllocationListener0(Ljava/lang/memory/MemoryAllocationListener;)V at java.base/java.lang.System.setMemoryAllocationListener0(Native Method) at java.base/java.lang.System.setMemoryAllocationListener(System.java:261) at Hope.<init>(Hope.java:19) at Hope.main(Hope.java:11)
-- --
Can we skip right to it? What is the issue here?
Which JDK build is this? I can't tell if it has the map files used by the linker (mapfile-vers in the case of libjava) or not. The map files don't exist in the main line but they may exist if you are working on a patch for a previous release. -Alan
Any help? ________________________________ From: mr rupplin <mearvk@outlook.com> Sent: Friday, August 3, 2018 9:42:26 AM To: Alan Bateman; core-libs-dev@openjdk.java.net Subject: Re: System.java Development Question This is an OpenJDK 9 build. Can you explain? I'm very interested in getting all the details understood. Hey thanks! MR ________________________________ From: Alan Bateman <Alan.Bateman@oracle.com> Sent: Friday, August 3, 2018 9:38 AM To: mr rupplin; core-libs-dev@openjdk.java.net Subject: Re: System.java Development Question On 03/08/2018 06:22, mr rupplin wrote:
:
We get the following after running a trivial Java program:
Exception in thread "main" java.lang.UnsatisfiedLinkError: java.lang.System.setMemoryAllocationListener0(Ljava/lang/memory/MemoryAllocationListener;)V at java.base/java.lang.System.setMemoryAllocationListener0(Native Method) at java.base/java.lang.System.setMemoryAllocationListener(System.java:261) at Hope.<init>(Hope.java:19) at Hope.main(Hope.java:11)
-- --
Can we skip right to it? What is the issue here?
Which JDK build is this? I can't tell if it has the map files used by the linker (mapfile-vers in the case of libjava) or not. The map files don't exist in the main line but they may exist if you are working on a patch for a previous release. -Alan
On 4/08/2018 10:29 PM, mr rupplin wrote:
Any help?
Patience is a virtue. ;-) As Alan indicated in older releases, like 9, there is a mapfile used to tell the linker about exported entry points to native libraries. As you are using OpenJDK 9 you will need to add the appropriate entry in jdk/make/mapfiles/libjava/mapfile-vers David -----
________________________________ From: mr rupplin <mearvk@outlook.com> Sent: Friday, August 3, 2018 9:42:26 AM To: Alan Bateman; core-libs-dev@openjdk.java.net Subject: Re: System.java Development Question
This is an OpenJDK 9 build. Can you explain? I'm very interested in getting all the details understood. Hey thanks!
MR ________________________________ From: Alan Bateman <Alan.Bateman@oracle.com> Sent: Friday, August 3, 2018 9:38 AM To: mr rupplin; core-libs-dev@openjdk.java.net Subject: Re: System.java Development Question
On 03/08/2018 06:22, mr rupplin wrote:
:
We get the following after running a trivial Java program:
Exception in thread "main" java.lang.UnsatisfiedLinkError: java.lang.System.setMemoryAllocationListener0(Ljava/lang/memory/MemoryAllocationListener;)V at java.base/java.lang.System.setMemoryAllocationListener0(Native Method) at java.base/java.lang.System.setMemoryAllocationListener(System.java:261) at Hope.<init>(Hope.java:19) at Hope.main(Hope.java:11)
-- --
Can we skip right to it? What is the issue here?
Which JDK build is this? I can't tell if it has the map files used by the linker (mapfile-vers in the case of libjava) or not. The map files don't exist in the main line but they may exist if you are working on a patch for a previous release.
-Alan
On 2018-08-04 14:29, mr rupplin wrote:
Any help?
I think it would help if you described what you're trying to achieve, rather than the current stumbling block.[0] Reading between the lines then it seems you're trying to add some kind of adhoc allocation profiling, so I wonder if you've seen the Low Overhead Heap-Profiling work that went into jdk/jdk just a few weeks ago?[1] If it doesn't fit your use-case - or you really need something like it applied to JDK 9 - it might still be good advice to study the code and approach taken there before reverse-engineering the entire OpenJDK source code... :-) /Claes [0] https://en.wikipedia.org/wiki/XY_problem [1] Initial implementation: http://hg.openjdk.java.net/jdk/jdk/rev/e2a7f431f65c Impl RFE: https://bugs.openjdk.java.net/browse/JDK-8203394 JEP: https://bugs.openjdk.java.net/browse/JDK-8203394 (See the JEP for follow-up bug fixes you'd need to consider if you'd ever attempt to backport this)
Clases, Hello. Firstly thank you for replying. Of course our goal is to show the strengths in the OpenJDK. Some weeks ago we were working with the ClassFileTransformer as an initial hook for a modest databasing proposal. We found it to be a dead end. Of course the company has greenlit further work into the area. We would like to point out JDK did not have any way to hook the malloc sequence at the time. Please refer us to the technical lay for the Overhead Heap-Profiling reference you refer to; Ok. Thanks, Max R. ________________________________ From: Claes Redestad <claes.redestad@oracle.com> Sent: Monday, August 6, 2018 2:12:35 AM To: core-libs-dev@openjdk.java.net; mearvk@outlook.com Subject: Re: System.java Development Question On 2018-08-04 14:29, mr rupplin wrote:
Any help?
I think it would help if you described what you're trying to achieve, rather than the current stumbling block.[0] Reading between the lines then it seems you're trying to add some kind of adhoc allocation profiling, so I wonder if you've seen the Low Overhead Heap-Profiling work that went into jdk/jdk just a few weeks ago?[1] If it doesn't fit your use-case - or you really need something like it applied to JDK 9 - it might still be good advice to study the code and approach taken there before reverse-engineering the entire OpenJDK source code... :-) /Claes [0] https://en.wikipedia.org/wiki/XY_problem [1] Initial implementation: http://hg.openjdk.java.net/jdk/jdk/rev/e2a7f431f65c Impl RFE: https://bugs.openjdk.java.net/browse/JDK-8203394 JEP: https://bugs.openjdk.java.net/browse/JDK-8203394 (See the JEP for follow-up bug fixes you'd need to consider if you'd ever attempt to backport this)
Hi Max, On 2018-08-06 17:55, mr rupplin wrote:
Clases, Hello.
Firstly thank you for replying. Of course our goal is to show the strengths in the OpenJDK.
Some weeks ago we were working with the ClassFileTransformer as an initial hook for a modest databasing proposal. We found it to be a dead end.
Of course the company has greenlit further work into the area. We would like to point out JDK did not have any way to hook the malloc sequence at the time.
it's great that you're showing an interest in the platform and exploring ways to extend/improve it. It's somewhat coincidental that a lot of work happened in this particular area recently.
Please refer us to the technical lay for the Overhead Heap-Profiling reference you refer to; Ok.
I thought I already had, but it seems I referred to the initial implementation RFE twice. Sorry about that.. The high-level JEP is here: http://openjdk.java.net/jeps/331 It has the high-level overview. From there you can click through to JBS details for the JEP, and from there to the implementation. For historical reference, initial discussion on the proposal here: http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-June/017543.h... There were a couple of code reviews done on open lists, but I think this is the final round (and thread): http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-May/023668.ht... On top of the Low-Overhead Heap Profiling JEP mentioned, JFR was also open sourced in time for JDK 11. Perhaps it's memory allocation sampling is of interest and a workable alternative. HTH! /Claes
That is alot of reading. I will look into it. We would build some according to the frameworks' ability to handle that control area. Thank you. I will be in touch. Max R. Sr. Software Lead ________________________________ From: Claes Redestad <claes.redestad@oracle.com> Sent: Monday, August 6, 2018 2:20:38 PM To: mr rupplin; core-libs-dev@openjdk.java.net Subject: Re: System.java Development Question Hi Max, On 2018-08-06 17:55, mr rupplin wrote: Clases, Hello. Firstly thank you for replying. Of course our goal is to show the strengths in the OpenJDK. Some weeks ago we were working with the ClassFileTransformer as an initial hook for a modest databasing proposal. We found it to be a dead end. Of course the company has greenlit further work into the area. We would like to point out JDK did not have any way to hook the malloc sequence at the time. it's great that you're showing an interest in the platform and exploring ways to extend/improve it. It's somewhat coincidental that a lot of work happened in this particular area recently. Please refer us to the technical lay for the Overhead Heap-Profiling reference you refer to; Ok. I thought I already had, but it seems I referred to the initial implementation RFE twice. Sorry about that.. The high-level JEP is here: http://openjdk.java.net/jeps/331 It has the high-level overview. From there you can click through to JBS details for the JEP, and from there to the implementation. For historical reference, initial discussion on the proposal here: http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-June/017543.h... There were a couple of code reviews done on open lists, but I think this is the final round (and thread): http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-May/023668.ht... On top of the Low-Overhead Heap Profiling JEP mentioned, JFR was also open sourced in time for JDK 11. Perhaps it's memory allocation sampling is of interest and a workable alternative. HTH! /Claes
participants (4)
-
Alan Bateman
-
Claes Redestad
-
David Holmes
-
mr rupplin