search for: class_siz

...ething else. My idea was a C API with implementations of functions: For example Assuming I need to implement a function which allocates a new object. The API provides a really basic allocator function I can use to implement the complete function the high-level language needs. void *__newobject(int class_size) { void *r = __alloc(class_size); // Add GC metadata here return r; } This function will be included in the runtime library. Obviously this is a stupid example maybe a better implementation can be done. Something like this can be done for I/O. > On May 23, 2016, at 11:28 AM, David Chisnal...

...a C API with implementations of functions: > For example > Assuming I need to implement a function which allocates a new object. > The API provides a really basic allocator function I can use to implement the complete function the high-level language needs. > > void *__newobject(int class_size) { > void *r = __alloc(class_size); > // Add GC metadata here > return r; > } You have still completely failed to explain why __alloc() is better than malloc(). If you wish to implement a language-specific allocator like this, then why would it want to call __alloc() from your hypoth...

On 23 May 2016, at 10:13, Lorenzo Laneve <lore97drk at icloud.com> wrote: > > I know but maybe malloc() is a bit higher level than a hypothetical __alloc(), which may be lower-level and then faster. How? > And malloc() is contained in the libc as Matthias said and so maybe a program using malloc() even for a non-C language linking against the crt is needed. On many *NIX

...ntations of functions: >> For example >> Assuming I need to implement a function which allocates a new object. >> The API provides a really basic allocator function I can use to implement the complete function the high-level language needs. >> >> void *__newobject(int class_size) { >> void *r = __alloc(class_size); >> // Add GC metadata here >> return r; >> } > > You have still completely failed to explain why __alloc() is better than malloc(). If you wish to implement a language-specific allocator like this, then why would it want to call...

.... I have random effects nested within levels of a random effect? The problem is this: I have a sample of classes (class being the nesting factor). Within each class I have a sample of students. I have separate random effects models at each level. That is, at the class level, I have: random=~class_size+number_teachers+class_length and at the student level I have: test_score~treatment+experience+age. What I want o assess is the contribution of class level variables simultaneously with individual level variables on test scores. Now, my problem is specifying them both as a random effect. I...

...ndle_to_obj(unsigned long handle) { return *(unsigned long *)handle; @@ -885,17 +922,6 @@ static unsigned long obj_to_head(struct size_class *class, struct page *page, return *(unsigned long *)obj; } -static unsigned long obj_idx_to_offset(struct page *page, - unsigned long obj_idx, int class_size) -{ - unsigned long off = 0; - - if (!is_first_page(page)) - off = page->index; - - return off + obj_idx * class_size; -} - static inline int trypin_tag(unsigned long handle) { unsigned long *ptr = (unsigned long *)handle; @@ -952,6 +978,7 @@ static void free_zspage(struct page *first_page...

...ndle_to_obj(unsigned long handle) { return *(unsigned long *)handle; @@ -880,17 +917,6 @@ static unsigned long obj_to_head(struct size_class *class, struct page *page, return *(unsigned long *)obj; } -static unsigned long obj_idx_to_offset(struct page *page, - unsigned long obj_idx, int class_size) -{ - unsigned long off = 0; - - if (!is_first_page(page)) - off = page->index; - - return off + obj_idx * class_size; -} - static inline int trypin_tag(unsigned long handle) { unsigned long *ptr = (unsigned long *)handle; @@ -916,7 +942,6 @@ static void reset_page(struct page *page) cle...

Currently, we store class:fullness into page->mapping. The number of class we can support is 255 and fullness is 4 so (8 + 2 = 10bit) is enough to represent them. Meanwhile, the bits we need to store in-use objects in zspage is that 11bit is enough. For example, If we assume that 64K PAGE_SIZE, class_size 32 which is worst case, class->pages_per_zspage become 1 so the number of objects in zspage is 2048 so 11bit is enough. The next class is 32 + 256(i.e., ZS_SIZE_CLASS_DELTA). With worst case that ZS_MAX_PAGES_PER_ZSPAGE, 64K * 4 / (32 + 256) = 910 so 11bit is still enough. So, we could squeeze...

....reset = intel_hda_reset, + .props = intel_hda_properties, + .class_init = intel_hda_class_init, +}; + +static TypeInfo hda_codec_device_type_info = { + .name = TYPE_HDA_CODEC_DEVICE, + .parent = TYPE_DEVICE, + .instance_size = sizeof(HDACodecDevice), + .abstract = true, + .class_size = sizeof(HDACodecDeviceClass), }; static void intel_hda_register(void) { pci_qdev_register(&intel_hda_info); + type_register_static(&hda_codec_device_type_info); } device_init(intel_hda_register); diff --git a/hw/ioh3420.c b/hw/ioh3420.c index a6bfbb9..6cfafb3 100644 --- a...

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.