{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":104359190,"defaultBranch":"master","name":"openj9","ownerLogin":"jdmpapin","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2017-09-21T14:32:53.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/22403820?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1725982927.0","currentOid":""},"activityList":{"items":[{"before":null,"after":"e59fffe049115821820a2fcdc798ef9268da1918","ref":"refs/heads/refine-linkToVirtual-no-direct-doc-comment","pushedAt":"2024-09-10T15:42:07.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Correct outdated linkToVirtual() J2I-avoidance transformation comment\n\nThis method no longer generates any control flow. Instead it generates\nan unconditional virtual dispatch using dispatchVirtual(). Update the\ndoc comment for consistency with 425a1f1da0, 830016e675, and fc9e39d53f.","shortMessageHtmlLink":"Correct outdated linkToVirtual() J2I-avoidance transformation comment"}},{"before":null,"after":"4f864fe6421aba201934616d3fdc371c774589e6","ref":"refs/heads/vTableSlot-cpIndex","pushedAt":"2024-08-30T14:43:59.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Remove unused cpIndex parameter of vTableSlot(), virtualCallSelector()\n\n...in TR_ResolvedMethod.\n\nAdditionally:\n\n- Delete commented code in vTableSlot().\n\n- Remove TR_ResolvedRelocatableJ9Method::virtualCallSelector(). This\n  override just forwarded to the base implementation.\n\n- Stop using virtualCallSelector() to determine the vtable slot to pass\n  to the constructor when instantiating TR_J9MutableCallSite. Instead\n  just pass -1 like we do for other call sites that don't use the slot.","shortMessageHtmlLink":"Remove unused cpIndex parameter of vTableSlot(), virtualCallSelector()"}},{"before":null,"after":"d12b90239eaf656e1c4619586134c4d32ac3909c","ref":"refs/heads/vTableSlot-private-invokevirtual","pushedAt":"2024-08-30T14:43:59.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Set TR_ResolvedMethod vtable slot to zero for private invokevirtual\n\n...for consistency with other private methods and generally other\nmethods that don't appear in the vtable. Previously the vtable slot\nwould have been J9VTABLE_INVOKE_PRIVATE_OFFSET.","shortMessageHtmlLink":"Set TR_ResolvedMethod vtable slot to zero for private invokevirtual"}},{"before":null,"after":"fc9e39d53fc58441cf4c44b83b901a0410799ae0","ref":"refs/heads/refine-linkToVirtual-no-direct","pushedAt":"2024-08-30T14:43:59.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Remove outdated comment and logic from refineMethodHandleLinkTo()\n\nIt's true that final methods of Object and private methods are not in\nthe vtable and must be dispatched directly even though they're called\nusing invokevirtual. However, those methods won't be encountered here\nbecause the MemberName would be of kind MH_REF_INVOKESPECIAL, and the\ndispatch would be carried out by linkToSpecial().","shortMessageHtmlLink":"Remove outdated comment and logic from refineMethodHandleLinkTo()"}},{"before":"dc0af4feff57dd2f6e7c2ce01d991c683573f633","after":"72e686bf93dfa4d5867964410c2a30c2dec9a3df","ref":"refs/heads/master","pushedAt":"2024-08-29T20:04:51.000Z","pushType":"push","commitsCount":81,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Merge pull request #18288 from midronij/offheap-unsafe-setmemory\n\nCheck if runtime array check is needed for Unsafe.setMemory() on PPC","shortMessageHtmlLink":"Merge pull request <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"1945915675\" data-permission-text=\"Title is private\" data-url=\"https://github.com/eclipse-openj9/openj9/issues/18288\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/eclipse-openj9/openj9/pull/18288/hovercard\" href=\"https://github.com/eclipse-openj9/openj9/pull/18288\">eclipse-openj9#18288</a> from midronij/offheap-unsafe-…"}},{"before":null,"after":"3b79bb12ff2299dc4120f9bbeab473280131b2df","ref":"refs/heads/refersTo-shadow","pushedAt":"2024-08-19T16:45:40.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Use findOrFabricateShadowSymbol for Reference.referent in get/refersTo\n\nWhen inlining Reference.getImpl() or Reference.refersTo(), the compiler\ngenerates a load of Reference.referent. Previously, it would reuse any\naddress-typed shadow symref it could find with the expected offset and\nowning method. If it did find such a shadow symref representing a field\nof a different class, it would have incorrect aliasing and likely an\nincorrect type signature. Now instead the field shadow is fabricated if\nnecessary using findOrFabricateShadowSymbol().","shortMessageHtmlLink":"Use findOrFabricateShadowSymbol for Reference.referent in get/refersTo"}},{"before":"f1125a5911601d2eabe71147c8ff7bf67e64d89f","after":"dc0af4feff57dd2f6e7c2ce01d991c683573f633","ref":"refs/heads/master","pushedAt":"2024-08-16T19:44:50.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Merge pull request #19970 from Sreekala-Gopakumar/46RelNoteUpdte\n\nUpdated 0.46.0 Release note with new features","shortMessageHtmlLink":"Merge pull request <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2452571372\" data-permission-text=\"Title is private\" data-url=\"https://github.com/eclipse-openj9/openj9/issues/19970\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/eclipse-openj9/openj9/pull/19970/hovercard\" href=\"https://github.com/eclipse-openj9/openj9/pull/19970\">eclipse-openj9#19970</a> from Sreekala-Gopakumar/46Rel…"}},{"before":"29635ce0db520804e8862f73a58f6a83a4d12c30","after":"f1125a5911601d2eabe71147c8ff7bf67e64d89f","ref":"refs/heads/master","pushedAt":"2024-08-16T18:50:36.000Z","pushType":"push","commitsCount":225,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Use findOrFabricateShadowSymbol for Reference.referent in get/refersTo\n\nWhen inlining Reference.getImpl() or Reference.refersTo(), the compiler\ngenerates a load of Reference.referent. Previously, it would reuse any\naddress-typed shadow symref it could find with the expected offset and\nowning method. If it did find such a shadow symref representing a field\nof a different class, it would have incorrect aliasing and likely an\nincorrect type signature. Now instead the field shadow is fabricated if\nnecessary using findOrFabricateShadowSymbol().","shortMessageHtmlLink":"Use findOrFabricateShadowSymbol for Reference.referent in get/refersTo"}},{"before":"4b7136fa5434f03d038591bab192ed57e9e432dc","after":"29635ce0db520804e8862f73a58f6a83a4d12c30","ref":"refs/heads/master","pushedAt":"2024-07-16T18:07:05.000Z","pushType":"push","commitsCount":183,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Merge pull request #19326 from tajila/offheap\n\nArray base offset zero","shortMessageHtmlLink":"Merge pull request <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2246153731\" data-permission-text=\"Title is private\" data-url=\"https://github.com/eclipse-openj9/openj9/issues/19326\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/eclipse-openj9/openj9/pull/19326/hovercard\" href=\"https://github.com/eclipse-openj9/openj9/pull/19326\">eclipse-openj9#19326</a> from tajila/offheap"}},{"before":"28e52eb0f8a72d14fcd726167a478e126b30828b","after":"0e9b08b7ffd988f2532f2e87d5cd5cfec8790d72","ref":"refs/heads/detect-in-place-redef","pushedAt":"2024-07-05T19:27:31.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Revert \"-XX:+EnableExtendedHCR TestRefreshGCSpecialClassesCache JIT_ON modes\"\n\nThis reverts commit f6a5b16f61ba180c2476a9562dee53b7bfc47b48.","shortMessageHtmlLink":"Revert \"-XX:+EnableExtendedHCR TestRefreshGCSpecialClassesCache JIT_O…"}},{"before":"1a04531c7bc92c6fd6f486d7b8f861e71dca937f","after":"28e52eb0f8a72d14fcd726167a478e126b30828b","ref":"refs/heads/detect-in-place-redef","pushedAt":"2024-07-05T19:24:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"JIT: Detect in-place redefinition based on J9JITRedefinedClass\n\nPreviously, the redefinition hook would determine the relationship\nbetween the old/new and stale/fresh status of redefined classes by\nchecking for TR_EnableHCR. This was a proxy for debug mode, in which\nfast HCR is off because redefinition will OSR and discard the entire\ncode cache. Until recently, this determination was accurate because in\ndebug mode the VM would always redefine classes out-of-place to allow\nfor \"extended HCR.\" However, extended HCR is now being deprecated, and\nas of 704a781a1e6a, by default it's off and redefinition is in-place.\n\nIf a class was redefined in-place unexpectedly, the hook would mix up\nthe old and the new class, which would result in an incorrect CH table\nstate.\n\nRather than try to predict whether redefinition is supposed to be done\nin-place, the hook will now detect whether it was in fact done in-place.","shortMessageHtmlLink":"JIT: Detect in-place redefinition based on J9JITRedefinedClass"}},{"before":"b931ee3204428fb2a4cdd1837c2a5216c581d231","after":"1a04531c7bc92c6fd6f486d7b8f861e71dca937f","ref":"refs/heads/detect-in-place-redef","pushedAt":"2024-07-05T16:41:18.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"JIT: Detect in-place redefinition based on J9JITRedefinedClass\n\nPreviously, the redefinition hook would determine the relationship\nbetween the old/new and stale/fresh status of redefined classes by\nchecking for TR_EnableHCR. This was a proxy for debug mode, in which\nfast HCR is off because redefinition will OSR and discard the entire\ncode cache. Until recently, this determination was accurate because in\ndebug mode the VM would always redefine classes out-of-place to allow\nfor \"extended HCR.\" However, extended HCR is now being deprecated, and\nas of 704a781a1e6a, by default it's off and redefinition is in-place.\n\nIf a class was redefined in-place unexpectedly, the hook would mix up\nthe old and the new class, which would result in an incorrect CH table\nstate.\n\nRather than try to predict whether redefinition is supposed to be done\nin-place, the hook will now detect whether it was in fact done in-place.","shortMessageHtmlLink":"JIT: Detect in-place redefinition based on J9JITRedefinedClass"}},{"before":null,"after":"b931ee3204428fb2a4cdd1837c2a5216c581d231","ref":"refs/heads/detect-in-place-redef","pushedAt":"2024-07-05T16:08:02.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"JIT: Detect in-place redefinition based on J9JITRedefinedClass\n\nPreviously, the redefinition hook would determine the relationship\nbetween the old/new and stale/fresh status of redefined classes by\nchecking for TR_EnableHCR. This was a proxy for debug mode, in which\nfast HCR is off because redefinition will OSR and discard the entire\ncode cache. Until recently, this determination was accurate because in\ndebug mode the VM would always redefine classes out-of-place to allow\nfor \"extended HCR.\" However, extended HCR is now being deprecated, and\nas of 704a781a1e6a, by default it's off and redefinition is in-place.\n\nIf a class was redefined in-place unexpectedly, the hook would mix up\nthe old and the new class, which would result in an incorrect CH table\nstate.\n\nRather than try to predict whether redefinition is supposed to be done\nin-place, the hook will now detect whether it was in fact done in-place.","shortMessageHtmlLink":"JIT: Detect in-place redefinition based on J9JITRedefinedClass"}},{"before":"c4b36274a48129d0fc994e1f07594db5937fc8d8","after":"070557c26f6f0378aafa36bfc95225a88563d718","ref":"refs/heads/aggressive-sfff","pushedAt":"2024-06-20T21:06:01.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Fold primitive-typed static final fields more aggressively\n\nWhenever the compiler attempts to fold a static final field (that hasn't\nbeen explicitly allowlisted somehow), it will now determine whether the\ndeclaring class contains a putstatic instruction that could modify one\nof its static final fields outside of <clinit>. The presence of such a\nputstatic instruction prevents folding, but it should be extremely rare,\nsince javac doesn't generate any.\n\nWe can assume JCL classes won't attempt to store to static final fields\noutside of <clinit>, and classes with class file version 53 or later\nwon't succeed even if they do attempt it. Other classes, i.e. non-JCL\nclasses with version 52 or earlier, will have their bytecode scanned.\n\nIf no putstatic instruction interferes, all primitive-typed static final\nfields will now be folded without any runtime assumption. If the field\ncould potentially be modified later, e.g. using some reflection hack or\nUnsafe, the compiled code is not required to see the new value. This is\nalso true of references, but due to limitations in the JIT's handling of\nknown objects, those still require runtime assumptions if there is any\npossibility they will be modified later.\n\nLater on, when it becomes possible to treat reference-typed static final\nfields the same way, it should be possible to entirely eliminate guarded\nstatic final field folding.","shortMessageHtmlLink":"Fold primitive-typed static final fields more aggressively"}},{"before":null,"after":"13951bc426a1e02802450dbdd060a61713bfdf48","ref":"refs/heads/bytebuffer-vh-no-ufp","pushedAt":"2024-06-18T16:50:27.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Ignore ByteBufferHandle operations in unsafe fast path\n\nTransforming unsafe accesses to array accesses when a ByteBufferHandle\noperation method is on the inline call stack erroneously allows a read-\nonly buffer to be mutated on big-endian systems. The indexRO() method\nchecks for read-only buffers by loading the ByteBuffer.isReadOnly field\nwith Unsafe. That's a boolean, which in an array would occupy one byte,\nbut in a field it occupies four. Treating the load as an array access\nmeans that we only load the first byte, which on a big-endian system is\nthe high byte and therefore always zero.","shortMessageHtmlLink":"Ignore ByteBufferHandle operations in unsafe fast path"}},{"before":"ef127697cd5dc6201b6d6ae39bb3f0d0587ceb1c","after":"4b7136fa5434f03d038591bab192ed57e9e432dc","ref":"refs/heads/master","pushedAt":"2024-06-18T00:54:55.000Z","pushType":"push","commitsCount":194,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Merge pull request #19689 from ChengJin01/ffi_test_native_string_conversion_downcall_jdk21\n\n[FFI/Test_JDK21+] Convert the native string for downcall on z/OS","shortMessageHtmlLink":"Merge pull request <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2349545226\" data-permission-text=\"Title is private\" data-url=\"https://github.com/eclipse-openj9/openj9/issues/19689\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/eclipse-openj9/openj9/pull/19689/hovercard\" href=\"https://github.com/eclipse-openj9/openj9/pull/19689\">eclipse-openj9#19689</a> from ChengJin01/ffi_test_nati…"}},{"before":null,"after":"c4b36274a48129d0fc994e1f07594db5937fc8d8","ref":"refs/heads/aggressive-sfff","pushedAt":"2024-06-13T16:03:31.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Fold primitive-typed static final fields more aggressively\n\nWhenever the compiler attempts to fold a static final field (that hasn't\nbeen explicitly allowlisted somehow), it will now determine whether the\ndeclaring class contains a putstatic instruction that could modify one\nof its static final fields outside of <clinit>. The presence of such a\nputstatic instruction prevents folding, but it should be extremely rare,\nsince javac doesn't generate any.\n\nWe can assume JCL classes won't attempt to store to static final fields\noutside of <clinit>, and classes with class file version 53 or later\nwon't succeed even if they do attempt it. Other classes, i.e. non-JCL\nclasses with version 52 or earlier, will have their bytecode scanned.\n\nIf no putstatic instruction interferes, all primitive-typed static final\nfields will now be folded without any runtime assumption. If the field\ncould potentially be modified later, e.g. using some reflection hack or\nUnsafe, the compiled code is not required to see the new value. This is\nalso true of references, but due to limitations in the JIT's handling of\nknown objects, those still require runtime assumptions if there is any\npossibility they will be modified later.\n\nLater on, when it becomes possible to treat reference-typed static final\nfields the same way, it should be possible to entirely eliminate guarded\nstatic final field folding.","shortMessageHtmlLink":"Fold primitive-typed static final fields more aggressively"}},{"before":"c4b36274a48129d0fc994e1f07594db5937fc8d8","after":null,"ref":"refs/heads/aggressive-sfff","pushedAt":"2024-06-13T16:01:47.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"}},{"before":"892232a512ee2637dd482a4dad5f351dda362e56","after":"c4b36274a48129d0fc994e1f07594db5937fc8d8","ref":"refs/heads/aggressive-sfff","pushedAt":"2024-06-13T16:01:41.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Fold primitive-typed static final fields more aggressively\n\nWhenever the compiler attempts to fold a static final field (that hasn't\nbeen explicitly allowlisted somehow), it will now determine whether the\ndeclaring class contains a putstatic instruction that could modify one\nof its static final fields outside of <clinit>. The presence of such a\nputstatic instruction prevents folding, but it should be extremely rare,\nsince javac doesn't generate any.\n\nWe can assume JCL classes won't attempt to store to static final fields\noutside of <clinit>, and classes with class file version 53 or later\nwon't succeed even if they do attempt it. Other classes, i.e. non-JCL\nclasses with version 52 or earlier, will have their bytecode scanned.\n\nIf no putstatic instruction interferes, all primitive-typed static final\nfields will now be folded without any runtime assumption. If the field\ncould potentially be modified later, e.g. using some reflection hack or\nUnsafe, the compiled code is not required to see the new value. This is\nalso true of references, but due to limitations in the JIT's handling of\nknown objects, those still require runtime assumptions if there is any\npossibility they will be modified later.\n\nLater on, when it becomes possible to treat reference-typed static final\nfields the same way, it should be possible to entirely eliminate guarded\nstatic final field folding.","shortMessageHtmlLink":"Fold primitive-typed static final fields more aggressively"}},{"before":null,"after":"892232a512ee2637dd482a4dad5f351dda362e56","ref":"refs/heads/aggressive-sfff","pushedAt":"2024-06-13T15:54:36.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Fold primitive-typed static final fields more aggressively\n\nWhenever the compiler attempts to fold a static final field (that hasn't\nbeen explicitly allowlisted somehow), it will now determine whether the\ndeclaring class contains a putstatic instruction that could modify one\nof its static final fields outside of <clinit>. The presence of such a\nputstatic instruction prevents folding, but it should be extremely rare,\nsince javac doesn't generate any.\n\nWe can assume JCL classes won't attempt to store to static final fields\noutside of <clinit>, and classes with class file version 53 or later\nwon't succeed even if they do attempt it. Other classes, i.e. non-JCL\nclasses with version 52 or earlier, will have their bytecode scanned.\n\nIf no putstatic instruction interferes, all primitive-typed static final\nfields will now be folded without any runtime assumption. If the field\ncould potentially be modified later, e.g. using some reflection hack or\nUnsafe, the compiled code is not required to see the new value. This is\nalso true of references, but due to limitations in the JIT's handling of\nknown objects, those still require runtime assumptions if there is any\npossibility they will be modified later.","shortMessageHtmlLink":"Fold primitive-typed static final fields more aggressively"}},{"before":null,"after":"33b5a605e7fb42068e04820f0f5af9a39bd39155","ref":"refs/heads/checkExactType-nullchk","pushedAt":"2024-05-29T00:37:54.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Generate a NULLCHK when transforming checkExactType() into ZEROCHK\n\nIt's possible for the MethodHandle to be null, in which case the attempt\nto load its type field would result in an unexpected segfault.","shortMessageHtmlLink":"Generate a NULLCHK when transforming checkExactType() into ZEROCHK"}},{"before":"43ea1bc042eb6c830dfcd61b2c39a026bb8d32ad","after":"642115d2b8dc6b6af6d99a99781afd7690e092b3","ref":"refs/heads/ojdk-vh-ufp","pushedAt":"2024-05-28T15:31:08.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Revert \"Revert \"Optimize OpenJDK VarHandle operation methods\"\"\n\nThis reverts commit 37a3b8ad1f92947e4232c3cda4efca9c9d5402aa,\neffectively repeating 0f1343b5bebf820a829711a3b4a64c213e3f03d4.","shortMessageHtmlLink":"Revert \"Revert \"Optimize OpenJDK VarHandle operation methods\"\""}},{"before":null,"after":"43ea1bc042eb6c830dfcd61b2c39a026bb8d32ad","ref":"refs/heads/ojdk-vh-ufp","pushedAt":"2024-05-28T15:13:50.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Revert \"Revert \"Optimize OpenJDK VarHandle operation methods\"\"\n\nThis reverts commit 37a3b8ad1f92947e4232c3cda4efca9c9d5402aa,\neffectively repeating 0f1343b5bebf820a829711a3b4a64c213e3f03d4.","shortMessageHtmlLink":"Revert \"Revert \"Optimize OpenJDK VarHandle operation methods\"\""}},{"before":"78f3bb783e52712ff0ba358c2571ea82471d34d9","after":"ef127697cd5dc6201b6d6ae39bb3f0d0587ceb1c","ref":"refs/heads/master","pushedAt":"2024-05-27T18:37:44.000Z","pushType":"push","commitsCount":227,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Merge pull request #19538 from knn-k/macosBuild\n\nAdd comment on non-cmake build on AArch64 macOS","shortMessageHtmlLink":"Merge pull request <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2311938713\" data-permission-text=\"Title is private\" data-url=\"https://github.com/eclipse-openj9/openj9/issues/19538\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/eclipse-openj9/openj9/pull/19538/hovercard\" href=\"https://github.com/eclipse-openj9/openj9/pull/19538\">eclipse-openj9#19538</a> from knn-k/macosBuild"}},{"before":null,"after":"0cb4aa5951855c28b6e6fc61e3d8570b6ff220a7","ref":"refs/heads/vh-asdirect","pushedAt":"2024-05-21T15:45:19.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Stop predicting VH.asDirect()/directVarHandleTarget() during inlining\n\nThe MethodHandle can be found without knowing the result of this call\nbecause it's looked up based on the original VarHandle reference, not\nthe one from directVarHandleTarget(), and this is enough to allow the\ninliner to inline the entire access.\n\nAdditionally, the compiler has been failing to determine the result\nanyway. The logic deleted here would give up whenever the VarHandle was\nan instance of a subclass, which it seems is always the case.\n\nNothing looks for directVarHandleTarget() anymore, so it will no longer\nbe recognized. But asDirect() will continue to be recognized for\nisJSR292SmallGetterMethod().","shortMessageHtmlLink":"Stop predicting VH.asDirect()/directVarHandleTarget() during inlining"}},{"before":"dc5644368e4c35129a204c9c6685deea4b7e82f5","after":"78f3bb783e52712ff0ba358c2571ea82471d34d9","ref":"refs/heads/master","pushedAt":"2024-05-14T18:08:24.000Z","pushType":"push","commitsCount":88,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Merge pull request #19285 from knn-k/macOSBreakpoint\n\nEnable JIT breakpoint on macOS","shortMessageHtmlLink":"Merge pull request <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2232539443\" data-permission-text=\"Title is private\" data-url=\"https://github.com/eclipse-openj9/openj9/issues/19285\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/eclipse-openj9/openj9/pull/19285/hovercard\" href=\"https://github.com/eclipse-openj9/openj9/pull/19285\">eclipse-openj9#19285</a> from knn-k/macOSBreakpoint"}},{"before":"2103d46424428958a9a37ceeba942aabb63b1f92","after":"f3783e061ae7781e74e72e6740adcf2eb073fc03","ref":"refs/heads/redef-gc-44","pushedAt":"2024-03-22T23:33:07.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Avoid heap walk and GC for MemberName fix-up on class redefinition\n\nIn class redefinition the affected MemberName objects were previously\nidentified by iterating over all objects in the heap. The heap walk also\nnecessitated a GC cycle to eliminate dead objects, which could otherwise\ncause the fix-up to crash.\n\nThis heap walk and GC cycle were causing a significant performance\nregression in redefinition for builds using OpenJDK MethodHandles (i.e.\nJava 17+) vs. ones using J9 MethodHandles. The regression was especially\ndrastic in fast HCR mode, where no other heap walk is necessary and\ntherefore the time taken for redefinition should be largely independent\nof the number of objects in the heap.\n\nNow instead each J9Class has a list of JNI weak global references to all\nof the MemberName objects that are resolved (i.e. have vmtarget set) to\na member of that class (as determined by the clazz field). Redefinition\nuses these lists to identify the affected MemberNames without inspecting\nany other objects, and in particular without walking the heap. Because\nthe heap walk is no longer needed, neither is the GC cycle, and both are\neliminated.\n\nThe use of weak references ensures that these lists don't prevent\nMemberName objects from being reclaimed, and in particular that they\ndon't prevent class unloading.\n\nWhen a MemberName is reclaimed, its corresponding weak reference is\ncleared, and both that reference and its linked list node become\nunnecessary. To avoid leaking this memory, such entries are removed just\nprior to the addition of a MemberName, but only if it can be expected\nthat there are any. To this end, the VM now provides an implementation\nof a native method MethodHandleNatives.markClassForMemberNamePruning(),\nwhich is expected to (exist and) be called when a MemberName that is on\na per-class list becomes unreachable (really, phantom reachable), such\nas from a cleaning action or finalizer.\n\nWithout this adjustment to the Java sources, the mechanism implemented\nin this commit will still work, but the MemberName list will leak memory\nif many MemberNames for the same class are created and then reclaimed.\n\n(cherry picked from commit e06a34ca513dc9bcbe722a7eb2c054c3d25b3334)","shortMessageHtmlLink":"Avoid heap walk and GC for MemberName fix-up on class redefinition"}},{"before":null,"after":"2103d46424428958a9a37ceeba942aabb63b1f92","ref":"refs/heads/redef-gc-44","pushedAt":"2024-03-22T23:31:17.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"}},{"before":"6f1339f8c215c82304da96ef8804e4b65d6dc18c","after":"e06a34ca513dc9bcbe722a7eb2c054c3d25b3334","ref":"refs/heads/redef-gc","pushedAt":"2024-03-22T01:04:46.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Avoid heap walk and GC for MemberName fix-up on class redefinition\n\nIn class redefinition the affected MemberName objects were previously\nidentified by iterating over all objects in the heap. The heap walk also\nnecessitated a GC cycle to eliminate dead objects, which could otherwise\ncause the fix-up to crash.\n\nThis heap walk and GC cycle were causing a significant performance\nregression in redefinition for builds using OpenJDK MethodHandles (i.e.\nJava 17+) vs. ones using J9 MethodHandles. The regression was especially\ndrastic in fast HCR mode, where no other heap walk is necessary and\ntherefore the time taken for redefinition should be largely independent\nof the number of objects in the heap.\n\nNow instead each J9Class has a list of JNI weak global references to all\nof the MemberName objects that are resolved (i.e. have vmtarget set) to\na member of that class (as determined by the clazz field). Redefinition\nuses these lists to identify the affected MemberNames without inspecting\nany other objects, and in particular without walking the heap. Because\nthe heap walk is no longer needed, neither is the GC cycle, and both are\neliminated.\n\nThe use of weak references ensures that these lists don't prevent\nMemberName objects from being reclaimed, and in particular that they\ndon't prevent class unloading.\n\nWhen a MemberName is reclaimed, its corresponding weak reference is\ncleared, and both that reference and its linked list node become\nunnecessary. To avoid leaking this memory, such entries are removed just\nprior to the addition of a MemberName, but only if it can be expected\nthat there are any. To this end, the VM now provides an implementation\nof a native method MethodHandleNatives.markClassForMemberNamePruning(),\nwhich is expected to (exist and) be called when a MemberName that is on\na per-class list becomes unreachable (really, phantom reachable), such\nas from a cleaning action or finalizer.\n\nWithout this adjustment to the Java sources, the mechanism implemented\nin this commit will still work, but the MemberName list will leak memory\nif many MemberNames for the same class are created and then reclaimed.","shortMessageHtmlLink":"Avoid heap walk and GC for MemberName fix-up on class redefinition"}},{"before":"f27b9dd44183ee5f73b503d19be3cd230caae8f3","after":"dc5644368e4c35129a204c9c6685deea4b7e82f5","ref":"refs/heads/master","pushedAt":"2024-03-21T03:20:51.000Z","pushType":"push","commitsCount":130,"pusher":{"login":"jdmpapin","name":"Devin Papineau","path":"/jdmpapin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22403820?s=80&v=4"},"commit":{"message":"Merge pull request #19194 from cjjdespres/fix-openssl-compilation\n\nDefine OpenSSL error constant if not present","shortMessageHtmlLink":"Merge pull request <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2197921085\" data-permission-text=\"Title is private\" data-url=\"https://github.com/eclipse-openj9/openj9/issues/19194\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/eclipse-openj9/openj9/pull/19194/hovercard\" href=\"https://github.com/eclipse-openj9/openj9/pull/19194\">eclipse-openj9#19194</a> from cjjdespres/fix-openssl-c…"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOS0xMFQxNTo0MjowNy4wMDAwMDBazwAAAASyP3so","startCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOS0xMFQxNTo0MjowNy4wMDAwMDBazwAAAASyP3so","endCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wMy0yMVQwMzoyMDo1MS4wMDAwMDBazwAAAAQbTp20"}},"title":"Activity · jdmpapin/openj9"}