- Notifications
You must be signed in to change notification settings - Fork 1.2k
some write barrier fixes #2293
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
some write barrier fixes #2293
Conversation
leirocks commented Dec 28, 2016
- false poisitive on EntryPointInfo->jsMethod after native address reuse in recycler
- false poisitive in arena allocator cacheBlockEnd reused in leaf block in recycler (sharing same page allocator)
- overload ChangeToAssign in JIT code, check all posible assign for write barrier
- missing barriers in various location
+ minor fixes to JavascriptOperatorA.S
In addition to Debugger support, this PR also brings the required base for compiling code with script profiler.
…es a union in a way that allows a ParseableFunctionInfo to be accessed as though it were a FunctionBody. This led to memory corruption when redeferral changed the meaning of a flag that was meant to protect the accesses. Fixed by removing the union and the flag and using IsFunctionBody/GetFunctionBody to guard against illegal access.
…Works around a parser anomaly that appeared with re-deferral. I'll keep investigating the cause of the anomaly.
Add annotation in CodeGenNumberAllocator.cpp to suppress sal warning. Restructure code in Encoder.cpp, the two function calls were throwing off the analyzer.
Merge pull request chakra-core#2273 from pleath:startbindfunction ByteCodeGenerator::StartBindFunction uses a union in a way that allows a ParseableFunctionInfo to be accessed as though it were a FunctionBody. This led to memory corruption when redeferral changed the meaning of a flag that was meant to protect the accesses. Fixed by removing the union and the flag and using IsFunctionBody/GetFunctionBody to guard against illegal access.
…n fix Merge pull request chakra-core#2273 from pleath:startbindfunction ByteCodeGenerator::StartBindFunction uses a union in a way that allows a ParseableFunctionInfo to be accessed as though it were a FunctionBody. This led to memory corruption when redeferral changed the meaning of a flag that was meant to protect the accesses. Fixed by removing the union and the flag and using IsFunctionBody/GetFunctionBody to guard against illegal access.
Merge pull request chakra-core#2279 from meg-gupta:fixsal Add annotation in CodeGenNumberAllocator.cpp to suppress sal warning. Restructure code in Encoder.cpp, the two function calls were throwing off the analyzer.
Merge pull request chakra-core#2279 from meg-gupta:fixsal Add annotation in CodeGenNumberAllocator.cpp to suppress sal warning. Restructure code in Encoder.cpp, the two function calls were throwing off the analyzer.
…tub for a non-deferred function. Merge pull request chakra-core#2225 from pleath:9871933 Works around a parser anomaly that appeared with re-deferral. I'll keep investigating the cause of the anomaly.
… a deferred stub for a non-deferred function. Merge pull request chakra-core#2225 from pleath:9871933 Works around a parser anomaly that appeared with re-deferral. I'll keep investigating the cause of the anomaly.
Merge pull request chakra-core#2056 from obastemur:debug In addition to Debugger support, this PR also brings the required base for compiling code with script profiler. Fixes chakra-core#2058
…ompiler direction Merge pull request chakra-core#2211 from obastemur:fix_pie + minor fixes to JavascriptOperatorA.S
Merge pull request chakra-core#2272 from obastemur:fix_asmjs_crash
# Conflicts: # build.sh # lib/Runtime/Base/FunctionBody.h
a562259 to 21bc6f2 Compare | @dotnet-bot test Linux tests please |
| @dotnet-bot test Linux tests please |
| @dotnet-bot test Linux tests please |
| @dotnet-bot test Linux tests please |
| @dotnet-bot test Linux tests please |
| @dotnet-bot test Linux tests please |
| @dotnet-bot test Linux tests please |
| @dotnet-bot test Linux tests please |
| @dotnet-bot test OSX daily_osx_osx_test_static please |
…e barrier) and some other fix for no write barrier build on windows
looks there's a bug in llvm lto: dlopen() failed; dlerror says '/home/ddccstemp/swb/lto/libChakraCore.so: undefined symbol: _ZTHN6Memory24MemoryOperationLastError14MemOpLastErrorE' this symbol should have been removed after optimization. manually remove here
| @dotnet-bot test Linux tests please |
| @dotnet-bot test Linux tests please |
| @dotnet-bot test Linux tests please |
for some struct like InterpreterStackFrame it's hard to add write barrier annotation. let the recycler aware of such memory, set barrier before rescanning(assuming it's always dirty) currently applied this to generator function feature
while debugger attaching, it deletes current NativeCodeGenerator and free all the native address. then these address can be easily reused by recycler also add more tags on the functionBody to prevent the bit fields becoming pointer like value Record write barrier bit clearing for debugging purpose
| @dotnet-bot test Linux tests please |
lib/Runtime/Base/FunctionBody.cpp Outdated
| #endif | ||
| if (validationCookie == currentCookie) | ||
| { | ||
| if (this->jsMethod == reinterpret_cast<Js::JavascriptMethod>(this->GetNativeAddress())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (this->jsMethod == reinterpret_castJs::JavascriptMethod(this->GetNativeAddress())) [](start = 20, length = 87)
When "jsMethod != ...", what would "jsMethod" contain, could it still create other false positives? Is it ok to always do this without checking "jsMethod != ..."?
| if binary == None: | ||
| if sys.platform == 'win32': | ||
| binary = 'Build/VcBuild/bin/{}_{}/ch.exe'.format(arch, flavor) | ||
| binary = 'Build\\VcBuild\\bin\\{}_{}\\ch.exe'.format(arch, flavor) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Build\VcBuild\bin\{}_{}\ch.exe [](start = 18, length = 34)
Just curious, is this change necessary? I've been running it on Windows and "/" worked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you copy the command line with /, ttt won't work...
lib/Runtime/Base/FunctionBody.h Outdated
| FieldWithBarrier(bool) hasExecutionDynamicProfileInfo : 1; | ||
| #ifdef _M_X64_OR_ARM64 | ||
| FieldWithBarrier(bool) m_tag : 1; // Used to tag the low bit to prevent possible GC false references | ||
| #endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why moving "m_tag"... is it because x64 difference with x86? If so would this make x86 worse?
Also this should be a build break on x86, as now "m_tag" only declared on x64 but initialized on both. (I'm reading in commit order, this could be fixed in later commit.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, in later commit, I carefully added tag for every 4 bytes. and this won't be build break either, for x86 m_tag is defined in another .h file :)
| HRESULT ExecuteTestWithMemoryCheck(char* fileName) | ||
| { | ||
| HRESULT hr = E_FAIL; | ||
| #ifdef _WIN32 // looks on linux it always leak ThreadContextTLSEntry since there's no DllMain |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Recall Oguz did some change in master, not sure if resolves this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems not, hit assertions in linux test
| yes, it's a duplicate if global write barrier off. and I kept the plain one because many other places we are using this pattern and do the conversion inside function body In reply to: 271458604 [](ancestors = 271458604) Refers to: lib/Runtime/Base/FunctionBody.h:3702 in 50b4d1a. [](commit_id = 50b4d1a, deletion_comment = True) |
| DECLARE_SERIALIZABLE_FIELD(ProfileId, profiledReturnTypeCount, UInt16); | ||
| DECLARE_SERIALIZABLE_FIELD(ProfileId, profiledSlotCount, UInt16); | ||
| DECLARE_SERIALIZABLE_ACCESSOR_FIELD(uint, LoopCount, RegSlot); | ||
| DECLARE_SERIALIZABLE_FIELD(bool, m_tag31, Bool); // Used to tag the low bit to prevent possible GC false references |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DECLARE_SERIALIZABLE_FIELD(bool, m_tag31, Bool); [](start = 4, length = 48)
Are the "tag" fields being serialized? Is that the reason your change affected bc.h? If so can we avoid serializing the tag fields?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, it will be serialized. it's one byte more space in the bytecode. if we choose to not serializing it but add tag here, we might need to change the serializing logic. I didn't spent time on investigate how much work to do though
In reply to: 95427632 [](ancestors = 95427632)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be very easy to do. Add a new macro DECLARE_TAG_FIELD in this file which by default does nothing. In FunctionBody.h define it to declare a tag field. Serializer does not see it so no impact.
In reply to: 95429096 [](ancestors = 95429096,95427632)
| #endif | ||
| { | ||
| return RecyclerNew(this->GetRecycler(), JavascriptGenerator, generatorType, args, scriptFunction); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider moving this into a function JavascriptGenerator::New (and make constructor private) so that the logic at the same place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
|
Merge pull request chakra-core#2293 from leirocks:wb3 - false poisitive on EntryPointInfo->jsMethod after native address reuse in recycler - false poisitive in arena allocator cacheBlockEnd reused in leaf block in recycler (sharing same page allocator) - overload ChangeToAssign in JIT code, check all posible assign for write barrier - missing barriers in various location