| /arkcompiler/runtime_core/docs/changelogs/ |
| D | 2022-08-18-isa-changelog.md | 13 1. We delete all original java specific opcodes and delete java specific opcode prefix. 14 2. We remove the prefix of ecmascript specific opcodes, such that most of the bytecode opcode can b… 15 …We add prefix "deprecated" and keep the many old isa as "deprecated"-prefixed opcodes (for compati… 16 4. We add prefix "throw" and make all throwing opcodes be prefixed by "throw". 17 5. We add prefix "wide" to support opcodes which need larger immediate number. 18 6. We adjust the format of some opcodes (about immediate number and accumulator), so that the bytec… 19 7. We change the semantics of some opcodes. 20 8. We add 8-bit or 16-bit imm as inline cache slot for some specific opcodes. 23 As we merge some "define-function" opcodes as one opcode, in function we add one field which record… 25 We also add header index in function such that runtime can access IndexHeader more efficiently. [all …]
|
| D | 2024-04-08-file_format-changelog.md | 12 1. We update the version to 12.0.1.0 15 1. We delete ProtoItem's data from file format from version 12.0.1.0. 16 2. We invalid the [proto_idx] field by setting [0xffff] in Method from version 12.0.1.0. 19 1. We delete the corresponding [field_idx_off] offsets-array from file format from version 12.0.1.0. 20 2. We invalid the [field_idx_size] & [field_idx_off] by setting [0xffffffff] in IndexHeader from ve… 21 3. We delete the corresponding [proto_idx_off] offsets-array from file format from version 12.0.1.0. 22 4. We invalid the [proto_idx_size] & [proto_idx_off] by setting [0xffffffff] in IndexHeader from ve…
|
| /arkcompiler/runtime_core/static_core/plugins/ets/compiler/docs/ |
| D | interop_intrinsic_opt_doc.md | 4 …lues (we call this **wrap**), and returned local value is converted to ArkTS JSValue, which may be… 6 We try to reduce number of local scopes by merging them and then optimize wrap/unwrap intrinsics. 31 …e option `--compiler-interop-scope-object-limit`. If we hit the limit during the first 2 stages, w… 35 …e local scopes inside each basic block. We iterate block instructions and track current scope stat… 37 … separated from `V(G)\S` by scope switches (scope start or scope ends). If we remove these scope s… 39 …bjects in the newly created scopes, we use disjoint set union (DSU) with this number saved for eac… 41 …or dominate each other, but use `wrap`s of the same values, is bad too. So we try to minimize numb… 43 …we use some ideas from general `partial-redundancy elimination` algorithms. We call a value **anti… 50 We traverse the CFG, tracking the current scope (i. e. last scope start instruction on the path fro… 54 Here we use scope starts computed above and optimize only pairs of instructions which are in the sa… [all …]
|
| /arkcompiler/runtime_core/static_core/docs/ |
| D | task_manager.md | 3 …we have different tasks for two components `GC` and `JIT`. Both of this components can use more th… 5 …ybrid mode (i.e. we can execute both static and dynamic code) TaskManager also should take into ac… 25 …ent context(i.e. which language currently executed - static or dynamic, do we expect GC soon or no… 27 …rity for TaskQueue(s). For example if we are currently expect a lot of GC because we have a lot of… 35 For managing worker threads we should provide machinery for: 41 NB: the minimal entity in this machinery is WorkerThread, i.e. we shouldn't have one `TaskQueue` fo…
|
| D | cfi_directives.md | 24 In prolog we save `lr`, `fp` and `callee` regs on stack. 25 So we should explicitly mark these stack slots with help of `CFI` directives. 30 In epilog we read saved `callees` from stack and also `fp`/`lr`. Here we annotate that saved regist… 41 In that case we "say" to `debugger` that we are not going to return to previous frame. So we direct…
|
| D | on-stack-replacement.md | 7 Under the OSR, we mean the transition from interpreter code to optimized code. Opposite transition … 8 unoptimized - we call `Deoptimization`. 47 …d regular compilation use the same hotness counter. First time, when counter is overflowed we look 48 whether method is already compiled or not. If not, we start compilation in regular mode. Otherwise,… 51 Once compilation is triggered and OSR compiled code is already set, we begin On-Stack Replacement p… 61 To ensure all loops in the compiled code may be entered from the interpreter, we need to avoid loop… 76 On each OSR entry, we need to restore execution context. 77 To do this, we need to know all live virtual registers at this moment. 98 Since Panda Interpreter is written in the C++ language, we haven't access to its stack. Thus, we ca… 99 interpreter frame by cframe on the stack. When OSR is occurred we call OSR compiled code, and once … [all …]
|
| D | rationale-for-bytecode.md | 30 making interpretation slower than _native code execution_. In return, we get the ability to 76 At the same time, to execute a stack-based addition we need to run 3 instructions compared to 110 With this approach, we are no longer required to encode destination register, it is "hardcoded" to 148 It easy to see that to address virtual registers 4 and 5 we need just 3 bits which allows to encode 158 into 4 bits, we have to use a wider encoding: 165 How to make sure that we benefit from the shorter encoding most of the time? An observation shows 171 Please note also that we don't need "full-range" versions for all instructions. In case some 172 instruction lacks a wide-range form, we can prepare operands for it with moves that have all 173 needed forms. Thus we save on opcode space without losing in encoding size (on average). 175 With such approach, we can carefully introduce various "overloads" for instruction when it could [all …]
|
| D | deoptimization.md | 22 The slow path encodes a call to the runtime function `Deoptimize`. We do the following for this: 32 The function `Deoptimize` calculates bitecode pc where we should start executing code in the interp… 33 If deoptimization occurred in the inlined method, we restore all interpreter frames for all inlined… 78 …s (which we saved in the method) and call `InvokeInterpreter` to execute the method in the interpr… 84 …he interpreter. After return from `InvokeInterpreter`, we restore callee saved registers(which we … 97 If deoptimization occurred in the inlined method, we call interpreter for all inlined methods from …
|
| D | memory-management.md | 5 Panda Runtime should be scalable onto different devices/OSes. So we need some abstraction level for… 6 For now, all targets suppose interaction with the user, so we have some limitations for the STW pau… 7 We have very limited memory resources for IoT target, so we should maximize efforts on reducing mem… 33 Mode are chosen at the startup time (we'll use profile info from cloud for that). 107 However, we can also support such version of the object header(Hash is stored just after the object… 123 This scenario decreases the size of a Monitor instance, and we don't need to save Hash somewhere du… 125 But, this scenario will be useful if we have allocator and GC which decreases such a situation to a… 152 Heavyweight Lock - we have competition for this object(few threads try to lock this object). 172 If we don't use strings compressing, each string has this structure: 184 If we use strings compressing, each string has this structure: [all …]
|
| /arkcompiler/runtime_core/docs/ |
| D | cfi_directives.md | 24 In prolog we save `lr`, `fp` and `callee` regs on stack. 25 So we should explicitly mark these stack slots with help of `CFI` directives. 30 In epilog we read saved `callees` from stack and also `fp`/`lr`. Here we annotate that saved regist… 41 In that case we "say" to `debugger` that we are not going to return to previous frame. So we direct…
|
| D | on-stack-replacement.md | 7 Under the OSR, we mean the transition from interpreter code to optimized code. Opposite transition … 8 unoptimized - we call `Deoptimization`. 47 …d regular compilation use the same hotness counter. First time, when counter is overflowed we look 48 whether method is already compiled or not. If not, we start compilation in regular mode. Otherwise,… 51 Once compilation is triggered and OSR compiled code is already set, we begin On-Stack Replacement p… 61 To ensure all loops in the compiled code may be entered from the interpreter, we need to avoid loop… 76 On each OSR entry, we need to restore execution context. 77 To do this, we need to know all live virtual registers at this moment. 98 Since Panda Interpreter is written in the C++ language, we haven't access to its stack. Thus, we ca… 99 interpreter frame by cframe on the stack. When OSR is occurred we call OSR compiled code, and once … [all …]
|
| D | rationale-for-bytecode.md | 30 making interpretation slower than _native code execution_. In return, we get the ability to 76 At the same time, to execute a stack-based addition we need to run 3 instructions compared to 110 With this approach, we are no longer required to encode destination register, it is "hardcoded" to 148 It easy to see that to address virtual registers 4 and 5 we need just 3 bits which allows to encode 158 into 4 bits, we have to use a wider encoding: 165 How to make sure that we benefit from the shorter encoding most of the time? An observation shows 171 Please note also that we don't need "full-range" versions for all instructions. In case some 172 instruction lacks a wide-range form, we can prepare operands for it with moves that have all 173 needed forms. Thus we save on opcode space without losing in encoding size (on average). 175 With such approach, we can carefully introduce various "overloads" for instruction when it could [all …]
|
| D | memory-management.md | 5 Panda Runtime should be scalable onto different devices/OSes. So we need some abstraction level for… 6 For now, all targets suppose interaction with the user, so we have some limitations for the STW pau… 7 We have very limited memory resources for IoT target, so we should maximize efforts on reducing mem… 33 Mode are chosen at the startup time (we'll use profile info from cloud for that). 107 However, we can also support such version of the object header(Hash is stored just after the object… 123 This scenario decreases the size of a Monitor instance, and we don't need to save Hash somewhere du… 125 But, this scenario will be useful if we have allocator and GC which decreases such a situation to a… 152 Heavyweight Lock - we have competition for this object(few threads try to lock this object). 172 If we don't use strings compressing, each string has this structure: 184 If we use strings compressing, each string has this structure: [all …]
|
| /arkcompiler/runtime_core/static_core/compiler/docs/ |
| D | memory_barriers_doc.md | 5 We need to encode barriers after the instructions NewArray, NewObject, NewMultiArray so that if the… 6 We can remove the barrier if we prove that the created object cannot be passed to another thread be… 7 This can happen if we save the object to memory or pass it to another method 21 We pass through all instructions in PRO order. If the instruction has flag `MEM_BARRIER` we add the… 22 If we visit an instruction that can pass an object to another thread(Store instruction, Call instru… 23 If the instruction has input from the `barriers_insts_`, we call function `MergeBarriers`. 25 So we will only set the barrier in the last instruction before potentially passing the created obje…
|
| D | lse_doc.md | 27 …as written by store instruction above, this load can be eliminated because we already know the val… 31 …o traverse basic blocks in reverse post order so that for each basic block we already visited all … 33 Once a heap is initialized for a basic block we iterate over instructions and update heap by applyi… 38 - if the instruction is a load and there is no value from the heap for this load then we update hea… 45 …we cannot eliminate anything in single traversal because further memory operations may update heap… 105 …iminated due to `v3`. However we can't record `v20` to list of loads that will be eliminated becau… 111 …We call these memory accesses as phi-candidates. Each phi-candidate has its own list of aliased me… 113 …we iterate over all memory accesses collected in lists for each phi-candidate. If there is at leas… 117 - visiting any memory access inside a reducible loop we check the aliasing with phi-candidates of t… 122 * If any of aliased accesses for a candidate is a store, we do nothing. [all …]
|
| D | bridges.md | 11 …case GC is triggered between incorrect SaveState and usage then we will lost object - we will not … 14 We need to be sure that the `source` instruction dominates the `target` instruction. 17 We bypass the graph in the opposite direction from the `target` instruction to the `source` and we … 26 … traversing backwards from `target`, and `target_block` (for the case when we need to build bridge… 36 …or moved, but the pointer will not change. As a result, in instruction v10 we can use the object a…
|
| D | inlining.md | 21 To devirtualize virtual calls, i.e. determine target method in compile time, we use following techn… 34 here, we know receiver class (A) at compile time and we can inline A.foo method without any specula… 38 We use dynamic Class Hierarchy Analysis, because Panda Runtime allows dynamic class loading. 57 # Actually, here is static devirtualization makes a work, we use this assembly for simplicity and c… 67 Since Panda VM allows instantiating a classes with abstract methods, we can't rely on the fact that… 68 never instantiated. Thus we can't apply the rule: abstract method does not break Single Implementat… 71 We should protect all devirtualized call sites with CHA by special guards. In short, these guards c… 79 compilation code in Method class is not enough. Thus, we walk over call stack of the all threads an… 80 dependent methods. Then we set special `ShouldDeoptimize` flag in the frame of these dependent meth…
|
| /arkcompiler/runtime_core/static_core/runtime/mem/ |
| D | alloc_config.h | 30 …* We want to record stats about allocations and free events. Allocators don't care about the type … 32 …* we can cast void* to object and get the specific size of this object, otherwise we should believ… 33 …* can record only approximate size. Because of this we force allocators to use specific config for… 86 * we find the first object, which crosses the border of this interval. 154 // We don't use crossing map in this config. 157 // We don't use crossing map in this config. 165 // We don't use crossing map in this config. 168 // We can't call CrossingMap when we don't use it in FindFirstObjInCrossingMap() 173 // We don't use crossing map in this config. 176 // We don't use crossing map in this config. [all …]
|
| /arkcompiler/runtime_core/static_core/bytecode_optimizer/ |
| D | check_resolver.h | 27 * Check Resolver is a bytecodeopt-specific pass. In bytecode optimizer, we do 31 * For the sake of saving ROM size, we can delete these check-instructions. Besides, 36 * why dead lenarr remains. So we can also benefit from the size of generated bytecode 40 * since they can throw but they are not generated as inputs of check-instructions, We 43 * For every check-instruction, we replace the corresponding input of its users by the data 44 * flow input. Then we clear its NO_DCE flag such that it can be removed by DCE pass. We set
|
| /arkcompiler/runtime_core/libabckit/tests/clean_scenarios/cpp_api/dynamic/router_table/ |
| D | README.md | 3 Suppose that we have many annotated classes and one map, we need to collect all these classes and c… 11 We have such classes: 44 // we have many such imports
|
| /arkcompiler/runtime_core/libabckit/tests/clean_scenarios/c_api/dynamic/router_table/ |
| D | README.md | 3 Suppose that we have many annotated classes and one map, we need to collect all these classes and c… 11 We have such classes: 44 // we have many such imports
|
| /arkcompiler/runtime_core/cmake/ |
| D | PandaCmakeFunctions.cmake | 15 # We need use linker scripts for section replacement above 4GB 17 # so we have difference start addresses for asan and default buildings 19 # When using rapidcheck we should use linker scripts with 32 # For cross-aarch64 with ASAN with linker script we need use additional path-link 33 … # Here we use default addresses space (without ASAN flag). It is nuance of cross-building. 40 # We need use specific options for AMD64 building with Clang compiler
|
| D | ClangTidy.cmake | 21 # TODO: Retry once we upgrade the checker. 36 # Currently we fix a certain version of clang-tidy to avoid unstable linting, 53 # Hence we check for ERROR_VARIABLE instead of RESULT_VARIABLE. 66 # definition. We add it to targets on which we run clang-tidy just to 93 # * We use permissive policy for checks, i.e. everything is enabled by default, 95 # * We maintain the list of global exceptions in this function (not in .clang-tidy) 147 "-readability-identifier-naming" # disabled because we will use little-hump-style 149 …"-fuchsia-trailing-return" # disabled because we have a lot of false positives and it is stylisti… 150 …"-fuchsia-default-arguments-calls" # disabled because we use functions with default arguments a lot 151 …"-fuchsia-default-arguments-declarations" # disabled because we use functions with default argumen… [all …]
|
| /arkcompiler/runtime_core/static_core/runtime/mem/gc/ |
| D | gc_settings.h | 97 …mum percentage of not used bytes in tenured region to collect it on full even if we have no garbage 103 * @brief Specify if we need to track removing objects 131 …* @brief Max stack size for marking in main thread, if it exceeds we will send a new task to worke… 137 …* @brief Max stack size for marking in a gc worker, if it exceeds we will send a new task to worke… 151 /// @brief true if we want to do marking phase in multithreading mode. 156 /// @brief true if we want to do compacting phase in multithreading mode. 161 /// @brief true if we want to do ref updating phase in multithreading mode 188 * collect it on full even if we have no garbage inside 197 …/// Max stack size for marking in main thread, if it exceeds we will send a new task to workers, 0… 199 …/// Max stack size for marking in a gc worker, if it exceeds we will send a new task to workers, 0… [all …]
|
| /arkcompiler/runtime_core/static_core/libpandabase/mem/ |
| D | weighted_adaptive_tlab_average.h | 48 * If vector with samples is not empty, we start estimating TLABs' average fill fraction 49 * If average fill fraction is less than desiredFillFraction_, then we increase TLABs' size 50 * Else, we reduce TLABs' size 67 // it means that zero tlab is the only sample that we currently have in ComputeNewSumAndResetSamples() 68 // in this case we don't have enough information to calculate new TLAB size in ComputeNewSumAndResetSamples() 77 // In this case we have few TLABs with good average fill fraction in ComputeNewSumAndResetSamples() 78 // It means that we should consider reducing TLABs' size in ComputeNewSumAndResetSamples()
|