New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP - Tiered Jitting Part Deux #12193

Merged
merged 1 commit into from Jul 25, 2017

Conversation

Projects
None yet
6 participants
@noahfalk
Member

noahfalk commented Jun 9, 2017

Do not merge - this is heads up only. This is a continuation of the tiered compilation work trying to establish .Net code versioning on generally more sound footing. In particular - resolving issues between ReJit and tiered compilation.

Please see code-versioning-pr-notes.md for info.

@noahfalk

This comment has been minimized.

Show comment
Hide comment
@noahfalk

noahfalk Jun 9, 2017

Member

@janvorli @gkhanna79 @jkotas @sergign60 @davmason @mikem8361 @mjsabby @dotnet/jit-contrib @discostu105
You guys might want to look at varying parts of this that interest you?

I'm hoping I can get JanV to be overall code reviewer? (sorry I know its big and will be even bigger before its done : )

Member

noahfalk commented Jun 9, 2017

@janvorli @gkhanna79 @jkotas @sergign60 @davmason @mikem8361 @mjsabby @dotnet/jit-contrib @discostu105
You guys might want to look at varying parts of this that interest you?

I'm hoping I can get JanV to be overall code reviewer? (sorry I know its big and will be even bigger before its done : )

@noahfalk

This comment has been minimized.

Show comment
Hide comment
@noahfalk

noahfalk Jun 21, 2017

Member

@janvorli @gkhanna79 @jkotas @sergign60 @davmason @mikem8361 @mjsabby @dotnet/jit-contrib @discostu105 - heads up, lots of updates

Folks writing profilers, be sure to check out the breaking change doc I added in my most recent commit.

Member

noahfalk commented Jun 21, 2017

@janvorli @gkhanna79 @jkotas @sergign60 @davmason @mikem8361 @mjsabby @dotnet/jit-contrib @discostu105 - heads up, lots of updates

Folks writing profilers, be sure to check out the breaking change doc I added in my most recent commit.

@noahfalk noahfalk referenced this pull request Jun 21, 2017

Closed

Profiling API #445

## Likely ways you will see behavior change ##
1. There will be more JITCompilation events, and potentially more ReJIT compilation events than there were before.

This comment has been minimized.

@discostu105

discostu105 Jun 21, 2017

Contributor

If there are multiple JITCompilation events for the same method, is there any way of knowing the last if these (per method)? We currently pre-compute IL-code at ModuleLoadStarted, then keep it in memory until JITCompilationStarted, then exchange it and then delete it. If there will be subsequent JITCompilationStarted events, we cannot do this optimization anymore. Is it possible to know when there is the last-stage JIT event, after which there won't be any more.
Btw: we have not implemented re-jit yet. We'd probably have the same problem there anyway.

@discostu105

discostu105 Jun 21, 2017

Contributor

If there are multiple JITCompilation events for the same method, is there any way of knowing the last if these (per method)? We currently pre-compute IL-code at ModuleLoadStarted, then keep it in memory until JITCompilationStarted, then exchange it and then delete it. If there will be subsequent JITCompilationStarted events, we cannot do this optimization anymore. Is it possible to know when there is the last-stage JIT event, after which there won't be any more.
Btw: we have not implemented re-jit yet. We'd probably have the same problem there anyway.

This comment has been minimized.

@noahfalk

noahfalk Jun 21, 2017

Member

I assume you mean that you call ICorProfilerInfo::SetILFunctionBody to do that exchange? If you called this method the first time a method JITs (as you do today), the effect of this would persist automatically for all future jittings of that same method. If I understand you correctly the only thing you might need to change is to check in your JITCompilation handler if the IL code pointer is already NULL. If it is that means you already set the IL and deleted your copy in a previous event so you should avoid calling SetILFunctionBody again with your now deleted IL pointer.

@noahfalk

noahfalk Jun 21, 2017

Member

