Вы мне сейчас приписываете какие-то утверждения, которых я не делал. Я не говорю, что верю в "подобные исследования". Я только заметил, что не всегда можно верить своим глазам и здравому смыслу. Что не исключает вероятности кривости тех или иных исследования. Как раз в постулатах квантовой механики (не понимаю, при чём тут кварки, я про них не говорил) я не сомневаюсь, ибо я вначале 10 лет учился в школе, а потом ещё 5 - на физмате, и за это время успел усвоить научную картину мира, к которой человечество шло долгие века, методом проб и ошибок, положив на это кучу ресурсов. Это при том, что с точки зрения органов чувств и "житейской" логики вся квантовая механика - это дичайшая муть.
Автор же комментария, на который я ответил, ведёт себя как такой невежда, который на физмате не учился, услышал о волновой функции и кинулся критиковать, потому что это не соответствует показаниям его органов чувств.
Что касается лично моего опыта (на основании которого, конечно, нельзя делать общих выводов, претендующих на научность) я вижу, что дама написала статью и словила кучу сексистских комментариев. Я при этом ничего не утверждаю о качестве её статьи, о достоверности содержимого - недостаточно компетентен в вопросе, чтобы судить. Я говорю именно о реакции комментаторов.
не уйдет на три года в отпуск по уходу за ребенком
Во-первых, уйти в отпуск по уходу за ребёнком может и папа. Во-вторых, как раз в IT я очень часто наблюдаю, что женщины с маленьким ребёнком работают - деньги лишними не бывают (особенно для семьи с ребёнком), а сидеть дома скучно, так что многие уже через 3-6 месяцев просятся хотя бы на полставки на удалёнку, и, надо сказать, хорошо справляются с работой.
Зависит от. Некоторые мужчины так же достаточно остро реагируют на ревью. Ну и потом, не факт, что такая реакция не имеет иных причину - например, девушка, окружённая суровыми мужиками (некоторые из которых, возможно, действительно делают сексистские выпадки), испытывает определённые проблемы с самооценкой и потому нервничает.
Считаю, что к женщинам давно уже относятся абсолютно одинаково и согласно с их реальными знаниями и умениями.
Не соглашусь. Мы с вами находимся в некотором информационном пузыре, где это, возможно, действительно так, но вовсем не факт, что так в обществе везде. Хотя бывает, что мы настолько привыкли к некоторой предвзятости по отношению к женщинам, что даже не замечаем некоторой гендерной предвзятости, считая себя образцом толератности.
С другой стороны, я совсем не думаю, что все эти инициативы со стороны компаний и посты в интернете действительно как-то помогут. Скорее, наоборот, вызовут только негативную реакцию. Вот как быть - не могу подсказать, ибо сам не знаю. Возможно, рыночек порешает - сейчас много где в мире назревает нехватка рабочей силы, и мигрантами затыкать вечно не получится (потому что страны, откуда мигрируют, либо в процессе, либо совсем скоро начнут демографический переход).
Я с одной стороны не согласен с тезисом "мужской и женский мозг ничем не отличаются". С другой, да, они отличаются. Но, ИМХО, как раз успех в той или иной деятельности зависит от такого чудовищного количества факторов, что лишь один из них (а именно те или иные гормоны) непонятно как вписывается в общую картину. И самое главное - а где научные исследования про совместимость того или иного гормонального фона с работой программистом?
Да! (ваш уровень аргументации мне нравится, что ж буду пользоваться тем же приемом)
А тут и аргументировать нечего. Нет возможности научно доказать пригодность того или иного языка для решения тех или иных задач. Я думаю, бОльшая часть программистского сообщества согласится, что Rust - это более низкоуровневая штука, на которой какие-нибудь компиляторы можно писать. А вот писать то, для чего обычно используют JS, т.е. веб-морды для всяческих онлайн-сервисов, на Rust намного сложнее. Но фанатам Rust, конечно, так не кажется, и нет никаких надёжных способов их в этом убедить.
Примеров конечно же не будет приведено в качестве аргумента?
Java: на сервере и в Android из коробки; Graal Native Image - легковесные утилиты, быстро стартующие сервисы, iOS-приложения; Google Closure Compiler, TeaVM - компиляция в JS и в WebAssembly (кстати, значительной разницы в перфомансе между JS и WASM таргетами не наблюдается)
Kotlin: из коробки на сервере, Android, iOS, JS и WebAssembly (опять же, в веб Kotlin прекрасно работал через Kotlin/JS, ещё задолго до появления WASM)
Python - из коробки на сервере; Brython - рантайм для браузера (опять же, через JS).
при том, что если вы сможете запустить модель из браузера и получить ту же производительность, что и если вы запустите из питона используя cuda
CUDA работает на видеокарте. На CPU есть ли какой-то смысл запускать AI-модели (ну кроме чисто учебных)? Во сколько раз просядет производительность? Точнее, на сколько порядков? WebAssembly как-то умеет работать на GPU?
Писать логику на расте для браузера вместо джава скрипта это как благословение с небес
Эээ, нет.
Переиспользовать можно 95% одного и того же кода на всех платформах сразу: браузер, мобила, сервер - это просто супер преимущество, тут конечно больше спасибо расту, но тем не менее.
Это совсем не уникальное преимущество WASM или Rust.
Не сегодня-завтра всем понадобится запускать ИИ модели у себя в браузере или на мобиле и производительность там играет решающее значение, wasm и тут должен стать незаменим.
Эээ, я думал, ИИ-модели запускают на CUDA, при чём тут WebAssembly? Может, в данном случае лучше предусмотреть CUDA API или хотя бы OpenCL API для браузера?
Вот всегда в таких статьях "как мы покоряем просторы вселенной" говорится о больших фичах, но всегда не обращается внимание на то, что "есть нюанс". Например, GC они выпустили, ага. Только там почему-то дереференс nullptr приводит к trap-у, а не к исключению, что полностью противоречит поведению в подавляющем числе мейнстримных языков с управляемой кучей (JS, Java, C#, Python); аналогично с делением на ноль или с neg для -0x100000000. Или вот GC не поддерживается ни в одном известном мне безбраузерном движке. Или что до сих пор не выпустили никакого стандарта debug информации, а поддержка DWARF (где она есть) сырая просто до неюзабельности и вообще не вполне стандартизирована (я как автор компилятора в WASM лично сталкивался с тем, что wasmtime и chrome понимают DWARF по-разному). Ну и что DWARF идеологически никак не ложится на языки с GC. Или что ничего близко к "нативной производительности" в WebAssembly и не пахнет, что его "куча" спроектирована так, что любое обращение к памяти неминуемо обкладывается проверками на рантайме, и как авторы этих рантаймов героически пишут оптимизации, призванные количество этих проверок хоть как-то снизить.
Зато, о чудо, реализовали хвостовую рекурсию, всё многочисленное сообщество программистов на OCaml будет довольно этой новости.
B2 хватает, это факт. Другое дело - это скорость и нагрузка. По-русски я пишу быстрее и лучше, при этом прикладывая меньше усилий. И да, я "-тся" и "-ться" не путаю, "не" знаю когда писать раздельно или слитно, но вот те же артикли так и не осилил во всех нюансах.
В догонку вспомнился один случай - как-то про мой проект кто-то упомянул в комментариях к посту в hacker news. И несколько пользователей сразу пожаловались - а по документации проекта не понятно, как вообще начать его использовать. При том, что документация getting started была - как с помощью строчки в CLI создать пустой проект hello world. Естественно, в шаблоне я добавил комментариев, чтобы человек мог создать проект, посмотреть код и увидеть тут же объяснение. Но видимо, они не осилили скопировать текст в консоль, или просто не знали, что в IDEA есть поддержка архетипов в UI - и сразу сделали вывод.
Ещё момент: многие разработчики open source проектов попросту не являются native english speaker и писать документацию с условным B2 (а именно на нём часто люди застревают в плато, с которого в C1 непонятно как попасть, не посвящая вообще всё свободное время планомерному изучению - где же тогда взять время на кодинг) довольно-таки сложно и медленно. И, наконец, разработчику не всегда очевидно, что может вызвать затруднения у других.
Опишу свой опыт с другой стороны. Я вот поддерживаю свой компилятор Java/Kotlin/Scala в JavaScript. Какая-то документация есть. Но документация в стиле "вот так вы можете сгенерировать JS". При этом документация не раскрывает, например, следующие моменты:
Как подключить JS к HTML-файлу (потому что это элементарная культура, про это вообще в интернете куча всего)
Как завести gradle или Maven проект
Как обеспечить копирование какого-то файлика в директории сборки в WAR-файл
Как поднять HTTP-сервер и задеплоить в нём, например, WAR-файл
Как работают те или иные JS API (например, тот же DOM) - есть только документация о том, как их вызывать из Java кода
Как отлаживать JS в браузере
Как настроить webpack и чем ES2015 modules отличаются от CommonJS
И вот не поверите, всё это у меня постоянно спрашивают пользователи, недовольные тем, что "у проекта нет документации". Когда я кому-то из них по какой-то причине всё-таки помогаю (т.е. по сути помогаю с ИХ проблемой, а не с пониманием, как пользоваться МОИМ компилятором), то угадайте, сколько таких несчастных в ответ написали хоть один туториал в репозиторий с документацией по проекту?
Ещё часто пользователи просто не могут глазами спарсить сообщение об ошибке, где им чёрным по белому расписано, почему что-то не работает. При этом есть ещё небольшая прослойка адекватных пользователей, которым, как оказывается, документация вообще не нужна, потому что они давно склонировали репозиторий и нашли в нём папку samples, где уже есть готовые примеры - изучай нехочу, да папку tests, где, не поверите, лежат тесты, которые являются по совместительству ещё и примерами использования проекта.
Что касается бинарников - обычно для всяких кросплатформенных сред с этим всё сильно лучше. И тут я вам открою страшную тайну: собрать дистрибутив на Rust или C++ под все платформы - это то ещё приключение (хотя бы в силу отсутствия того или иного железа в наличии у мейнтейнера). В случае той же Java это не проблема - собирай себе на любой машине и это запуститсяу кого угодно.
Open source проектами занимаются либо большие компании, которые получают непрямой доход от проекта (например, поддерживают ядро Linux, чтобы был софт для железа, которое они продают, или делают платное IDE для языка, компилятор которого опенсорс) - и тогда всё с документацией как правило нормально, потому что большая компания может позволить себе нанять на зарплату помимо армии разработчиков, ещё технических писателей, developer advocate и т.д; либо одиночки-энтузиасты, которым просто по кайфу запрограммировать что-то вечером после работы. Во втором случае странно призывать их писать документацию - они делают то, что им нравится, т.е. пишут код, решая некоторую техническую задачу.
> Ну вот и как можно утверждать, что массивы в JVM реализованы через массивы C?
я этого не утверждал
Выше было
С другой стороны, Kotlin все равно реализован на сях (ИМХО), поэтому, мне кажется что и переписывание памяти в динамических массивах там должно быть аналогичными,
А так же
Где-то ж должно быть пересечение с системными вызовами [Dos]Alloc/Realloc/Free, логично это делать через Це malloc/realloc/free ну или делая вид, что их нет - через классы Це++. Вот оно и есть в рантайме.
вообще говоря в утверждении "попа равно попа с ручкой" есть некое противоречие. Ручка - это длина. В парадигмах жабы не бывает попы без руки..
Ваши указатели и malloc - это тоже ручка. Есть только регистры и числа в них. Остальное - от лукавого. А вообще, я сейчас даже ещё более смелое утверждение выскажу: Жаба, как и C (ИМХО) написаны на Verilog.
Вот допустим, вам потребовался объект/массив на сколько-нибудь гигабайт памяти, вы поюзали и бросили, и далее ждете реакции допустим пользователя до потери пульса - что будет дальше? Отдаст java системе гигабайты?
Нет, не отдаст. Это как раз отличная иллюстрация того, что JVM не использует никак рантайм C для работы с массивами. И, кстати, для таких вот целей аллокации гигантских массивах в Java есть всяческие offheap решения (взять хотя бы тот же ByteBuffer).
Небольшое уточнение. Какие там в Windows системные вызовы, никто не знает, всё вызывается через user-level DLL. Есть подозрение, что VirtualAlloc (а не LocalAlloc) реализован практически через прямой вызов в ядро, а вот всякие LocalAlloc/HeapAlloc - это по сути реализованый из коробки в dll аналог какого-нибудь jemalloc.
Где-то ж должно быть пересечение с системными вызовами [Dos]Alloc/Realloc/Free
Извините, вы про какие системные вызовы? В какой операционной системе? Если богомерзкой, то там LocalAlloc/LocalFree. Если в православной, то mmap. Но это не относится к языку C, это просто системные вызовы, которые можно вызывать откуда угодно. malloc/realloc/free - это уже часть стандарта C, но это уже shared libraries, которые линкуются (статически или динамически) и выполняются в user space. Внутри себя реализации malloc могут использовать системные вызовы для аллокации хипа в целом, но вряд ли вызывают их на каждый чих. И строго говоря, к массивам эти функции не имеют отношения.
JVM для объектов не использует ничего близко похожего на malloc, ибо управляемая куча принципиально иначе функционирует. И в управляемой куче, строго говоря, нет такой операции как free (даже GC внутри не "освобождает" память в хипе в том же смысле, в каком это делает free).
Массивы в Java принципиально иначе устроены. Начнём с того, что в C как таковых массивов-то и нет, есть просто арифметика указателей и синтаксический сахар, совмещающий арифметику указателей с дереференсом. В массивах Java есть длина, если полноценный vtable, ибо они тоже объекты и у них можно вызвать, например, toString или clone. При обращении к элементам массива индекс проверяется на выход за границы (если только не удалось доказать во время компиляции, что индекс не выходит), кидается исключение.
Ну вот и как можно утверждать, что массивы в JVM реализованы через массивы C? Не, ну в каком-то смысле можно так натянуть. В том, что данные массива так же расположены в памяти один за другим. Но это как утверждать, что человек - это такой же камень, потому что тоже состоит из атомов.
А как же
IntStream?Вы мне сейчас приписываете какие-то утверждения, которых я не делал. Я не говорю, что верю в "подобные исследования". Я только заметил, что не всегда можно верить своим глазам и здравому смыслу. Что не исключает вероятности кривости тех или иных исследования. Как раз в постулатах квантовой механики (не понимаю, при чём тут кварки, я про них не говорил) я не сомневаюсь, ибо я вначале 10 лет учился в школе, а потом ещё 5 - на физмате, и за это время успел усвоить научную картину мира, к которой человечество шло долгие века, методом проб и ошибок, положив на это кучу ресурсов. Это при том, что с точки зрения органов чувств и "житейской" логики вся квантовая механика - это дичайшая муть.
Автор же комментария, на который я ответил, ведёт себя как такой невежда, который на физмате не учился, услышал о волновой функции и кинулся критиковать, потому что это не соответствует показаниям его органов чувств.
Что касается лично моего опыта (на основании которого, конечно, нельзя делать общих выводов, претендующих на научность) я вижу, что дама написала статью и словила кучу сексистских комментариев. Я при этом ничего не утверждаю о качестве её статьи, о достоверности содержимого - недостаточно компетентен в вопросе, чтобы судить. Я говорю именно о реакции комментаторов.
Во-первых, уйти в отпуск по уходу за ребёнком может и папа. Во-вторых, как раз в IT я очень часто наблюдаю, что женщины с маленьким ребёнком работают - деньги лишними не бывают (особенно для семьи с ребёнком), а сидеть дома скучно, так что многие уже через 3-6 месяцев просятся хотя бы на полставки на удалёнку, и, надо сказать, хорошо справляются с работой.
Зависит от. Некоторые мужчины так же достаточно остро реагируют на ревью. Ну и потом, не факт, что такая реакция не имеет иных причину - например, девушка, окружённая суровыми мужиками (некоторые из которых, возможно, действительно делают сексистские выпадки), испытывает определённые проблемы с самооценкой и потому нервничает.
Согласно моим глазам, ушам, памяти и здравому смыслу нет ничего абсурднее квантовой механики.
Не соглашусь. Мы с вами находимся в некотором информационном пузыре, где это, возможно, действительно так, но вовсем не факт, что так в обществе везде. Хотя бывает, что мы настолько привыкли к некоторой предвзятости по отношению к женщинам, что даже не замечаем некоторой гендерной предвзятости, считая себя образцом толератности.
С другой стороны, я совсем не думаю, что все эти инициативы со стороны компаний и посты в интернете действительно как-то помогут. Скорее, наоборот, вызовут только негативную реакцию. Вот как быть - не могу подсказать, ибо сам не знаю. Возможно, рыночек порешает - сейчас много где в мире назревает нехватка рабочей силы, и мигрантами затыкать вечно не получится (потому что страны, откуда мигрируют, либо в процессе, либо совсем скоро начнут демографический переход).
Я с одной стороны не согласен с тезисом "мужской и женский мозг ничем не отличаются". С другой, да, они отличаются. Но, ИМХО, как раз успех в той или иной деятельности зависит от такого чудовищного количества факторов, что лишь один из них (а именно те или иные гормоны) непонятно как вписывается в общую картину. И самое главное - а где научные исследования про совместимость того или иного гормонального фона с работой программистом?
А никто не говорит про объединение. Старые добрые потоки в пуле
А вы пробовали вместо потока на каждый файл банально запускать задачи в thread pool?
А тут и аргументировать нечего. Нет возможности научно доказать пригодность того или иного языка для решения тех или иных задач. Я думаю, бОльшая часть программистского сообщества согласится, что Rust - это более низкоуровневая штука, на которой какие-нибудь компиляторы можно писать. А вот писать то, для чего обычно используют JS, т.е. веб-морды для всяческих онлайн-сервисов, на Rust намного сложнее. Но фанатам Rust, конечно, так не кажется, и нет никаких надёжных способов их в этом убедить.
Java: на сервере и в Android из коробки; Graal Native Image - легковесные утилиты, быстро стартующие сервисы, iOS-приложения; Google Closure Compiler, TeaVM - компиляция в JS и в WebAssembly (кстати, значительной разницы в перфомансе между JS и WASM таргетами не наблюдается)
Kotlin: из коробки на сервере, Android, iOS, JS и WebAssembly (опять же, в веб Kotlin прекрасно работал через Kotlin/JS, ещё задолго до появления WASM)
Python - из коробки на сервере; Brython - рантайм для браузера (опять же, через JS).
CUDA работает на видеокарте. На CPU есть ли какой-то смысл запускать AI-модели (ну кроме чисто учебных)? Во сколько раз просядет производительность? Точнее, на сколько порядков? WebAssembly как-то умеет работать на GPU?
Эээ, нет.
Это совсем не уникальное преимущество WASM или Rust.
Эээ, я думал, ИИ-модели запускают на CUDA, при чём тут WebAssembly? Может, в данном случае лучше предусмотреть CUDA API или хотя бы OpenCL API для браузера?
Вот всегда в таких статьях "как мы покоряем просторы вселенной" говорится о больших фичах, но всегда не обращается внимание на то, что "есть нюанс". Например, GC они выпустили, ага. Только там почему-то дереференс nullptr приводит к trap-у, а не к исключению, что полностью противоречит поведению в подавляющем числе мейнстримных языков с управляемой кучей (JS, Java, C#, Python); аналогично с делением на ноль или с neg для -0x100000000. Или вот GC не поддерживается ни в одном известном мне безбраузерном движке. Или что до сих пор не выпустили никакого стандарта debug информации, а поддержка DWARF (где она есть) сырая просто до неюзабельности и вообще не вполне стандартизирована (я как автор компилятора в WASM лично сталкивался с тем, что wasmtime и chrome понимают DWARF по-разному). Ну и что DWARF идеологически никак не ложится на языки с GC. Или что ничего близко к "нативной производительности" в WebAssembly и не пахнет, что его "куча" спроектирована так, что любое обращение к памяти неминуемо обкладывается проверками на рантайме, и как авторы этих рантаймов героически пишут оптимизации, призванные количество этих проверок хоть как-то снизить.
Зато, о чудо, реализовали хвостовую рекурсию, всё многочисленное сообщество программистов на OCaml будет довольно этой новости.
B2 хватает, это факт. Другое дело - это скорость и нагрузка. По-русски я пишу быстрее и лучше, при этом прикладывая меньше усилий. И да, я "-тся" и "-ться" не путаю, "не" знаю когда писать раздельно или слитно, но вот те же артикли так и не осилил во всех нюансах.
В догонку вспомнился один случай - как-то про мой проект кто-то упомянул в комментариях к посту в hacker news. И несколько пользователей сразу пожаловались - а по документации проекта не понятно, как вообще начать его использовать. При том, что документация getting started была - как с помощью строчки в CLI создать пустой проект hello world. Естественно, в шаблоне я добавил комментариев, чтобы человек мог создать проект, посмотреть код и увидеть тут же объяснение. Но видимо, они не осилили скопировать текст в консоль, или просто не знали, что в IDEA есть поддержка архетипов в UI - и сразу сделали вывод.
Ещё момент: многие разработчики open source проектов попросту не являются native english speaker и писать документацию с условным B2 (а именно на нём часто люди застревают в плато, с которого в C1 непонятно как попасть, не посвящая вообще всё свободное время планомерному изучению - где же тогда взять время на кодинг) довольно-таки сложно и медленно. И, наконец, разработчику не всегда очевидно, что может вызвать затруднения у других.
Опишу свой опыт с другой стороны. Я вот поддерживаю свой компилятор Java/Kotlin/Scala в JavaScript. Какая-то документация есть. Но документация в стиле "вот так вы можете сгенерировать JS". При этом документация не раскрывает, например, следующие моменты:
Как подключить JS к HTML-файлу (потому что это элементарная культура, про это вообще в интернете куча всего)
Как завести gradle или Maven проект
Как обеспечить копирование какого-то файлика в директории сборки в WAR-файл
Как поднять HTTP-сервер и задеплоить в нём, например, WAR-файл
Как работают те или иные JS API (например, тот же DOM) - есть только документация о том, как их вызывать из Java кода
Как отлаживать JS в браузере
Как настроить webpack и чем ES2015 modules отличаются от CommonJS
И вот не поверите, всё это у меня постоянно спрашивают пользователи, недовольные тем, что "у проекта нет документации". Когда я кому-то из них по какой-то причине всё-таки помогаю (т.е. по сути помогаю с ИХ проблемой, а не с пониманием, как пользоваться МОИМ компилятором), то угадайте, сколько таких несчастных в ответ написали хоть один туториал в репозиторий с документацией по проекту?
Ещё часто пользователи просто не могут глазами спарсить сообщение об ошибке, где им чёрным по белому расписано, почему что-то не работает. При этом есть ещё небольшая прослойка адекватных пользователей, которым, как оказывается, документация вообще не нужна, потому что они давно склонировали репозиторий и нашли в нём папку samples, где уже есть готовые примеры - изучай нехочу, да папку tests, где, не поверите, лежат тесты, которые являются по совместительству ещё и примерами использования проекта.
Что касается бинарников - обычно для всяких кросплатформенных сред с этим всё сильно лучше. И тут я вам открою страшную тайну: собрать дистрибутив на Rust или C++ под все платформы - это то ещё приключение (хотя бы в силу отсутствия того или иного железа в наличии у мейнтейнера). В случае той же Java это не проблема - собирай себе на любой машине и это запуститсяу кого угодно.
Open source проектами занимаются либо большие компании, которые получают непрямой доход от проекта (например, поддерживают ядро Linux, чтобы был софт для железа, которое они продают, или делают платное IDE для языка, компилятор которого опенсорс) - и тогда всё с документацией как правило нормально, потому что большая компания может позволить себе нанять на зарплату помимо армии разработчиков, ещё технических писателей, developer advocate и т.д; либо одиночки-энтузиасты, которым просто по кайфу запрограммировать что-то вечером после работы. Во втором случае странно призывать их писать документацию - они делают то, что им нравится, т.е. пишут код, решая некоторую техническую задачу.
Я за написание гайда для пользователей open-source проектов. Напомнить лишний раз про донаты не повредит
Выше было
А так же
Ваши указатели и malloc - это тоже ручка. Есть только регистры и числа в них. Остальное - от лукавого. А вообще, я сейчас даже ещё более смелое утверждение выскажу: Жаба, как и C (ИМХО) написаны на Verilog.
Нет, не отдаст. Это как раз отличная иллюстрация того, что JVM не использует никак рантайм C для работы с массивами. И, кстати, для таких вот целей аллокации гигантских массивах в Java есть всяческие offheap решения (взять хотя бы тот же ByteBuffer).
Небольшое уточнение. Какие там в Windows системные вызовы, никто не знает, всё вызывается через user-level DLL. Есть подозрение, что VirtualAlloc (а не LocalAlloc) реализован практически через прямой вызов в ядро, а вот всякие LocalAlloc/HeapAlloc - это по сути реализованый из коробки в dll аналог какого-нибудь jemalloc.
Извините, вы про какие системные вызовы? В какой операционной системе? Если богомерзкой, то там LocalAlloc/LocalFree. Если в православной, то mmap. Но это не относится к языку C, это просто системные вызовы, которые можно вызывать откуда угодно. malloc/realloc/free - это уже часть стандарта C, но это уже shared libraries, которые линкуются (статически или динамически) и выполняются в user space. Внутри себя реализации malloc могут использовать системные вызовы для аллокации хипа в целом, но вряд ли вызывают их на каждый чих. И строго говоря, к массивам эти функции не имеют отношения.
JVM для объектов не использует ничего близко похожего на malloc, ибо управляемая куча принципиально иначе функционирует. И в управляемой куче, строго говоря, нет такой операции как free (даже GC внутри не "освобождает" память в хипе в том же смысле, в каком это делает free).
Массивы в Java принципиально иначе устроены. Начнём с того, что в C как таковых массивов-то и нет, есть просто арифметика указателей и синтаксический сахар, совмещающий арифметику указателей с дереференсом. В массивах Java есть длина, если полноценный vtable, ибо они тоже объекты и у них можно вызвать, например, toString или clone. При обращении к элементам массива индекс проверяется на выход за границы (если только не удалось доказать во время компиляции, что индекс не выходит), кидается исключение.
Ну вот и как можно утверждать, что массивы в JVM реализованы через массивы C? Не, ну в каком-то смысле можно так натянуть. В том, что данные массива так же расположены в памяти один за другим. Но это как утверждать, что человек - это такой же камень, потому что тоже состоит из атомов.