On Tue, 20 Oct 2020 09:27:45 GMT, Nick Gasson wrote:
> When using the Linux "perf" tool to do system profiling, symbol names of
> running Java methods cannot be decoded, resulting in unhelpful output
> such as:
>
> 10.52% [JIT] tid 236748 [.] 0x7f6fdb75d223
>
> Perf can read a simple text
On Wed, 14 Oct 2020 22:25:34 GMT, Alex Menkov wrote:
> Please review the fix for JDK-6606767.
> The original issue is not reproducible.
> The fix:
> - resexhausted003 and resexhausted004 are un-problemlisted
> - resexhausted004 is problemlisted on linux due JDK-8253916 (resexhausted004
> execute
On Tue, 20 Oct 2020 21:53:10 GMT, Richard Reingruber wrote:
> The following test cases try to provoke VMOutOfMemoryException during object
> reallocation:
>
> EAPopFrameNotInlinedReallocFailure
> EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure
> EAForceEarlyReturnOfInlinedMethodWithSc
The following test cases try to provoke VMOutOfMemoryException during object
reallocation:
EAPopFrameNotInlinedReallocFailure
EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure
EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure
This is not 100% reliable therefore it
On Tue, 20 Oct 2020 01:13:33 GMT, Chris Plummer wrote:
>> although horizontal alignment (of variable names, initialization,
>> expressions, etc) seems to somewhat improve
>> readability, it almost always associated with a higher maintenance cost, and
>> the current consensus is not to do that.
On Tue, 20 Oct 2020 19:42:38 GMT, Robbin Ehn wrote:
> Thanks, I'm exploring what we need to execute the EB inside the handshake.
I want to experiment with object reallocation without referencing a frame. I
think a should be possible to reallocate
objects given only the corresponding compiled pc
On Tue, 20 Oct 2020 17:53:47 GMT, Richard Reingruber wrote:
>>>
>>>
>>> > Hi,
>>> > this is a good change, because it is a simplification and it it makes the
>>> > stack walks safe by doing them as part of a
>>> > handshake. The change conflicts with #119 though. This one is ready to be
>>> >
On Tue, 20 Oct 2020 17:54:21 GMT, Vladimir Kozlov wrote:
>> ...or I can put new test into a separate file. But the existing test is
>> quite inferior compared to the new one, so it
>> does not seem to make a lot of sense to keep it.
>
> It was mistake in 8253191 (I file bug). If you modify exist
On Tue, 20 Oct 2020 17:43:07 GMT, Aleksey Shipilev wrote:
>> Well, I am replacing the entire file. There is a recent precedent of the
>> similar change
>> [here](https://github.com/openjdk/jdk/commit/6d13c766#diff-0daf75421f8fdb55a5640742ef6f12730fe1b370cc864311c188ad6b51fe).
>> Either that
On Tue, 20 Oct 2020 15:33:59 GMT, Richard Reingruber wrote:
>>> Hi,
>>>
>>> this is a good change, because it is a simplification and it it makes the
>>> stack walks safe by doing them as part of a
>>> handshake.
>>> The change conflicts with #119 though. This one is ready to be pushed since
>
On Tue, 20 Oct 2020 17:42:00 GMT, Aleksey Shipilev wrote:
>> test/jdk/java/lang/instrument/GetObjectSizeTest.java line 2:
>>
>>> 1: /*
>>> 2: * Copyright (c) 2020, Red Hat, Inc. All rights reserved.
>>
>> You can't replace Copyright lines of one company with other.
>
> Well, I am replacing the
On Tue, 20 Oct 2020 17:33:56 GMT, Vladimir Kozlov wrote:
>> Aleksey Shipilev has refreshed the contents of this pull request, and
>> previous commits have been removed. The
>> incremental views will show differences compared to the previous content of
>> the PR.
>
> test/jdk/java/lang/instrumen
On Mon, 19 Oct 2020 06:57:24 GMT, Aleksey Shipilev wrote:
>> This is fork off the SizeOf JEP, JDK-8249196. There is already the entry
>> point in JDK that can use the intrinsic like
>> this: `Instrumentation.getInstanceSize`. Therefore, we can implement the
>> C1/C2 intrinsic now, hook it up to
On Tue, 20 Oct 2020 10:24:35 GMT, Aleksey Shipilev wrote:
>> This is fork off the SizeOf JEP, JDK-8249196. There is already the entry
>> point in JDK that can use the intrinsic like
>> this: `Instrumentation.getInstanceSize`. Therefore, we can implement the
>> C1/C2 intrinsic now, hook it up to
On Thu, 10 Sep 2020 20:48:23 GMT, Richard Reingruber wrote:
> Hi,
>
> this is the continuation of the review of the implementation for:
>
> https://bugs.openjdk.java.net/browse/JDK-8227745
> https://bugs.openjdk.java.net/browse/JDK-8233915
>
> It allows for JIT optimizations based on escape an
On Tue, 20 Oct 2020 14:18:57 GMT, Robbin Ehn wrote:
>
>
> > Hi,
> > this is a good change, because it is a simplification and it it makes the
> > stack walks safe by doing them as part of a
> > handshake. The change conflicts with #119 though. This one is ready to be
> > pushed since last wee
On Tue, 20 Oct 2020 14:10:49 GMT, Richard Reingruber wrote:
> Hi,
>
> this is a good change, because it is a simplification and it it makes the
> stack walks safe by doing them as part of a
> handshake.
> The change conflicts with #119 though. This one is ready to be pushed since
> last week b
On Tue, 20 Oct 2020 12:53:15 GMT, Robbin Ehn wrote:
>> Why don't you just do:
>> JavaThread* java_thread = JavaThread::current();
>> HandleMark hm(java_thread);
>>
>> JavaThread::current is the same thing as what you have.
>>
>> Oh I see there are two different threads. nevermind.
>
> Hi Coleen
On Tue, 20 Oct 2020 11:55:49 GMT, David Holmes wrote:
>> Robbin Ehn has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Removed TraceSuspendDebugBits
>> - Removed unused method is_ext_suspend_completed_with_lock
>
> Still looks good.
Hi,
On Tue, 20 Oct 2020 12:06:57 GMT, Coleen Phillimore wrote:
>> Yes, that would be good.
>
> Why don't you just do:
> JavaThread* java_thread = JavaThread::current();
> HandleMark hm(java_thread);
>
> JavaThread::current is the same thing as what you have.
Hi Coleen, we are in a handshake.
Target
On Tue, 20 Oct 2020 10:32:26 GMT, Robbin Ehn wrote:
>> The main point of this change-set is to make it easier to implement S/R on
>> top of handshakes.
>> Which is a prerequisite for removing _suspend_flag (which duplicates the
>> handshake functionality).
>> But we also remove some complicated
On Tue, 20 Oct 2020 09:27:45 GMT, Nick Gasson wrote:
> When using the Linux "perf" tool to do system profiling, symbol names of
> running Java methods cannot be decoded, resulting in unhelpful output
> such as:
>
> 10.52% [JIT] tid 236748 [.] 0x7f6fdb75d223
>
> Perf can read a simple text
On Tue, 20 Oct 2020 09:27:45 GMT, Nick Gasson wrote:
> When using the Linux "perf" tool to do system profiling, symbol names of
> running Java methods cannot be decoded, resulting in unhelpful output
> such as:
>
> 10.52% [JIT] tid 236748 [.] 0x7f6fdb75d223
>
> Perf can read a simple text
> The main point of this change-set is to make it easier to implement S/R on
> top of handshakes.
> Which is a prerequisite for removing _suspend_flag (which duplicates the
> handshake functionality).
> But we also remove some complicated S/R methods.
>
> We basically just put in everything in t
> This is fork off the SizeOf JEP, JDK-8249196. There is already the entry
> point in JDK that can use the intrinsic like
> this: `Instrumentation.getInstanceSize`. Therefore, we can implement the
> C1/C2 intrinsic now, hook it up to
> `Instrumentation`, and let the tools use that fast path today
On Mon, 19 Oct 2020 18:13:59 GMT, Vladimir Kozlov wrote:
>> Aleksey Shipilev has refreshed the contents of this pull request, and
>> previous commits have been removed. The
>> incremental views will show differences compared to the previous content of
>> the PR.
>
> Always run graalunit testing
On Tue, 20 Oct 2020 07:12:01 GMT, Robbin Ehn wrote:
>> Hi Robbin,
>>
>> IIUC the "waiting" part of `wait_for_ext_suspend_completion` is now
>> implicitly handled in the handshake - correct?
>>
>> Overall this seems like a great simplification.
>>
>> A few minor comments below.
>>
>> Thanks,
On Mon, 19 Oct 2020 18:13:59 GMT, Vladimir Kozlov wrote:
>> Aleksey Shipilev has refreshed the contents of this pull request, and
>> previous commits have been removed. The
>> incremental views will show differences compared to the previous content of
>> the PR.
>
> Always run graalunit testing
When using the Linux "perf" tool to do system profiling, symbol names of
running Java methods cannot be decoded, resulting in unhelpful output
such as:
10.52% [JIT] tid 236748 [.] 0x7f6fdb75d223
Perf can read a simple text file format describing the mapping between
address ranges and symbol
On Tue, 20 Oct 2020 08:30:24 GMT, Stefan Johansson wrote:
> For future reference, you should avoid force pushing changes to open PRs.
> Instead of rebasing you can merge with master
> to make your branch up to date. This time it don't really matter since we
> didn't have any comments in the cod
On Tue, 20 Oct 2020 07:44:54 GMT, Lin Zang wrote:
>>> Dear @stefank,
>>> I have update this PR that use a claimer to help worker thread do parallel
>>> iteration. would you like to help review
>>> again? Thanks,
>>> Lin
>>
>> Wrong Stefan, I think you mean @kstefanj
>
> Hi @stefank,
> So s
On Tue, 20 Oct 2020 07:40:28 GMT, Stefan Karlsson wrote:
>> Dear @stefank,
>> I have update this PR that use a claimer to help worker thread do parallel
>> iteration. would you like to help review
>> again? Thanks,
>> Lin
>
>> Dear @stefank,
>> I have update this PR that use a claimer to help wo
On Mon, 19 Oct 2020 12:21:27 GMT, Lin Zang wrote:
> Dear @stefank,
> I have update this PR that use a claimer to help worker thread do parallel
> iteration. would you like to help review
> again? Thanks,
> Lin
Wrong Stefan, I think you mean @kstefanj
-
PR: https://git.openjdk.java
On 20/10/2020 5:20 pm, Robbin Ehn wrote:
On Tue, 20 Oct 2020 02:22:15 GMT, David Holmes wrote:
The main point of this change-set is to make it easier to implement S/R on top
of handshakes.
Which is a prerequisite for removing _suspend_flag (which duplicates the
handshake functionality).
But
On Tue, 20 Oct 2020 02:22:15 GMT, David Holmes wrote:
>> The main point of this change-set is to make it easier to implement S/R on
>> top of handshakes.
>> Which is a prerequisite for removing _suspend_flag (which duplicates the
>> handshake functionality).
>> But we also remove some complicat
On Tue, 20 Oct 2020 02:28:35 GMT, David Holmes wrote:
>> The main point of this change-set is to make it easier to implement S/R on
>> top of handshakes.
>> Which is a prerequisite for removing _suspend_flag (which duplicates the
>> handshake functionality).
>> But we also remove some complicat
36 matches
Mail list logo