I assume you mean that you call ICorProfilerInfo::SetILFunctionBody to do that exchange? If you called this method the first time a method JITs (as you do today), the effect of this would persist automatically for all future jittings of that same method. If I understand you correctly the only thing you might need to change is to check in your JITCompilation handler if the IL code pointer is already NULL. If it is that means you already set the IL and deleted your copy in a previous event so you should avoid calling SetILFunctionBody again with your now deleted IL pointer.

This comment has been minimized.

@discostu105

discostu105 Jun 21, 2017

Contributor

You assumed exactly right. Sounds like we will be fine.

@discostu105

discostu105 Jun 21, 2017

Contributor

You assumed exactly right. Sounds like we will be fine.

@@ -0,0 +1,29 @@
# Code Versioning Profiler Breaking Changes #

This comment has been minimized.

@SergeyKanzhelev

SergeyKanzhelev Jun 21, 2017

Can you mention code map? Are you fixing those for reJIT cases?

@SergeyKanzhelev

SergeyKanzhelev Jun 21, 2017

Can you mention code map? Are you fixing those for reJIT cases?

This comment has been minimized.

@noahfalk

noahfalk Jun 21, 2017

Member

Thanks, I had missed this one, but yes the issue is similar to GetCodeInfo3 where the API only expects one code body. As you point out the API is already somewhat broken because it doesn't handle ReJIT code bodies either.

As a tentative proposal what if we create GetILToNativeMapping3 which takes a code start address rather than a FunctionID? It will take a little research to confirm, but I don't think there should be any significant obstacle to making it work correctly for all code bodies.

@noahfalk

noahfalk Jun 21, 2017

Member

Thanks, I had missed this one, but yes the issue is similar to GetCodeInfo3 where the API only expects one code body. As you point out the API is already somewhat broken because it doesn't handle ReJIT code bodies either.

As a tentative proposal what if we create GetILToNativeMapping3 which takes a code start address rather than a FunctionID? It will take a little research to confirm, but I don't think there should be any significant obstacle to making it work correctly for all code bodies.

This comment has been minimized.

@SergeyKanzhelev

SergeyKanzhelev Jun 21, 2017

So you saying that code map is broken after tiered re jit? Adding method is fine I think

@SergeyKanzhelev

SergeyKanzhelev Jun 21, 2017

So you saying that code map is broken after tiered re jit? Adding method is fine I think

This comment has been minimized.

@noahfalk

noahfalk Jun 21, 2017

Member

So you saying that code map is broken after tiered re jit?

Yes, the end to end workflow would be broken. GetILToNativeMapping will give you a valid IL to Native map for the first code body which is jitted. However if the same method JITs a second time, the second code body may have a different native to il mapping than the first. The current API provides you no mechanism to access the native to il map that corresponds to that second code body.

@noahfalk

noahfalk Jun 21, 2017

Member

So you saying that code map is broken after tiered re jit?

Yes, the end to end workflow would be broken. GetILToNativeMapping will give you a valid IL to Native map for the first code body which is jitted. However if the same method JITs a second time, the second code body may have a different native to il mapping than the first. The current API provides you no mechanism to access the native to il map that corresponds to that second code body.

This comment has been minimized.

@SergeyKanzhelev

SergeyKanzhelev Jun 21, 2017

it is actually two questions in one. First, just want to confirm that exception stack will show the proper line number after tiered re-JIT optimized the method body. Second, can fixing of code map for re-JITed by profiler methods can be included in scope of this work.

For the second one - if it requires a new method - it is fine. Just allow to do it.

@SergeyKanzhelev

SergeyKanzhelev Jun 21, 2017

it is actually two questions in one. First, just want to confirm that exception stack will show the proper line number after tiered re-JIT optimized the method body. Second, can fixing of code map for re-JITed by profiler methods can be included in scope of this work.

For the second one - if it requires a new method - it is fine. Just allow to do it.

This comment has been minimized.

@noahfalk

noahfalk Jun 22, 2017

Member

