On Fri, 9 Apr 2021 21:59:04 GMT, Vladimir Kozlov wrote:
>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related
>> to Ahead-of-Time Compiler from JDK:
>>
>> - `jdk.aot` module — the `jaotc` tool
>> - `src/hotspot/share/aot` — loads AoT compiled code into VM for execution
On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote:
>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related
>> to Ahead-of-Time Compiler from JDK:
>>
>> - `jdk.aot` module — the `jaotc` tool
>> - `src/hotspot/share/aot` — loads AoT compiled code into VM for execution
On Wed, 3 Mar 2021 13:28:21 GMT, Lutz Schmidt wrote:
>> Dear community,
>> may I please request reviews for this fix, improving the usefulness of
>> method invocation counters.
>> - aggregation counters are retyped as uint64_t, shifting the overflow
>> probability way out (> 500 years in case o
On Tue, 2 Mar 2021 21:08:38 GMT, Lutz Schmidt wrote:
>> I see that you've fixed the types since the last comment, but it think it's
>> still broken (and has been before).
>> How about:
>> int64_t diff = ((*b)->compiled_invocation_count() -
>> (*a)->compiled_invocation_count()) + ((*b)->invocat
On Tue, 2 Mar 2021 20:43:53 GMT, Lutz Schmidt wrote:
>> So, why do we need the casts to unsigned in this method?
>
> When you increment (2^31-1), you get 2^31 which is 0x8000. When
> interpreted as signed int, it is MIN_INT. I don't want that. I want to treat
> the value as positive number
On Tue, 2 Mar 2021 20:59:46 GMT, Igor Veresov wrote:
>> Then it will never happen. These values come from
>> ```InvocationCounter::count()```. And it will never return a value > 2^31 -
>> 1.
>
> Sorry, it can return 2^31. Which would be an indication of a counter ove
On Tue, 2 Mar 2021 20:55:50 GMT, Igor Veresov wrote:
>> With overflow I do not mean "counter overflow" as it is used to trigger
>> compiler activities but plain simple "range of singed int exceeded". Should
>> I use different wording? E.g. "counte
On Tue, 2 Mar 2021 20:47:25 GMT, Lutz Schmidt wrote:
>> I'd be better to change the logic to check if the counter is ```>=
>> InvocationCounter::count_limit``` then it's in overflow.
>
> With overflow I do not mean "counter overflow" as it is used to trigger
> compiler activities but plain simp
On Thu, 25 Feb 2021 16:36:38 GMT, Igor Veresov wrote:
>> Lutz Schmidt has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> comment changes requested by TheRealMDoerr
>
> src/hotspot/share/runtime/ja
On Thu, 25 Feb 2021 09:01:10 GMT, Lutz Schmidt wrote:
>> Dear community,
>> may I please request reviews for this fix, improving the usefulness of
>> method invocation counters.
>> - aggregation counters are retyped as uint64_t, shifting the overflow
>> probability way out (> 500 years in case
On Tue, 2 Mar 2021 17:30:47 GMT, Lutz Schmidt wrote:
>> src/hotspot/share/oops/method.cpp line 518:
>>
>>> 516: // Print a "overflow" notification to create awareness.
>>> 517: const char* addMsg;
>>> 518: unsigned int maxInt = (1U<<31) - 1;
>>
>> Why not use INT_MAX?
>
> Will change.
I'
On Thu, 11 Feb 2021 17:47:54 GMT, Lutz Schmidt wrote:
>> Dear community,
>> may I please request reviews for this fix, improving the usefulness of
>> method invocation counters.
>> - aggregation counters are retyped as uint64_t, shifting the overflow
>> probability way out (> 500 years in case
On Thu, 11 Feb 2021 21:14:04 GMT, Igor Veresov wrote:
>> Lutz Schmidt 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.
>
> src/hotsp
On Tue, 2 Mar 2021 19:25:26 GMT, Lutz Schmidt wrote:
>> No it was a different question. I see my comments try clicking on the "Files
>> changed" tab and scrolling down to method.cpp.
>> I also left a comment about your changes to ```compare_methods()``` I don't
>> think it's correct.
>
> Igor,
On Tue, 2 Mar 2021 17:35:18 GMT, Lutz Schmidt wrote:
>> I have few comments.
>
> @veresov I can't see your comment re. the casts. The only comment I see is
> re. the *64 suffixes.
> Anyway, is your question/comment directly related to Vladimir's annotations?
> Or do you need further reasoning?
On Tue, 2 Mar 2021 08:34:29 GMT, Lutz Schmidt wrote:
>> Hi @RealLucy , I didn't do an actual review just made a passing comment.
>
> @dholmes-ora OK then. I just didn't want to ignore anyone's opinion.
> I plan to integrate the change before my EOB (GMT+1), provided there are no
> objections.
On Thu, 7 Jan 2021 18:43:51 GMT, Igor Veresov wrote:
> This change removes the legacy compilation policy and an emulation mode to
> the tiered policy to simulate the old behavior with
> ```-XX:-TieredCompilation```. The change removed a bunch of interpreter code,
> devir
ome
> help from the maintainers of the specific ports to verify the build and run
> basic smoke tests. I've already tested x64 and aarch64. Thanks!
Igor Veresov has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains six commits:
On Mon, 25 Jan 2021 18:13:20 GMT, Igor Veresov wrote:
>> Looks better now. I would like to see result of performance testing before
>> approving.
>
> I asked Eric to run the benchmarks. The results should be ready on Wednesday.
The benchmarking is done. No regressio
On Mon, 25 Jan 2021 17:57:29 GMT, Vladimir Kozlov wrote:
>> Igor Veresov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address Vladimir's review comments
>
> Looks better now. I would like to see r
On Fri, 22 Jan 2021 17:32:09 GMT, Igor Veresov wrote:
>> src/hotspot/share/compiler/compileBroker.cpp line 972:
>>
>>> 970:
>>> 971: // Initialize the compilation queue
>>> 972: if (_c2_count > 0) {
>>
>> Is ZERO treated as `is_interp
ome
> help from the maintainers of the specific ports to verify the build and run
> basic smoke tests. I've already tested x64 and aarch64. Thanks!
Igor Veresov has updated the pull request incrementally with one additional
commit since the last revision:
Address Vladimir'
On Fri, 22 Jan 2021 20:08:17 GMT, Vladimir Kozlov wrote:
>> It's not so easy. You can have AOT or JVMCI enabled with -Xint. JVMCI code
>> installs can be initiated not only as a result of method going through the
>> compiler broker. Remember that you can run Graal in "host" mode, where it is
>
On Fri, 22 Jan 2021 01:37:53 GMT, Vladimir Kozlov wrote:
>> Igor Veresov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Check legacy flags validity before deriving flag values for emulation mode.
>
&
On Fri, 22 Jan 2021 18:04:54 GMT, Vladimir Kozlov wrote:
>> I guess it's a matter of naming convention. What I tried to make the
>> CompilerConfig API about is to check if compilers are present/enabled and in
>> which combination. Of course presence of a compiler implies that we're going
>> to
On Fri, 22 Jan 2021 17:51:36 GMT, Vladimir Kozlov wrote:
>> Right now has_() functions are defined before uses. Do you want them to be
>> after the uses? Please confirm.
>
> Don't touch has_() - they are in correct place. I am asking only to move
> these 4 is_() functions between has_() and is_
On Fri, 22 Jan 2021 01:11:33 GMT, Vladimir Kozlov wrote:
>> Igor Veresov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix another s390 compilation failure
>
> src/hotspot/share/jvmci/vmStructs
On Fri, 22 Jan 2021 01:25:25 GMT, Vladimir Kozlov wrote:
>> Igor Veresov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Check legacy flags validity before deriving flag values for emulation mode.
>
&
On Fri, 22 Jan 2021 00:56:16 GMT, Vladimir Kozlov wrote:
>> Igor Veresov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix another s390 compilation failure
>
> src/hotspot/share/runtime/vmStructs.cpp lin
On Fri, 22 Jan 2021 00:24:34 GMT, Vladimir Kozlov wrote:
>> Igor Veresov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix another s390 compilation failure
>
> src/hotspot/share/compiler/compileBroker.cp
On Fri, 22 Jan 2021 00:43:29 GMT, Vladimir Kozlov wrote:
>> Igor Veresov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Check legacy flags validity before deriving flag values for emulation mode.
>
> src
On Wed, 20 Jan 2021 20:52:31 GMT, Vladimir Kozlov wrote:
>> Igor Veresov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Check legacy flags validity before deriving flag values for emulation mode.
>
&
On Wed, 20 Jan 2021 20:36:35 GMT, Vladimir Kozlov wrote:
>> Igor Veresov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix another s390 compilation failure
>
> src/hotspot/share/aot/aotCodeHeap.cpp line
On Wed, 20 Jan 2021 20:28:34 GMT, Vladimir Kozlov wrote:
>> Igor Veresov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Check legacy flags validity before deriving flag values for emulation mode.
>
On Wed, 20 Jan 2021 20:17:48 GMT, Vladimir Kozlov wrote:
>> Igor Veresov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Check legacy flags validity before deriving flag values for emulation mode.
>
&
On Wed, 20 Jan 2021 19:51:11 GMT, Vladimir Kozlov wrote:
>> Igor Veresov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Check legacy flags validity before deriving flag values for emulation mode.
>
&
On Mon, 11 Jan 2021 17:54:10 GMT, Igor Veresov wrote:
>> I see some regression on ARM32 with this change:
>> http://cr.openjdk.java.net/~bulasevich/tmp/8251462_jtreg_hotspot/
>
>> I see some regression on ARM32 with this change:
>> http://cr.openjdk.java.net/~bulasevic
ome
> help from the maintainers of the specific ports to verify the build and run
> basic smoke tests. I've already tested x64 and aarch64. Thanks!
Igor Veresov has updated the pull request incrementally with one additional
commit since the last revision:
Check legacy flags vali
On Mon, 11 Jan 2021 09:09:12 GMT, Boris Ulasevich
wrote:
> I see some regression on ARM32 with this change:
> http://cr.openjdk.java.net/~bulasevich/tmp/8251462_jtreg_hotspot/
I don't think those are related to the changes. Those are probably some
preexisting c1 and c2 problems respectively th
On Mon, 11 Jan 2021 09:06:36 GMT, Boris Ulasevich
wrote:
>> Igor Veresov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix another s390 compilation failure
>
> src/hotspot/cpu/arm/templateInterpr
On Fri, 8 Jan 2021 06:29:10 GMT, Igor Veresov wrote:
>> Please find the answers in-line.
>>
>>> _Mailing list message from [David Holmes](mailto:david.hol...@oracle.com)
>>> on [shenandoah-dev](mailto:shenandoah-...@openjdk.java.net):_
>>>
>>&
On Fri, 8 Jan 2021 06:07:23 GMT, Igor Veresov wrote:
>> Marking as reviewed, but only for the jvmti tests. I don't believe there are
>> any other svc changes in this PR.
>
> Please find the answers in-line.
>
>> _Mailing list message from [David Holmes](ma
On Thu, 7 Jan 2021 21:49:56 GMT, Chris Plummer wrote:
>> Igor Veresov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix s390 build
>
> Marking as reviewed, but only for the jvmti tests. I don't
ome
> help from the maintainers of the specific ports to verify the build and run
> basic smoke tests. I've already tested x64 and aarch64. Thanks!
Igor Veresov has updated the pull request incrementally with one additional
commit since the last revision:
Fix another s390 compil
ome
> help from the maintainers of the specific ports to verify the build and run
> basic smoke tests. I've already tested x64 and aarch64. Thanks!
Igor Veresov has updated the pull request incrementally with one additional
commit since the last revision:
Fix s390
On Thu, 7 Jan 2021 20:50:50 GMT, Chris Plummer wrote:
>> Igor Veresov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix s390 build
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203
This change removes the legacy compilation policy and an emulation mode to the
tiered policy to simulate the old behavior with ```-XX:-TieredCompilation```.
The change removed a bunch of interpreter code, devirtualizes the compilation
policy API, adds a consistent way to query compiler configura
On Fri, 30 Oct 2020 17:40:51 GMT, Vladimir Kozlov wrote:
> We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an
> experimental feature. We shipped Graal as an experimental JIT compiler in JDK
> 10. We haven't seen much use of these features, and the effort required to
> suppor
s good.
>>
>> dl
>>
>> On 11/28/18 10:57 PM, Igor Veresov wrote:
>>> It would work right now. But I don’t want us fixing it again when somebody
>>> implements effectively final optimization in Graal.
>>>
>>> igor
>>>
>>>
> you had
>
> static int POISON = 0x1234; // not final
>
> class TaggedClass {
> static int field1 = 0xC0DE01 + POISON;
>
> in HeapFilter.java, is the compiler smart enough to treat the value as
> constant until it changes?
>
> dl
>
> On 11/28/18 9:26 P
Alright, how about the following solution:
http://cr.openjdk.java.net/~iveresov/8193577/webrev.01/
igor
> On Nov 28, 2018, at 4:59 PM, Igor Veresov wrote:
>
> I don’t want to make it Graal specific. I think I’ll just do field
> assignments in native so that it’s all invi
api for that.
>
> I was thinking about the same.
> Relaxing this just for Graal sounds good.
> On the other hand, making the test to know about Graal looks a little bit
> strange. :)
>
> Thanks,
> Serguei
>
>>
>> dl
>>
>> On 11/28/18 2:28 PM,
this case there are going to be multiple
objects on the heap with only one of them being reachable.
igor
> On Nov 28, 2018, at 2:08 PM, Igor Veresov wrote:
>
> I don’t think there is a way to identify an untagged object. There is nothing
> that is passed in the callback t
gt; Thanks,
> Serguei
>
>
> On 11/28/18 13:13, Igor Veresov wrote:
>> When doing heap iteration with JVMTI the way the object identity is tracked
>> is by tagging. This particular test checks if it can observe an untagged
>> object. Since there is no way to truly tr
the test objects? If so, can't we fix the matching so that it checks that
> all fields of an object match? I guess that would mean moving the "expected"
> and "found" counts up from fields[] to objects_info[].
>
> dl
>
> On 11/28/18 1:13 PM, Igor Vereso
When doing heap iteration with JVMTI the way the object identity is tracked is
by tagging. This particular test checks if it can observe an untagged object.
Since there is no way to truly track the identity of an untagged object the
test validates the identity by checking the value of the field
e If contiguous inline allocations are enabled, try that
> 3) Goto Slowpath
>
> With your fix, even if we do not have the issue anymore, it still keeps code
> that is not consistent but perhaps I'm missing something?
> Jc
>
> On Sat, Jul 21, 2018 at 1:47 PM Igor
I think you can just predicate the emission of these stubs for !UseTLAB, and
not mess with the CPU-specific code. What do you think?
diff --git a/src/hotspot/share/c1/c1_LIRGenerator.cpp
b/src/hotspot/share/c1/c1_LIRGenerator.cpp
--- a/src/hotspot/share/c1/c1_LIRGenerator.cpp
+++ b/src/hotspot/s
Looks good to me.
igor
> On Apr 12, 2018, at 11:24 AM, Doug Simon wrote:
>
> Please review this change that removes the existing Graal service provider
> for hooking into the Platform MBean Server and makes
> jdk.internal.vm.compiler.management an upgradeable module.
>
> Please refer to
> h
On 12/3/10 7:08 PM, David Holmes wrote:
Keith McGuigan said the following on 12/03/10 23:19:
On Dec 3, 2010, at 3:30 AM, Igor Veresov wrote:
You're calling notify_gc_end() while holding the FullGCCount_lock. Is
that ok? Would it be more prudent to divert control to the user
without holdi
You're calling notify_gc_end() while holding the FullGCCount_lock. Is
that ok? Would it be more prudent to divert control to the user without
holding it?
igor
On 12/2/10 2:29 PM, Keith McGuigan wrote:
This fix adds JVMTI callbacks for CMS full GCs:
http://cr.openjdk.java.net/~kamg/6458402/w
61 matches
Mail list logo
