Re: RFR: 8307462: [REDO] VmObjectAlloc is not generated by intrinsics methods which allocate objects [v3]

2023-08-08 Thread Leonid Mesnik
On Fri, 4 Aug 2023 20:37:00 GMT, Serguei Spitsyn wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional >> commit since the last revision: >> >> The too many deopts check should be first. > > This looks okay to me. > It needs to be reviewed by someone from the

Re: RFR: 8307462: [REDO] VmObjectAlloc is not generated by intrinsics methods which allocate objects [v3]

2023-08-08 Thread Tobias Hartmann
On Fri, 4 Aug 2023 19:45:56 GMT, Leonid Mesnik wrote: >> The fix adds posting VmObjectAlloc events by >> Unsafe.allocateInstance(Class cls). The previous attempt to post event >> directly from 'LibraryCallKit::inline_unsafe_allocate()' cause performance >> regression even if jvmti event is not

Re: RFR: 8307462: [REDO] VmObjectAlloc is not generated by intrinsics methods which allocate objects [v3]

2023-08-04 Thread Serguei Spitsyn
On Fri, 4 Aug 2023 19:45:56 GMT, Leonid Mesnik wrote: >> The fix adds posting VmObjectAlloc events by >> Unsafe.allocateInstance(Class cls). The previous attempt to post event >> directly from 'LibraryCallKit::inline_unsafe_allocate()' cause performance >> regression even if jvmti event is not

Re: RFR: 8307462: [REDO] VmObjectAlloc is not generated by intrinsics methods which allocate objects [v3]

2023-08-04 Thread Leonid Mesnik
> The fix adds posting VmObjectAlloc events by Unsafe.allocateInstance(Class > cls). The previous attempt to post event directly from > 'LibraryCallKit::inline_unsafe_allocate()' cause performance regression even > if jvmti event is not enabled. Some optimizations have been disabled just > bec