First, just want to confirm that exception stack will show the proper line number after tiered re-JIT optimized the method body

For the Exception.StackTrace issue that you mentioned I'm keeping it separate from this work. If you only use tiered jitting and never call RequestReJIT in the profiler then exception stack traces will work properly. If you do call RequestReJIT then the pre-existing bug may give you incorrect StackTrace results and that might still exist after this work is complete.

Second, can fixing of code map for re-JITed by profiler methods can be included in scope of this work

Yes, I will include fixing GetILToNativeMapping in this work. It may not be in this checkin, but I'll get a solution in place before tiered jitting is ever enabled by default.

@noahfalk

noahfalk Jun 22, 2017

Member

First, just want to confirm that exception stack will show the proper line number after tiered re-JIT optimized the method body

For the Exception.StackTrace issue that you mentioned I'm keeping it separate from this work. If you only use tiered jitting and never call RequestReJIT in the profiler then exception stack traces will work properly. If you do call RequestReJIT then the pre-existing bug may give you incorrect StackTrace results and that might still exist after this work is complete.

Second, can fixing of code map for re-JITed by profiler methods can be included in scope of this work

Yes, I will include fixing GetILToNativeMapping in this work. It may not be in this checkin, but I'll get a solution in place before tiered jitting is ever enabled by default.

@noahfalk

This comment has been minimized.

Show comment
Hide comment
@noahfalk
Member

noahfalk commented Jun 30, 2017

@noahfalk

This comment has been minimized.

Show comment
Hide comment
@noahfalk

noahfalk Jul 4, 2017

Member

Just fyi, I created a number of work items for additional work we need to do to get tiered jitting off the ground (#12609, #12610, #12611, #12612, #12617). If your interest directly relates to one of those feel free to add your comments to them.

Member

noahfalk commented Jul 4, 2017

Just fyi, I created a number of work items for additional work we need to do to get tiered jitting off the ground (#12609, #12610, #12611, #12612, #12617). If your interest directly relates to one of those feel free to add your comments to them.

// manager's active IL version hasn't yet asked the profiler for the IL body to use, in which case we want to filter it
// out from the return in this method.
ILCodeVersion activeILVersion = pCodeVersionManager->GetActiveILCodeVersion(pModule, methodTk);
if (activeILVersion.IsNull() || activeILVersion.GetRejitState() != ILCodeVersion::kStateActive)

This comment has been minimized.

@brianrob

brianrob Jul 13, 2017

Member

Out of curiosity, do we actually need to differentiate between rejit and non-rejit IL? I like the plan that you're on here of taking the rejit code and making it more general purpose, but would like it even more if we didn't have to have a concept of rejit specific storage. If I think about this a bit more, perhaps you're using the term rejit here to represent the fact that we might not be talking about IL that is in an assembly? #Resolved

@brianrob

brianrob Jul 13, 2017

Member

Out of curiosity, do we actually need to differentiate between rejit and non-rejit IL? I like the plan that you're on here of taking the rejit code and making it more general purpose, but would like it even more if we didn't have to have a concept of rejit specific storage. If I think about this a bit more, perhaps you're using the term rejit here to represent the fact that we might not be talking about IL that is in an assembly? #Resolved

This comment has been minimized.

@noahfalk

noahfalk Jul 14, 2017

Member

ICorDebug does have 1st class knowledge of ReJIT IL via APIs like ICorDebugFunction3::GetActiveReJitRequestILCode, so we do need to distinguish. At the moment ReJit is the only thing that can change the IL from its original state in the assembly, but if we wanted to add other IL modifying capabilities in the future I think we would need rethink whether treating each case specially was the right thing to do.

The reason the debugger cares about ReJit IL is that the debugger API can be operated by the same component that is operating the profiler API. It is legal to have the profiler create new IL code that has new local variables, then the debugger views a dump of that code and assigns special meaning to profiler added locals.


In reply to: 127300842 [](ancestors = 127300842)

@noahfalk

noahfalk Jul 14, 2017

Member

ICorDebug does have 1st class knowledge of ReJIT IL via APIs like ICorDebugFunction3::GetActiveReJitRequestILCode, so we do need to distinguish. At the moment ReJit is the only thing that can change the IL from its original state in the assembly, but if we wanted to add other IL modifying capabilities in the future I think we would need rethink whether treating each case specially was the right thing to do.

The reason the debugger cares about ReJit IL is that the debugger API can be operated by the same component that is operating the profiler API. It is legal to have the profiler create new IL code that has new local variables, then the debugger views a dump of that code and assigns special meaning to profiler added locals.


In reply to: 127300842 [](ancestors = 127300842)

ILCodeVersion activeILCodeVersion = pCodeVersionManager->GetActiveILCodeVersion(pMD);
NativeCodeVersion activeChild = activeILCodeVersion.GetActiveNativeCodeVersion(pMD);
NativeCodeVersionCollection nativeCodeVersions = activeILCodeVersion.GetNativeCodeVersions(pMD);
for (NativeCodeVersionIterator iter = nativeCodeVersions.Begin(); iter != nativeCodeVersions.End(); iter++)

This comment has been minimized.

@brianrob

brianrob Jul 13, 2017

Member

Do you actually want to run CopyNativeCodeVersiontoReJitData on every element or do you only want to run it once? I read it as once based on the comment below.

@brianrob

brianrob Jul 13, 2017

Member

Do you actually want to run CopyNativeCodeVersiontoReJitData on every element or do you only want to run it once? I read it as once based on the comment below.

This comment has been minimized.

@noahfalk

noahfalk Jul 14, 2017

Member

You are right, its not consistent with the comment so I'll fix that. Just for info I would still expect that anyone using SOS with tiered jitting enabled isn't going to get a nice experience just yet. Issue #12612 is tracking some work to get SOS in better shape for this.


In reply to: 127311445 [](ancestors = 127311445)

@noahfalk

noahfalk Jul 14, 2017

Member

You are right, its not consistent with the comment so I'll fix that. Just for info I would still expect that anyone using SOS with tiered jitting enabled isn't going to get a nice experience just yet. Issue #12612 is tracking some work to get SOS in better shape for this.


In reply to: 127311445 [](ancestors = 127311445)

{
continue;
}
CopyReJitInfoToReJitData(pRejitInfo, &rgRevertedRejitData[iRejitDataReverted]);
NativeCodeVersionCollection nativeCodeVersions = ilCodeVersion.GetNativeCodeVersions(pMD);
for (NativeCodeVersionIterator iter = nativeCodeVersions.Begin(); iter != nativeCodeVersions.End(); iter++)

This comment has been minimized.

@brianrob

brianrob Jul 13, 2017

Member

Same question here.

@brianrob

brianrob Jul 13, 2017

Member

Same question here.

This comment has been minimized.

@noahfalk

noahfalk Jul 14, 2017

Member

Yep, needs same fix.


In reply to: 127311558 [](ancestors = 127311558)

@noahfalk

noahfalk Jul 14, 2017

Member

Yep, needs same fix.


In reply to: 127311558 [](ancestors = 127311558)

Show outdated Hide outdated src/inc/shash.h
@@ -175,6 +177,7 @@ if (CLR_CMAKE_PLATFORM_UNIX OR CLR_CMAKE_TARGET_ARCH_ARM64)
endif ()
add_definitions(-DFEATURE_SVR_GC)
add_definitions(-DFEATURE_SYMDIFF)
add_definitions(-DFEATURE_TIERED_COMPILATION)

This comment has been minimized.

@brianrob

brianrob Jul 13, 2017

Member

Does it matter that FEATURE_REJIT is conditionally defined, but FEATURE_TIERED_COMPILATION is unconditionally defined? #Resolved

@brianrob

brianrob Jul 13, 2017

Member

Does it matter that FEATURE_REJIT is conditionally defined, but FEATURE_TIERED_COMPILATION is unconditionally defined? #Resolved

This comment has been minimized.

@noahfalk

noahfalk Jul 14, 2017

Member

Nope, this one is by design. ReJit depends on jumpstamps and jumpstamps aren't available on ARM. Tiered compilation on the other hand solely uses Precode so it should work on all architectures.


In reply to: 127331986 [](ancestors = 127331986)

@noahfalk

noahfalk Jul 14, 2017

Member

Nope, this one is by design. ReJit depends on jumpstamps and jumpstamps aren't available on ARM. Tiered compilation on the other hand solely uses Precode so it should work on all architectures.


In reply to: 127331986 [](ancestors = 127331986)

@brianrob

This comment has been minimized.

Show comment
Hide comment
@brianrob

brianrob Jul 13, 2017

Member
TieredCompilationManager * GetTieredCompilationManager()

It looks like there's a split between what members live on AppDomain and BaseDomain. Would it make sense to pick just one, or is there a reason to split? #Resolved


Refers to: src/vm/appdomain.hpp:3831 in cc2c79e. [](commit_id = cc2c79e, deletion_comment = False)

Member

brianrob commented Jul 13, 2017

TieredCompilationManager * GetTieredCompilationManager()

It looks like there's a split between what members live on AppDomain and BaseDomain. Would it make sense to pick just one, or is there a reason to split? #Resolved


Refers to: src/vm/appdomain.hpp:3831 in cc2c79e. [](commit_id = cc2c79e, deletion_comment = False)

@noahfalk

This comment has been minimized.

Show comment
Hide comment
@noahfalk

noahfalk Jul 14, 2017

Member
TieredCompilationManager * GetTieredCompilationManager()

That split is by design (I think, I haven't historically done a lot of work that dealt with domain distinctions so its possible I've misunderstood some semantics). Code versions (CodeVersionManager) are associated with whatever domain owns their module which could be the shared domain. Similarly call counts are associated with whatever domain owns their code. The shared domain derives from BaseDomain but not AppDomain. However the tiered compilation manager jits code on a thread affinitized to an AppDomain. Threads can't affinitize to the shared domain. If a thread in AppDomain X calls method Foo and triggers the final call on the call counter then we use the TieredCompilationManager in domain X to jit, even though the code being jitted might belong to the shared domain.


In reply to: 315205327 [](ancestors = 315205327)


Refers to: src/vm/appdomain.hpp:3831 in cc2c79e. [](commit_id = cc2c79e, deletion_comment = False)

Member

noahfalk commented Jul 14, 2017

TieredCompilationManager * GetTieredCompilationManager()

That split is by design (I think, I haven't historically done a lot of work that dealt with domain distinctions so its possible I've misunderstood some semantics). Code versions (CodeVersionManager) are associated with whatever domain owns their module which could be the shared domain. Similarly call counts are associated with whatever domain owns their code. The shared domain derives from BaseDomain but not AppDomain. However the tiered compilation manager jits code on a thread affinitized to an AppDomain. Threads can't affinitize to the shared domain. If a thread in AppDomain X calls method Foo and triggers the final call on the call counter then we use the TieredCompilationManager in domain X to jit, even though the code being jitted might belong to the shared domain.


In reply to: 315205327 [](ancestors = 315205327)


Refers to: src/vm/appdomain.hpp:3831 in cc2c79e. [](commit_id = cc2c79e, deletion_comment = False)

}
const char *description = "jit lock";
INDEBUG(description = m_pszDebugMethodName;)
ListLockEntryHolder pEntry(ListLockEntry::Find(pJitLock, this, description));
ReleaseHolder<JitListLockEntry> pEntry(JitListLockEntry::Find(
pJitLock, pConfig->GetCodeVersion(), description));

This comment has been minimized.

@brianrob

brianrob Jul 17, 2017

Member

Because this entry is now version specific, is it possible that we have a race between two threads attempting to compile the same IL but with different target versions (e.g. different optimization levels), and if so, is it possible that a higher optimization level might lose out to a lower opt-level?

@brianrob

brianrob Jul 17, 2017

Member

Because this entry is now version specific, is it possible that we have a race between two threads attempting to compile the same IL but with different target versions (e.g. different optimization levels), and if so, is it possible that a higher optimization level might lose out to a lower opt-level?

This comment has been minimized.

@noahfalk

noahfalk Jul 17, 2017

Member

The entry being version specific means that those two threads aren't competing for the same lock. Each of them will run concurrently holding a lock that is specific to their version of the code.

@noahfalk

noahfalk Jul 17, 2017

Member

The entry being version specific means that those two threads aren't competing for the same lock. Each of them will run concurrently holding a lock that is specific to their version of the code.

@@ -9354,11 +9353,8 @@ void MethodTable::SetSlot(UINT32 slotNumber, PCODE slotCode)
if (fSharedVtableChunk)
{
MethodDesc* pMD = GetMethodDescForSlotAddress(slotCode);
#ifndef FEATURE_INTERPRETER

This comment has been minimized.

@brianrob

brianrob Jul 18, 2017

Member

Just curious, is there a reason to remove FEATURE_INTERPRETER in a number of places?

@brianrob

brianrob Jul 18, 2017

Member

Just curious, is there a reason to remove FEATURE_INTERPRETER in a number of places?

This comment has been minimized.

@noahfalk

noahfalk Jul 18, 2017

Member

FEATURE_INTERPRETER used to have a custom scheme for switching between the interpreted code and jitted code but as part of this work I refactored it to use the same code path that tiered jitting uses. One goal was to reduce the number of different ways we do the same thing, the other was to remove special cases from the code I needed to refactor in prestub.

@noahfalk

noahfalk Jul 18, 2017

Member

FEATURE_INTERPRETER used to have a custom scheme for switching between the interpreted code and jitted code but as part of this work I refactored it to use the same code path that tiered jitting uses. One goal was to reduce the number of different ways we do the same thing, the other was to remove special cases from the code I needed to refactor in prestub.

LOG((LF_CLASSLOADER, LL_INFO1000000,
" In PrepareILBasedCode, calling JitCompileCode\n"));
// Mark the code as hot in case the method ends up in the native image
g_IBCLogger.LogMethodCodeAccess(this);

This comment has been minimized.

@brianrob

brianrob Jul 18, 2017

Member

Is it intentional to only call this when pCode == NULL? I take it that we're not worried about logging the access here unconditionally because in precompiled code, the probes will get executed?

@brianrob

brianrob Jul 18, 2017

Member

Is it intentional to only call this when pCode == NULL? I take it that we're not worried about logging the access here unconditionally because in precompiled code, the probes will get executed?

This comment has been minimized.

@noahfalk

noahfalk Jul 18, 2017

Member

Yep that is intentional. You can see the corresponding old code lines at 1465, 1525, and 1535. I assume what you describe is the case but mostly I was just trying to be faithful to the original logic which also had the pCode == NULL check.

@noahfalk

noahfalk Jul 18, 2017

Member

Yep that is intentional. You can see the corresponding old code lines at 1465, 1525, and 1535. I assume what you describe is the case but mostly I was just trying to be faithful to the original logic which also had the pCode == NULL check.

@brianrob

This comment has been minimized.

Show comment
Hide comment
@brianrob

brianrob Jul 18, 2017

Member

@noahfalk, thanks for all the information. Overall, I think this looks good. Based on the code and our conversations about it, the architecture sounds reasonable, and from my read of the code, looks correct. My main concern is around testing, simply because there's a good amount of churn in the VM portions of method compilation and code loading. I think that your plan to run this in the stress runs is a good idea. Furthermore, I'd recommend doing some A/B testing with and without this change on at least one scenario (you may have done this already) that uses fragile NGEN, R2R and jit compilation, to make sure that this doesn't regress the decision making on which code gets used (e.g. we don't end up JIT compiling code that used to be pre-compiled).

Consider me signed-off.

Member

brianrob commented Jul 18, 2017

@noahfalk, thanks for all the information. Overall, I think this looks good. Based on the code and our conversations about it, the architecture sounds reasonable, and from my read of the code, looks correct. My main concern is around testing, simply because there's a good amount of churn in the VM portions of method compilation and code loading. I think that your plan to run this in the stress runs is a good idea. Furthermore, I'd recommend doing some A/B testing with and without this change on at least one scenario (you may have done this already) that uses fragile NGEN, R2R and jit compilation, to make sure that this doesn't regress the decision making on which code gets used (e.g. we don't end up JIT compiling code that used to be pre-compiled).

Consider me signed-off.

Add the runtime code versioning feature
This makes tiered compilation work properly with profiler ReJIT, and positions the runtime to integrate other versioning related features together in the future. See the newly added code-versioning design-doc in this commit for more information.

Breaking changes for profilers: See code-versioning-profiler-breaking-changes.md for more details.
@noahfalk

This comment has been minimized.

Show comment
Hide comment
@noahfalk

noahfalk Jul 25, 2017

Member

Commit history was squashed in preparation for checkin. The original history remains available in the tiered_jitting_m2_backup branch of my personal github repo for anyone who wants to see it.

Member

noahfalk commented Jul 25, 2017

Commit history was squashed in preparation for checkin. The original history remains available in the tiered_jitting_m2_backup branch of my personal github repo for anyone who wants to see it.

@noahfalk

This comment has been minimized.

Show comment
Hide comment
@noahfalk

noahfalk Jul 25, 2017

Member

@dotnet-bot test Windows_NT x64 Release Priority 1 Build and Test

Member

noahfalk commented Jul 25, 2017

@dotnet-bot test Windows_NT x64 Release Priority 1 Build and Test

@noahfalk

This comment has been minimized.

Show comment
Hide comment
@noahfalk

noahfalk Jul 25, 2017

Member

@dotnet-bot test Tizen armel Cross Release Build

Member

noahfalk commented Jul 25, 2017

@dotnet-bot test Tizen armel Cross Release Build

@noahfalk

This comment has been minimized.

Show comment
Hide comment
@noahfalk

noahfalk Jul 25, 2017

Member

While running through the final testing I encountered more issue (#13019) but I will check it in separately. That issue only affects people experimenting with tiered jitting turned on (so effectively only me).

Member

noahfalk commented Jul 25, 2017

While running through the final testing I encountered more issue (#13019) but I will check it in separately. That issue only affects people experimenting with tiered jitting turned on (so effectively only me).

@noahfalk noahfalk merged commit 1c9eb77 into dotnet:master Jul 25, 2017

16 checks passed

CROSS Check Build finished.
Details
CentOS7.1 x64 Debug Build and Test Build finished.
Details
FreeBSD x64 Checked Build Build finished.
Details
OSX10.12 x64 Checked Build and Test Build finished.
Details
Tizen armel Cross Debug Build Build finished.
Details
Tizen armel Cross Release Build Build finished.
Details
Ubuntu arm Cross Release Build Build finished.
Details
Ubuntu x64 Checked Build and Test Build finished.
Details
Ubuntu x64 Formatting Build finished.
Details
Ubuntu16.04 arm Cross Debug Build Build finished.
Details
Windows_NT x64 CoreCLR Perf Tests Correctness Build finished.
Details
Windows_NT x64 Debug Build and Test Build finished.
Details
Windows_NT x64 Formatting Build finished.
Details
Windows_NT x64 Release Priority 1 Build and Test Build finished.
Details
Windows_NT x86 Checked Build and Test Build finished.
Details
Windows_NT x86 CoreCLR Perf Tests Correctness Build finished.
Details

@karelz karelz modified the milestone: 2.1.0 Aug 28, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment